一，公司现在正在使用的集群方案（redis+sentinel）
通过多个Sentinel一起监控redis集群，检测到master不可用时，通过投票来决定master是否需要切换。
Sentinel 之间互相检测（通过在共同检测的master中写入信息来进行），Sentinel
只需要配置master节点，自动通过master来获取已经连接的slave列表。当其中的某一个Sentinel
检测到master宕机之后，标示master为SDOWN，向其他的Sentinel 发送SENTINEL
is-master-down-by-addr命令来进行投票，投票确认之后标识为ODOWN，开始选择一个新的master，并且进行切换。
缺点：
1． 没有合适的客户端，需要自己处理各种事件。
2． 目前还没有release。
二，由Twitter开源的Twemproxy集群方案
主要是由Twemproxy作为代理，来接受多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回，这个方案解决了单个Redis实例承载能力的问题。
当然，Twemproxy本身也是单点，需要用keepalived做高可用方案。
缺点：
无法平滑地扩容、缩容。这样就导致了在业务量突增，需增加Redis服务器；业务量萎缩，需要减少Redis服务器，对于Twemproxy而言，基本上都很难操作。
三，基于Go和C开发的codis redis(由豌豆荚开源）
（1）体系架构
Codis引入了Group的概念，每个Group包括1个Redis Master及至少一个Redis Slave,这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可以通过Dashboard"自助式"切换到Slave，而不需要小心翼翼地修改程序配置文件。
Codis还支持数据热迁移（Auto Rebalance） ，出品方修改了Redis Server源码，并称之为Codis Server）。
Codis采用预先分片（Pre_Sharding)机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server)，这些路由信息保存在zookeeper中，Zookeeper还维护Codis Server Group 信息，并提供分布式锁等服务。
（2）使用技巧、注意事项
1，无缝迁移Twemproxy
使用Codis-port工具，可以实现同步的Twemproxy底下的Rdis数据到你的Codis集群，同步完成后，只需要修改一下程序配置文件，将Twemproxy的地址改成Codis的地址即可。
2，支持Java程序的HA
Codis提供一个Java客户端，并称之为Jodis，这样，如果单个Codis Proxy宕掉，Jodis自动发现，并自动规避之，使业务不受影响。
3，支持Pipeline
Pipeline使得客户端可以发出一批请求，并一次性获得这批请求的返回结果，这提升了Codis的想象空间。
4，Codis 不负责主从同步
Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性
5，要改进的地方
加pipeline参数后，Value长度如果较大，性能反而比Twemproxy要低一些