十余年的文县网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。网络营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整文县建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“文县网站设计”,“文县网站推广”以来，每个客户项目都认真落实执行。

导读：

redis官方号称支持并发11万读操作，并发8万写操作。由于优异的性能和方便的操作，相信很多人都在项目中都使用了Redis，为了不让应用过分的依赖 Redis服务，Redis的作用只作为提升应用并发和降低应用响应时间存在，即使Redis出现异常，应用程序也不应该出现提供服务失败问题，对此拍拍信最近安排了一次全环境的Redis Cluster 宕机演练。

本文作者系拍拍信架构负责人朱荣松和拍拍信架构开发工程师许彬，授权“技术锁话”进行发布。

一、演练过程

Redis 集群环境：

1. 测试环境：

Redis Cluster 配置 ：Redis 3主 3从 一共6个节点。

2. 预发环境：

Redis Cluster 配置 ：Redis 3主 3从 一共6个节点。

下面是我们操作的时间线:

• 第一天

程序运行中关闭任意一台从节点，测试一天均无异常。

• 第二天

程序运行中关闭任意一台从节点，程序未发现异常，测试一天未发现异常。

• 第三天

预发环境有应用发版，出现异常程序无法启动。

……

二、问题描述

首先说明几个前提：

1. 测试与预发环境目前关闭的都是任意一台Redis从节点。

2. 测试环境经过反复测试无问题才开始关闭预发环境节点。

3. 预发环境重启被关闭的Redis节点后异常消失。

4. 连接Redis客户端使用的是Java语言中使用范围较广的Jedis。

那么为什么测试环境在经过反复测试没有问题，到预发环境会出现问题？

三、原理

分析问题前先简单解释下Redis Cluster实现原理。简单来说RedisCluster中内置了 16384 个哈希槽，当需要在 Redis Cluster中存取一个 key或者value时，Redis 客户端先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数( 算法为:crc16(key)mod16384)，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，值得注意的是这个计算key是在哪个槽上的操作是Redis 客户端做的操作，Java中常用的客户端为Jedis 这个也是被Spring推荐的一种客户端。

注: 如果有人好奇为什么Redis Cluster为什么会使用16384也就是2^14个槽。可以查看 Githubhttps://github.com/antirez/redis/issues/2576作者对此进行了解释。

四、分析

首先是查看程序启动异常信息，下图1为程序异常信息。

 图1异常很明显抛出的是连接异常

查看了Jedis的源码后发现初始化Redis Cluster的槽信息时，调用initializeSlotsCache()方法时出现异常。图2 为此方法的具体实现，分析代码发现此代码的目的应该是需要cache Redis Cluster槽信息，由于代码中有break，所以是只需要连接Redis获取一次信息即可。细一看此代码应该是有Bug，Try 的范围没有覆盖到Jedis连接的操作，如果Jedis连接失败直接抛出连接失败异常，此循环会直接退出，与代码实际预期不符合。

图2

由此引发另一个思考，是不是我关闭的节点正好为循环的第一个节点导致此问题。尝试关闭另外一台从节点后程序正常启动。那么Jedis加载的节点顺序是什么，似乎Jedis对节点顺序进行了排序操作。在查看源码后发现Jedis重写了Redis节点配置类的hashCode方法。

图3

图4

下面简单测试下如果配置为:jedis-01.test.com、jedis-02.test.com、jedis-03.test.com、jedis-04.test.com、jedis-05.test.com、jedis-05.test.com输出顺序是什么。

图5

输出结果:

[redis-06.test.com:6379,redis-04.test.com:6379, redis-01.test.com:6379, redis-03.test.com:6379, redis-02.test.com:6379,redis-05.test.com:6379]

也就是说如果关闭redis-06.test.com:6379这台节点，程序就会出现启动失败问题。

五、解决

问题定位后首先去Github上的查看相关问题是否有人遇到，在查询后发现此问题有人在去年11月提了PR解决了此问题，链接如下:

https://github.com/xetorthio/jedis/pull/1633

官方目前释放出了2.10.0-m1和3.0.0-m1中解决了此问题，但是由于不是Release版本使用还得注意。解决的办法为图6，和图2对比可以发现图6对Jedis的实例化也进行了try catch。

图6

六、思考

Redis Cluster由于使用去中心化思想 ，图7 显示了Redis Cluster集群的状态，所以Redis Cluster 中如果有部分节点异常就会导致整个集群异常。

图7

那么问题来了多少节点异常会导致程序读写操作出现异常，下面我们也做了个简单的测试用于统计程序运行中，关闭Redis节点后程序的出错情况，以下测试表1仅供参考。

场景	操作（多节点均同时操作）	Redis写总量	Redis读总量	错误量	总耗时(s)	错误率
程序运行中	关主（关任一主）	100000	100000	3084	100	0.031
	关主（关任一主）	100000	100000	1482	102	0.015
	关主（关任一主）	100000	100000	3053	97.6	0.031
	关从（关任一从）	100000	100000	0	109.2	0
	关从（关任一从）	100000	100000	0	90.1	0
	关从（关任一从）	100000	100000	0	88.9	0
	主从一起关（关任一对）	100000	100000	32613	210.1	0.326
	主从一起关（关任一对）	100000	100000	29148	169.8	0.291
	主从一起关（关任一对）	100000	100000	32410	173.7	0.324
	所有主全关	100000	100000	100000	353.4	1
	所有从全关	100000	100000	0	87.7	0
	只留一台主	100000	100000	100000	357.1	1

表1

从测试结果看，集群Master的选举过程是由Master参与选举的。

1. 如果半数以上 Master 处于关闭状态那么整个集群处于不可用状态。

2. 关闭任意一对主从节点会导致部分（大约为整个集群的1/3）失败。

3. 关闭任意一主，会导致部分写操作失败，是由于从节点不能执行写操作，在Slave升级为Master期间会有少量的失败。

4. 关闭从节点对于整个集群没有影响。

分享文章：RedisCluster宕机引发的事故
标题链接：http://csdahua.cn/article/ishsih.html