背景
家喻户晓，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
@得物技术公众号