Redis性能压测实战
既然准备压测Redis，肯定要准备压测机器，Redis服务器，这里还走了不少弯路，大致情况如下：
Redis单点压测
1.三台Jmeter压5-10台Java服务器，压测后面一台单点的Redis 刚开始压测的时候想着模拟常规用户调用场景于是写了一个简单的Java服务，并且集群式部署，它们连接到一台Redis服务器，见下图：
当然压之前也查看了Redis官网，以及用Redis-bechmark试过Redis极限性能到10万的GPS左右，但是用这样的方式压测根本压不到瓶颈，哪怕把Java服务器与Redis的连接数调大。不停地加Java服务机器，却怎么压不出Redis的极限，此时可以感受到Redis性能的强悍。虽然有官方数据，但是经过这么多机器的压测仍然达不到它的瓶颈，大概知道是压测方式出问题了。
单Java服务器压单台Redis
换另一个方案，Java服务器，写接口多线程压测Redis，性能爆炸，压测数据如下：
这个数据巅峰数值达到了11万，比传言的还要高。
Redis-cluster压测
压完单点Redis服务之后，信心暴增，在求了运维之后，又加了了一些机器，利用6台Linux服务器搭建6主6从的Redis-cluster集群，如下图所示：
于是立马代码，着手压测，压测结果却不尽人意，下面请看数据：
分析了下上面的压测数据，Redis机器添加了6倍，性能突破1倍都没有，肯定是哪里出了问题，于是继续分析代码，原来使用JedisPoll的时候，每次使用完一个链接，又得丢给池子，性能可能损耗在这里，于是立马改代码，将线程不用再丢弃，每个压测线程使用一个Redis的链接，得到的数据非常爆炸。
JedisPool设置了100个链接，且用100个线程同时请求。
又设置了1000个连接
由此发现连接数越多也不是最好的，反而会导致性能下降，这个就是我们平时所谓的性能调优。
总结
1.Redis的单机性能达到10万QPS，集群的性能损失也不是很多，6节点的集群我们压到了50多万，只要合理使用Redis，Redis的性能远远够用。
2.Java服务器与Redis的连接数设置不是越多越好，一定是存在一个性能最好的中间值，这个需要不停的压测与调优才能得到。