導(dǎo)讀：
Redis官方號稱支持并發(fā)11萬讀操作，并發(fā)8萬寫操作。由于優(yōu)異的性能和方便的操作，相信很多人都在項(xiàng)目中都使用了Redis，為了不讓應(yīng)用過分的依賴 Redis服務(wù)，Redis的作用只作為提升應(yīng)用并發(fā)和降低應(yīng)用響應(yīng)時(shí)間存在，即使Redis出現(xiàn)異常，應(yīng)用程序也不應(yīng)該出現(xiàn)提供服務(wù)失敗問題，對此拍拍信最近安排了一次全環(huán)境的Redis Cluster 宕機(jī)演練。
本文作者系拍拍信架構(gòu)負(fù)責(zé)人朱榮松和拍拍信架構(gòu)開發(fā)工程師許彬，授權(quán)“技術(shù)鎖話”進(jìn)行發(fā)布。
Redis 集群環(huán)境：
1. 測試環(huán)境：
Redis Cluster 配置 ：Redis 3主 3從 一共6個(gè)節(jié)點(diǎn)。
2. 預(yù)發(fā)環(huán)境：
Redis Cluster 配置 ：Redis 3主 3從 一共6個(gè)節(jié)點(diǎn)。
下面是我們操作的時(shí)間線:
第一天
程序運(yùn)行中關(guān)閉任意一臺從節(jié)點(diǎn)，測試一天均無異常。
第二天
程序運(yùn)行中關(guān)閉任意一臺從節(jié)點(diǎn)，程序未發(fā)現(xiàn)異常，測試一天未發(fā)現(xiàn)異常。
第三天
預(yù)發(fā)環(huán)境有應(yīng)用發(fā)版，出現(xiàn)異常程序無法啟動(dòng)。
……
1. 測試與預(yù)發(fā)環(huán)境目前關(guān)閉的都是任意一臺Redis從節(jié)點(diǎn)。
2. 測試環(huán)境經(jīng)過反復(fù)測試無問題才開始關(guān)閉預(yù)發(fā)環(huán)境節(jié)點(diǎn)。
3. 預(yù)發(fā)環(huán)境重啟被關(guān)閉的Redis節(jié)點(diǎn)后異常消失。
4. 連接Redis客戶端使用的是Java語言中使用范圍較廣的Jedis。
那么為什么測試環(huán)境在經(jīng)過反復(fù)測試沒有問題，到預(yù)發(fā)環(huán)境會出現(xiàn)問題？
分析問題前先簡單解釋下Redis Cluster實(shí)現(xiàn)原理。簡單來說Redis Cluster中內(nèi)置了 16384 個(gè)哈希槽，當(dāng)需要在 Redis Cluster中存取一個(gè) key或者value時(shí)，Redis 客戶端先對 key 使用 crc16 算法算出一個(gè)結(jié)果，然后把結(jié)果對 16384 求余數(shù)( 算法為:crc16(key)mod 16384)，這樣每個(gè) key 都會對應(yīng)一個(gè)編號在 0-16383 之間的哈希槽，值得注意的是這個(gè)計(jì)算key是在哪個(gè)槽上的操作是Redis 客戶端做的操作，Java中常用的客戶端為Jedis 這個(gè)也是被Spring推薦的一種客戶端。
注: 如果有人好奇為什么Redis Cluster為什么會使用16384也就是2^14個(gè)槽?？梢圆榭?Github https://github.com/antirez/redis/issues/2576作者對此進(jìn)行了解釋。
圖1異常很明顯拋出的是連接異常
查看了Jedis的源碼后發(fā)現(xiàn)初始化Redis Cluster的槽信息時(shí)，調(diào)用initializeSlotsCache()方法時(shí)出現(xiàn)異常。圖2 為此方法的具體實(shí)現(xiàn)，分析代碼發(fā)現(xiàn)此代碼的目的應(yīng)該是需要cache Redis Cluster槽信息，由于代碼中有break，所以是只需要連接Redis獲取一次信息即可。細(xì)一看此代碼應(yīng)該是有Bug，Try 的范圍沒有覆蓋到Jedis連接的操作，如果Jedis連接失敗直接拋出連接失敗異常，此循環(huán)會直接退出，與代碼實(shí)際預(yù)期不符合。
圖2
由此引發(fā)另一個(gè)思考，是不是我關(guān)閉的節(jié)點(diǎn)正好為循環(huán)的第一個(gè)節(jié)點(diǎn)導(dǎo)致此問題。嘗試關(guān)閉另外一臺從節(jié)點(diǎn)后程序正常啟動(dòng)。那么Jedis加載的節(jié)點(diǎn)順序是什么，似乎Jedis對節(jié)點(diǎn)順序進(jìn)行了排序操作。在查看源碼后發(fā)現(xiàn)Jedis重寫了Redis節(jié)點(diǎn)配置類的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é)點(diǎn)，程序就會出現(xiàn)啟動(dòng)失敗問題。
問題定位后首先去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的實(shí)例化也進(jìn)行了try catch。
圖6
六、思考
圖7
那么問題來了多少節(jié)點(diǎn)異常會導(dǎo)致程序讀寫操作出現(xiàn)異常，下面我們也做了個(gè)簡單的測試用于統(tǒng)計(jì)程序運(yùn)行中，關(guān)閉Redis節(jié)點(diǎn)后程序的出錯(cuò)情況，以下測試表1僅供參考。
場景 | 操作（多節(jié)點(diǎn)均同時(shí)操作） | Redis寫總量 | Redis讀總量 | 錯(cuò)誤量 | 總耗時(shí)(s) | 錯(cuò)誤率 |
程序運(yùn)行中 | 關(guān)主（關(guān)任一主） | 100000 | 100000 | 3084 | 100 | 0.031 |
關(guān)主（關(guān)任一主） | 100000 | 100000 | 1482 | 102 | 0.015 | |
關(guān)主（關(guān)任一主） | 100000 | 100000 | 3053 | 97.6 | 0.031 | |
關(guān)從（關(guān)任一從） | 100000 | 100000 | 0 | 109.2 | 0 | |
關(guān)從（關(guān)任一從） | 100000 | 100000 | 0 | 90.1 | 0 | |
關(guān)從（關(guān)任一從） | 100000 | 100000 | 0 | 88.9 | 0 | |
主從一起關(guān)（關(guān)任一對） | 100000 | 100000 | 32613 | 210.1 | 0.326 | |
主從一起關(guān)（關(guān)任一對） | 100000 | 100000 | 29148 | 169.8 | 0.291 | |
主從一起關(guān)（關(guān)任一對） | 100000 | 100000 | 32410 | 173.7 | 0.324 | |
所有主全關(guān) | 100000 | 100000 | 100000 | 353.4 | 1 | |
所有從全關(guān) | 100000 | 100000 | 0 | 87.7 | 0 | |
只留一臺主 | 100000 | 100000 | 100000 | 357.1 | 1 |
表1
從測試結(jié)果看，集群Master的選舉過程是由Master參與選舉的。
1. 如果半數(shù)以上 Master 處于關(guān)閉狀態(tài)那么整個(gè)集群處于不可用狀態(tài)。
2. 關(guān)閉任意一對主從節(jié)點(diǎn)會導(dǎo)致部分（大約為整個(gè)集群的1/3）失敗。
3. 關(guān)閉任意一主，會導(dǎo)致部分寫操作失敗，是由于從節(jié)點(diǎn)不能執(zhí)行寫操作，在Slave升級為Master期間會有少量的失敗。
4. 關(guān)閉從節(jié)點(diǎn)對于整個(gè)集群沒有影響。
重慶分公司
重慶分公司
