1. Twemproxy – Twitter
2. Codis – 豌豆莢
3. Redis Cluster – 官方

Twemproxy:

    多個同構twemproxy（配置相同）同時工作，
    接受客戶端的請求，根據hash演算法，轉發給對應的redis。

優點：
- 開發簡單，對應用幾乎透明
- 歷史悠久，方案成熟

缺點：
- 代理影響效能
- lvs和twemproxy會有節點效能瓶頸
- redis擴容非常麻煩
- twitter內部已放棄使用該方案，新使用的架構未開源

Codis：

ZooKeeper：
    存放路由表和代理節點元資料
    分發Codis-Config的命令
Codis-Config :
    整合管理工具，有web介面
Codis-Proxy :
    無狀態代理，相容Redis協議
    對業務透明
Codis-Redis：
    基於2.8版本，二次開發
    加入slot支援和遷移命令
 

優點：
- 開發簡單，對應用幾乎透明
- 效能比Twemproxy好
- 有圖形化介面，擴容容易，運維方便

缺點：
- 代理依舊影響效能
- 元件過多，需要很多機器資源
- 修改了redis程式碼，導致和官方無法同步，新特性跟進緩慢
- 開發團隊準備主推基於redis改造的reborndb

Redis Cluster：

P2P模式，無中心化
把key分成16384個slot
每個例項負責一部分slot
客戶端請求若不在連線的例項，該例項會轉發給對應的例項。
通過Gossip協議同步節點資訊

優點：
- 元件all-in-box，部署簡單，節約機器資源
- 效能比proxy模式好
- 自動故障轉移、Slot遷移中資料可用
- 官方原生叢集方案，更新與支援有保障

缺點：
- 架構比較新，最佳實踐較少
- 多鍵操作支援有限（驅動可以曲線救國）
- 為了效能提升，客戶端需要快取路由表資訊
- 節點發現、reshard操作不夠自動化