大廠們的 redis 集羣方案

redis 集羣方案主要有兩類，一是使用類 codis 的架構，按組劃分，實例之間互相獨立；
另外一套是基於官方的 redis cluster 的方案；下面分別聊聊這兩種方案；

類 codis 架構

這套架構的特色：

• 分片算法：基於 slot hash桶；
• 分片實例之間相互獨立，每組 一個master 實例和多個slave；
• 路由信息存放到第三方存儲組件，如 zookeeper 或etcd
• 旁路組件探活

使用這套方案的公司：
阿里雲： ApsaraCache, RedisLabs、京東、百度等

codis

slots 方案：劃分了 1024個slot， slots 信息在 proxy層感知； redis 進程中維護本實例上的全部key的一個slot map；

遷移過程當中的讀寫衝突處理：
最小遷移單位爲key；
訪問邏輯都是先訪問 src 節點，再根據結果判斷是否須要進一步訪問 target 節點；

• 訪問的 key 還未被遷移：讀寫請求訪問 src 節點，處理後訪問：
• 訪問的 key 正在遷移：讀請求訪問 src 節點後直接返回；寫請求沒法處理，返回 retry
• 訪問的 key 已被遷移(或不存在）：讀寫請求訪問 src 節點，收到 moved 回覆，繼續訪問 target 節點處理

阿里雲

AparaCache 的單機版已開源(開源版本中不包含slot等實現)，集羣方案細節未知；ApsaraCache

百度 BDRP 2.0

主要組件：
proxy，基於twemproxy 改造，實現了動態路由表；
redis內核： 基於2.x 實現的slots 方案；
metaserver：基於redis實現，包含的功能：拓撲信息的存儲 & 探活；
最多支持1000個節點；

slot 方案：
redis 內核中對db劃分，作了16384個db； 每一個請求到來，首先作db選擇；

數據遷移實現：
數據遷移的時候，最小遷移單位是slot，遷移中整個slot 處於阻塞狀態，只支持讀請求，不支持寫請求；
對比 官方 redis cluster/ codis 的按key粒度進行遷移的方案：按key遷移對用戶請求更爲友好，但遷移速度較慢；這個按slot進行遷移的方案速度更快；

京東

主要組件：
proxy: 自主實現，基於 golang 開發；
redis內核：基於 redis 2.8
configServer(cfs)組件：配置信息存放；
scala組件：用於觸發部署、新建、擴容等請求；
mysql：最終全部的元信息及配置的存儲；
sentinal（golang實現）：哨兵，用於監控proxy和redis實例，redis實例失敗後觸發切換；

slot 方案實現：
在內存中維護了slots的map映射表；

數據遷移：
基於 slots 粒度進行遷移；
scala組件向dst實例發送命令告知會接受某個slot；
dst 向 src 發送命令請求遷移，src開啓一個線程來作數據的dump，將這個slot的數據整塊dump發送到dst（未加鎖，只讀操做）
寫請求會開闢一塊緩衝區，全部的寫請求除了寫原有數據區域，同時雙寫到緩衝區中。
當一個slot遷移完成後，把這個緩衝區的數據都傳到dst，當緩衝區爲空時，更改本分片slot規則，再也不擁有該slot，後續再請求這個slot的key返回moved；
上層proxy會保存兩份路由表，當該slot 請求目標實例獲得 move 結果後，更新拓撲；

跨機房：跨機房使用主從部署結構；沒有多活，異地機房做爲slave；

基於官方 redis cluster 的方案

和上一套方案比，全部功能都集成在 redis cluster 中，路由分片、拓撲信息的存儲、探活都在redis cluster中實現；各實例間經過 gossip 通訊；這樣的好處是簡單，依賴的組件少，應對400個節點之內的場景沒有問題（按單實例8w read qps來計算，可以支持 200 * 8 = 1600w 的讀多寫少的場景）；但當須要支持更大的規模時，因爲使用 gossip協議致使協議之間的通訊消耗太大，redis cluster 再也不合適；

使用這套方案的有：AWS, 百度貼吧

官方 redis cluster

數據遷移過程：
基於 key粒度的數據遷移；
遷移過程的讀寫衝突處理：
從A 遷移到 B;

• 訪問的 key 所屬slot 不在節點 A 上時，返回 MOVED 轉向，client 再次請求B；
• 訪問的 key 所屬 slot 在節點 A 上，但 key 不在 A上， 返回 ASK 轉向，client再次請求B；
• 訪問的 key 所屬slot 在A上，且key在 A上，直接處理；（同步遷移場景：該 key正在遷移，則阻塞）

AWS ElasticCache

ElasticCache 支持主從和集羣版、支持讀寫分離；
集羣版用的是開源的Redis Cluster，未作深度定製；

百度貼吧的ksarch-saas：

基於redis cluster + twemproxy 實現；後被 BDRP 吞併；
twemproxy 實現了 smart client 功能；使用 redis cluster後還加一層 proxy的好處：

1. 對client友好，不須要client都升級爲smart client；（不然，全部語言client 都須要支持一遍）
2. 加一層proxy能夠作更多平臺策略；好比在proxy可作 大key、熱key的監控、慢查詢的請求監控、以及接入控制、請求過濾等；

即將發佈的 redis 5.0 中有個 feature，做者計劃給 redis cluster加一個proxy。

ksarch-saas 對 twemproxy的改造已開源：
https://github.com/ksarch-saas/r3proxy