多個同構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操作不夠自動化