多个同构twemproxy（配置相同）同时工作， 接受客户端的请求，根据hash算法，转发给对应的redis。
优点： - 开发简单，对应用几乎透明 - 历史悠久，方案成熟
缺点： - 代理影响性能 - lvs和twemproxy会有节点性能瓶颈 - redis扩容非常麻烦 - twitter内部已放弃使用该方案，新使用的架构未开源
ZooKeeper： 存放路由表和代理节点元数据 分发Codis-Config的命令 Codis-Config : 集成管理工具，有web界面 Codis-Proxy : 无状态代理，兼容Redis协议 对业务透明 Codis-Redis： 基于2.8版本，二次开发 加入slot支持和迁移命令
优点： - 开发简单，对应用几乎透明 - 性能比Twemproxy好 - 有图形化界面，扩容容易，运维方便
缺点： - 代理依旧影响性能 - 组件过多，需要很多机器资源 - 修改了redis代码，导致和官方无法同步，新特性跟进缓慢 - 开发团队准备主推基于redis改造的reborndb
P2P模式，无中心化 把key分成16384个slot 每个实例负责一部分slot 客户端请求若不在连接的实例，该实例会转发给对应的实例。 通过Gossip协议同步节点信息
优点： - 组件all-in-box，部署简单，节约机器资源 - 性能比proxy模式好 - 自动故障转移、Slot迁移中数据可用 - 官方原生集群方案，更新与支持有保障
缺点： - 架构比较新，最佳实践较少 - 多键操作支持有限（驱动可以曲线救国） - 为了性能提升，客户端需要缓存路由表信息 - 节点发现、reshard操作不够自动化
