背景
家喻户晓，Redis是一款性能强悍的中间件。那么它的性能到底多强，大家也是只拿到的是官网给到的数据，那么真实情况是否真的是这样? 带着这个疑难，筛选了Redis单机与集群做压测，失去性能数据，并剖析两者性能的关系是否是线性的。
筹备工作
简略介绍下业界的Redis集群：
一、Codis
Codis 是 Wandoujia Infrastructure Team 开发的一个分布式 Redis 服务, 用户能够看成是一个有限内存的 Redis 服务, 有动静扩/缩容的能力. 对偏存储型的业务更实用, 如果你须要 SUBPUB 之类的指令, Codis 是不反对的. 时刻记住 Codis 是一个分布式存储的我的项目. 对于海量的 Key, value不太大( <= 1M ), 随着业务扩大缓存也要随之扩大的业务场景有特效.
Redis取得动静扩容/缩容的能力，增减Redis实例对client齐全通明、不须要重启服务，不须要业务方放心 Redis 内存爆掉的问题. 也不必放心申请太大, 造成节约. 业务方也不须要本人保护 Redis。Codis反对程度扩容/缩容，扩容能够间接界面的 “Auto Rebalance” 按钮，缩容只须要将要下线的实例领有的slot迁徙到其它实例，而后在界面上删除下线的group即可。
Codis 采纳 Pre-sharding 的技术来实现数据的分片, 默认分成 1024 个 slots (0-1023), 对于每个Key来说, 通过以下公式确定所属的 Slot Id : SlotId = crc32(key) % 1024。每一个 slot 都会有一个且必须有一个特定的 server group id 来示意这个 slot 的数据由哪个 server group 来提供。数据的迁徙也是以slot为单位的。
二、Twemproxy
Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可承受来自多个程序的拜访，依照路由规定，转发给后盾的各个Redis服务器，再原路返回。该计划很好的解决了单个Redis实例承载能力的问题。当然，Twemproxy自身也是单点，须要用Keepalived做高可用计划。通过Twemproxy能够应用多台服务器来程度扩张redis服务，能够无效的防止单点故障问题。尽管应用Twemproxy须要更多的硬件资源和Redis性能有肯定的损失（Twitter测试约20%），然而可能进步整个零碎的HA也是相当划算的。
疾速，笨重。保护长久的服务器连贯。放弃后端缓存服务器的连接数低。启用申请和响应的流水线操作。反对代理多个服务器。同时反对多个服务器池。跨多个服务器主动分片数据。实现残缺的memcached ascii和Redis协定。通过YAML文件轻松配置服务器池。反对多种散列模式，包含统一的散列和散布。能够配置为在产生故障时禁用节点。通过统计监控端口上显示的统计数据进行可察看性。实用于Linux，* BSD，OS X和SmartOS（Solaris）。
三、Redis Cluster
Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。Redis集群并不反对解决多个Keys的命令，因为这须要在不同的节点间挪动数据，从而达不到像Redis那样的性能,在高负载的状况下可能会导致不可意料的谬误.Redis 集群通过分区来提供肯定水平的可用性，在理论环境中当某个节点宕机或者不可达的状况下持续解决命令。
Redis 集群的劣势:1.主动宰割数据到不同的节点上。2.整个集群的局部节点失败或者不可达的状况下可能持续解决命令。
RedisCluster分片策略
Redis 集群没有并应用传统的一致性哈希来调配数据，而是采纳另外一种叫做哈希槽 (hash slot)的形式来调配的。Redis cluster 默认调配了 16384 个slot，当咱们set一个key 时，会用CRC16算法来取模失去所属的slot，而后将这个Key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。留神的是：必须要3个当前的主节点，否则在创立集群时会失败，咱们在后续会实际到。所以，假如当初有3个节点曾经组成了集群，别离是：A、B、C 三个节点，它们能够是一台机器上的三个端口，也能够是三台不同的服务器。那么，采纳哈希槽 (hash slot)的形式来调配16384个slot 的话，它们三个节点别离承当的slot 区间是：节点A笼罩0－5460;节点B笼罩5461－10922;节点C笼罩10923－16383。
Redis Cluster 节点高低线流程
现有7001,7002,7003,7004,7005,7006六个Redis节点组成的集群，其中7001,7002,7003这三个节点是master节点，而他们的从节点别离是7001master对应7004slave，7002master对应7004slave，7003master对应7006slave依据Redis-Cluster官网倡议slot数为16384，所以7001（0-5460），7002（5461-10922），7003（10923-16383）三个主节点对应的卡槽，当初来模仿一个主节点挂掉的状况，比方7002节点挂掉，依照Redis-cluster原理会选举7002的从节点7005为主节点，持续将7002节点重启，会发现7002会主动退出集群并且是7005的从节点集群增加节点，分为增加主节点，从节点，先增加主节点7007，退出了集群之后发现，并没有卡槽调配到7007上，须要手动对集群进行从新分片迁徙数据，并且手动计算因为目前是4个主节点所以须要调配4096个卡槽给7007，并且要求填写从哪些节点上调配卡槽给新的主节点，如果输出all，集群中左右的主节点都会抽取一部分卡槽，凑够了4096个，挪动到7007上；如果增加从节点，如果没有给定那个主节点–master-id的话，Redis-trib将会将新增的从节点随机到从节点较少的主节点上。
集群节点的移除，与增加一样,分为移除主节点，和从节点，移除主节点如果有数据，须要将卡槽先移到别的主节点上，该主节点上的从节点会调配到卡槽挪动的指标主节点上；移除从节点比拟不便，间接移除。
RedisCluster的slot为什么是16384个
依据CRC16算法（当然这个算法是什么我没有钻研）最多能够调配65535（2^16-1）个slot，65535=65K，用bitmap压缩后就是8K，因为集群之间的节点会有心跳 ，会把8K的数据包都带着，有点节约流量，所以还是倡议用16384个slot而后用bitmap压缩后是2K，个别来看Redis的集群节点不会超过1000个。
上面进入咱们的重点压测啦
既然筹备压测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万GPS，集群的性能损失也不是很多，6节点的集群咱们压到了50多万，只有正当应用Redis，Redis的性能远远够用。
2.Java服务器与Redis的连接数设置不是越多越好，肯定是存在一个性能最好的两头值，这个须要不停的压测与调优能力失去。
3.最初，纸上得来终觉浅，绝知此事要躬行。这次压测收益良多，学会计算本人零碎的压力阈值能力在将来的开发路上越走越宽。
*文/Devin
@得物技术公众号
发表回复