Redis Cluster 宕機引發(fā)的事故

一、演練過程

Redis 集群環(huán)境：

1. 測試環(huán)境：

Redis Cluster 配置 ：Redis 3主 3從 一共6個節(jié)點。

2. 預(yù)發(fā)環(huán)境：

Redis Cluster 配置 ：Redis 3主 3從 一共6個節(jié)點。

下面是我們操作的時間線:

• 第一天

程序運行中關(guān)閉任意一臺從節(jié)點，測試一天均無異常。

• 第二天

程序運行中關(guān)閉任意一臺從節(jié)點，程序未發(fā)現(xiàn)異常，測試一天未發(fā)現(xiàn)異常。

• 第三天

預(yù)發(fā)環(huán)境有應(yīng)用發(fā)版，出現(xiàn)異常程序無法啟動。

……

二、問題描述

首先說明幾個前提：

1. 測試與預(yù)發(fā)環(huán)境目前關(guān)閉的都是任意一臺Redis從節(jié)點。

2. 測試環(huán)境經(jīng)過反復(fù)測試無問題才開始關(guān)閉預(yù)發(fā)環(huán)境節(jié)點。

3. 預(yù)發(fā)環(huán)境重啟被關(guān)閉的Redis節(jié)點后異常消失。

4. 連接Redis客戶端使用的是Java語言中使用范圍較廣的Jedis。

那么為什么測試環(huán)境在經(jīng)過反復(fù)測試沒有問題，到預(yù)發(fā)環(huán)境會出現(xiàn)問題？

三、原理

分析問題前先簡單解釋下Redis Cluster實現(xiàn)原理。簡單來說Redis Cluster中內(nèi)置了 16384 個哈希槽，當(dāng)需要在 Redis Cluster中存取一個 key或者value時，Redis 客戶端先對 key 使用 crc16 算法算出一個結(jié)果，然后把結(jié)果對 16384 求余數(shù)( 算法為:crc16(key)mod 16384)，這樣每個 key 都會對應(yīng)一個編號在 0-16383 之間的哈希槽，值得注意的是這個計算key是在哪個槽上的操作是Redis 客戶端做的操作，Java中常用的客戶端為Jedis 這個也是被Spring推薦的一種客戶端。

注: 如果有人好奇為什么Redis Cluster為什么會使用16384也就是2^14個槽?？梢圆榭?Github https://github.com/antirez/redis/issues/2576作者對此進行了解釋。

四、分析

首先是查看程序啟動異常信息，下圖1為程序異常信息。

 圖1異常很明顯拋出的是連接異常

查看了Jedis的源碼后發(fā)現(xiàn)初始化Redis Cluster的槽信息時，調(diào)用initializeSlotsCache()方法時出現(xiàn)異常。圖2 為此方法的具體實現(xiàn)，分析代碼發(fā)現(xiàn)此代碼的目的應(yīng)該是需要cache Redis Cluster槽信息，由于代碼中有break，所以是只需要連接Redis獲取一次信息即可。細一看此代碼應(yīng)該是有Bug，Try 的范圍沒有覆蓋到Jedis連接的操作，如果Jedis連接失敗直接拋出連接失敗異常，此循環(huán)會直接退出，與代碼實際預(yù)期不符合。

圖2

由此引發(fā)另一個思考，是不是我關(guān)閉的節(jié)點正好為循環(huán)的第一個節(jié)點導(dǎo)致此問題。嘗試關(guān)閉另外一臺從節(jié)點后程序正常啟動。那么Jedis加載的節(jié)點順序是什么，似乎Jedis對節(jié)點順序進行了排序操作。在查看源碼后發(fā)現(xiàn)Jedis重寫了Redis節(jié)點配置類的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

輸出結(jié)果:

[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]

也就是說如果關(guān)閉redis-06.test.com:6379這臺節(jié)點，程序就會出現(xiàn)啟動失敗問題。

五、解決

問題定位后首先去Github上的查看相關(guān)問題是否有人遇到，在查詢后發(fā)現(xiàn)此問題有人在去年11月提了PR解決了此問題，鏈接如下:

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

官方目前釋放出了2.10.0-m1和3.0.0-m1中解決了此問題，但是由于不是Release版本使用還得注意。解決的辦法為圖6，和圖2對比可以發(fā)現(xiàn)圖6對Jedis的實例化也進行了try catch。

圖6

六、思考

Redis Cluster由于使用去中心化思想 ，圖7 顯示了Redis Cluster集群的狀態(tài)，所以Redis Cluster 中如果有部分節(jié)點異常就會導(dǎo)致整個集群異常。

圖7

那么問題來了多少節(jié)點異常會導(dǎo)致程序讀寫操作出現(xiàn)異常，下面我們也做了個簡單的測試用于統(tǒng)計程序運行中，關(guān)閉Redis節(jié)點后程序的出錯情況，以下測試表1僅供參考。

表1

從測試結(jié)果看，集群Master的選舉過程是由Master參與選舉的。

1. 如果半數(shù)以上 Master 處于關(guān)閉狀態(tài)那么整個集群處于不可用狀態(tài)。

2. 關(guān)閉任意一對主從節(jié)點會導(dǎo)致部分（大約為整個集群的1/3）失敗。

3. 關(guān)閉任意一主，會導(dǎo)致部分寫操作失敗，是由于從節(jié)點不能執(zhí)行寫操作，在Slave升級為Master期間會有少量的失敗。

4. 關(guān)閉從節(jié)點對于整個集群沒有影響。