接受客戶端的請求，根據哈希算法轉發到對應的redis。
優勢:
-開發簡單，對應用程序幾乎透明
——歷史悠久，方案成熟。
缺點:
-代理影響性能
-lvs和twemproxy會有節點性能瓶頸。
-redis擴展很麻煩。
Twitter內部已經放棄了該方案，新使用的架構也不是開源的。
Codis:
動物園管理員:
存儲路由表和代理節點元數據。
分發Codis-Config的命令。
codis-配置:
具有web界面的集成管理工具。
codis-代理:
無狀態代理，兼容Redis協議
對業務透明
Codis-Redis:
基於2.8版本，二次開發。
添加插槽支持和遷移命令
優勢:
-開發簡單，對應用程序幾乎透明
-性能優於Twemproxy
-圖形界面，易於擴展，操作維護方便。
缺點:
-代理仍然會影響性能
-組件太多，需要大量機器資源
redis代碼被修改，導致無法與官方同步，新功能跟進緩慢。
-開發團隊準備基於redis改造提升reborndb。
Redis集群:
P2P模式，無中心化
把鑰匙分成16384槽。
每個實例負責壹部分插槽。
如果客戶端請求不在連接的實例中，該實例將被轉發到相應的實例。
通過Gossip協議同步節點信息
優勢:
-組件壹體化，易於部署並節省機器資源。
-性能優於代理模式
-自動故障切換，插槽遷移中的數據可用性
-官方原創集群方案，保證更新和支持。
缺點:
-架構相對較新，幾乎沒有最佳實踐。
-有限支持多鍵操作(司機可以曲線救國)
-為了提高性能，客戶端需要緩存路由表信息。
-節點發現和重新共享操作不夠自動化。