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的好處：
- 對client友好，不需要client都升級為smart client；（否則，所有語言client 都需要支持一遍）
- 加一層proxy可以做更多平台策略；比如在proxy可做 大key、熱key的監控、慢查詢的請求監控、以及接入控制、請求過濾等；
即將發布的 redis 5.0 中有個 feature，作者計划給 redis cluster加一個proxy。
ksarch-saas 對 twemproxy的改造已開源：
https://github.com/ksarch-saas/r3proxy