Redis扩展机制

　　　　　　　　　　　　　　　　　　　　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或更高版本

　　代理分片机制引入更多的来回次数并增大延迟

　　需要时间验证其稳定性

　　没有后台界面