Redis扩展机制扫盲
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
关于Redis的Avalibility解决方案有很多，比如Twemproxy，Codis，
一.Twemproxy（Twitter）
1>.代理分配机制
2>.优点
非常稳定，企业级解决方案。
3>.缺点
单点故障
需依赖第三方软件，如Keepalived。
无法平滑地横向扩展
没有后台界面
代理分片及政治引入更多的来回次数并增大延迟
单核模式，无法充分利用多喝，除非多实例
Twitter官方内部不在继续使用twemproxy解决方案
二.Codis（豌豆荚实现开源的）
1>.代理分配机制
2>.2014年11月开源
3>.基于Go以及C语言开发
4>.优点
非常稳定，企业级方案
数据自动平衡
高性能
简单的测试显示较Twemproxy快一倍
善用多核CPU
简单（没有Paxos类的协调机制，没有主从复制）
有后台界面
5>.缺点
代理分配机制更引入更多的来回次数并增大延迟
需要第三方软件支持协调机制（目前支持zookeeper及Etcd）
不支持主从复制，需要另外实现
Codis采用了Proxy的方案，所以必然会带来单机性能的损失（经测试，在不开pipeline的情况下，大概会损失40%左右的性能）
三.Redis Cluster（官方）
1>.官方实现
2>.需要Redis 3.0或更高版本
3>.优点
无中心的P2P Gossip分散式模式
更少的来回次数并降低延迟
自动于多个Redis节点进行分片
不需要第三方软件支持协调机制
4>.缺点
依赖于Redis 3.0或更高版本
没有后台界面
需要智能客户端（Redis客户端必须支持Redis Cluster架构）
较Codis有更多的维护升级成本
四.Cerberus（芒果TV）
1>.优点
数据自动平衡
本身实现了Redis的Smart Client
支持读写分离
2>.缺点
依赖Redis 3.0或更高版本
代理分片机制引入更多的来回次数并增大延迟
需要时间验证其稳定性
没有后台界面