一，公司现在正在使用的集群方案（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 信息，并提供分布式锁等服务。

    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要低一些