1 研究背景

分散式快取是各大公司業務系統必不可少的元件，目前市面上開源的分散式快取解決方案主要有redis cluster和codis，在進行了一系列調研之後，redis cluster現階段的模組耦合使得我最後放棄了這一方案，轉向了codis。在使用過程中，發現了一些codis的不足之處。因此筆者在官方codis的基礎上（基於最新版本3.2.2），修改了原始碼，做出了codisX。

1. 真正的彈性伸縮，擴容時只需要在fe中新增server並且自動resharding，無需任何元件重啟
2. fe中可以實時監控各個server的執行狀態，也可以更改master和slave的角色
3. 相容原生的redis操作，業務開發人員無需學習成本
4. 業務開發人員不需要考慮分片問題，就像使用單機一樣使用codis
5. 不同的業務系統可以通過同一套zk的不同路徑去區分（擔心zk效能問題就多餘了，codis正常執行的過程中，無論是proxy連線池還是dashboard都根本不會走zk的）

2 codisX的設計思路

codis的官方作者一開始是想要實現一個KV資料庫，也就是強調資料一致性，是CP的系統，在一組server（包括master和slave）都宕機的情況下，服務是不可用的。但是很多場景快取只是用來加速的，也就是說，對於快取的需求應該是AP的，無需高度的一致性，而是需要滿足高的可用性。在這種情況下，一組server是不需要slave的（我這麼說不是說有slave不行，而是slave的存在沒什麼必要，有那個機器還不如去充當另一個group的master）。當一臺server宕機又恢復之後資料取不到也無所謂。

基於以上思考，就要動手修改codis原始碼了。借鑑了cassandra的設計模式，在slot級別實現了一致性雜湊，一個group的server宕機之後，請求會根據雜湊環打到下一個節點上，根據墨菲定律，最壞的情況是下一個節點的server也掛了，因此在proxy的配置檔案中，提供了最大重試次數的選項，如果超過了這個閾值還是失敗，就向業務系統返回異常，由業務系統自行處理。至於你的系統對快取的需求是CP還是AP的，只需要在dashboard的配置檔案中修改一下配置，指定working mode就可以了。

# Set work mode for codis cluster (only accept 'CP'
 
 & 'AP',default is 'CP').
working_mode = "AP"

注意，在AP模式下，如下圖所示配置各個group的權重，點選confirm，會按照一致性雜湊自動分配

另外，codis的主從讀寫分離規則中，replica group是包含master的。對於redis這種本身就是最終一致性的工具，本來如果你考慮實現讀寫分離的時候，就表明你認為減輕master的壓力比追求資料的強一致性要重要，因此在請求隨機路由的情況下，如果還是可能打到master是不必要的，這一點在codisX中做了改進。

kubernetes應該是現在比較理想的容器管理解決方案了，在官方實現的kubernetes scale方案中，server的伸縮方案還是基於CP的考慮的，前面我們已經說過了，在AP的模式下，scale過程中，group中要一個slave屬於浪費機器的舉動。當然土豪請自動忽略這句話。因此修改了codis基於k8s的scale方案，在叢集指定AP的工作模式下，擴容的時候，ReplicaController只會在新的group中放置一臺server。當然這一切對於使用者來說都是透明的，使用者無需關心這一點，而是通過指令碼自動識別的。

3 總結一下

codisX實現的新功能：

1. 可以提供CP和AP兩種分散式快取服務模式，無論你的業務系統對於把快取當作資料庫使用還是單純為了加速訪問，都可以滿足你的需求
2. 修改了讀寫分離邏輯
3. 修改了基於kubernetes的scale方式，自動根據工作模式去修改擴容的方式，這一切對於運維人員或者使用者來說是完全透明的
4. 其它一些小的修改

目前codisX執行在我們公司的推送和閘道器日誌統計平臺，每天日誌量過億，表現還是可以的。

歡迎各位高手試用和理性吐槽，如果有問題的話，可以找我反饋，我也會進行一些日常的維護