redis cluster及codis之間該如何選擇？

09-04

正在搭建redis cluster，可是發現好多人都在用codis，不知道這兩者之間該如何選擇

今天讀了一下劉奇先生的codis介紹豌豆莢分散式Redis的設計與實現，摘抄一下為何不用官方cluster的理由：

說的就是暫時沒有數據證明官方cluster靠譜（目前情況如何？），特別是在各個組件都是全部重寫（如sentinel中的raft）的情況下，難免會有bug。其實codis原理和官方cluster基本一致，但是：

codis是選用了一系列已證明靠譜的方案來構建（如zk選主/存放元數據；採用無狀態proxy，而不是smart client等）
為方便運維提供了一系列工具/介面
再加上公司內部的一定規模應用

所以大家用它更多。

不過個人更期望redis自己的cluster方案成熟，從而能持久傳承，讓大家自己發明的輪子們壽終正寢~

2017年5月，距離redis cluster release已經很久，再來回答一下這個問題。

redis cluster的原理，是基於分片。一個 Redis cluster集群包含 16384 個哈希槽, 任意一個key都可以通過 CRC16(key) % 16384 這個公式計算出應當屬於哪個槽。每個槽應當落在哪個節點上，也是事先定好。這樣，進行任一操作時，首先會根據key計算出對應的節點，然後操作相應的節點就可以了。

所以說，其實cluster跟單點相比，只是多了一個給key計算sharding值的過程，並沒有增加多少複雜度，個人認為完全可以放心使用。像增刪節點、重啟這些對redis本身的操作，和client端對數據的操作，是兩套流程，可以做到互不干擾。關於節點故障，一是有slave，二是即便這一個節點完全掛掉，也只是落在這個節點上的數據不可用，不會有類似「雪崩」這樣的問題影響整個集群。數據的恢復之類的邏輯，也與單點完全一致，是獨立於集群其他部分的。

redis cluster的整個設計是比較簡單的，並沒有引入太多新問題，大部分操作都可以按照單點的操作流程進行操作。至於cluster最終的易用性，其實很大程度上取決client端的代碼可靠性，而jedis現在的代碼也已經很完善了，用起來也比較方便。

關於運維，可以看一下搜狐的cacheCloud, 對cluster的管理現在也比較完善了。

所以，個人覺得，目前cluster完全可以取代codis,tweemproxy在生產環境使用。

好多人用豌豆莢開源的Codis是因為官方的Redis Cluster方案之前一直沒有Release，而Twemproxy又無法平滑的擴容或者縮容，所以很多公司都選擇了已經被生產環境檢驗的Codis；

至於選擇哪種方案，各有利弊吧：

Codis已經被很多公司用於生產環境，而且豆瓣也很給力，一直在維護升級。但作為一個開源項目，不可避免的會有跳票的風險；

官方的Cluster方案已經正式發布，但真正用於生產環境的公司很少，至少國內是。但官方方案有個顯而易見的好處是：會一直維護、更新下去，未來必定會更加成熟、穩定。

Codis很好用的。。就是安裝有點奇怪。

Codis。

Codis是一整套緩存解決方案，包含高可用、數據分片、監控、動態擴態 etc.。

走的是 Apps-&>代理-&>redis cluster，一定規模後基本都採用這種方式。

Redis cluster

剛出來短期不成熟，生產不建議用。

單純的數據分片，無其他功能。

走的是 Apps-&>redis server jump redis server，大規模後不方便統一管理。

推薦Codis。