1、需求背景
最近为满足业务推广活动的需求，需要对Redis集群做容灾，刚开始考虑采用最近比较火的开源方案codis。但考虑到可能会有很多坑，暂不推荐使用，作为后期预研方案。
我们之前一直在采用Twemproxy做数据分片，也运行得比较稳定，所以本次出于容灾的考虑，我们又引入了Redis Sentinel来做主从切换。
但问题又来了，Twemproxy本身不支持平滑重启（也就是所谓的reload）。正常情况下，Twemproxy的servers列表里填写为Redis Master节点IP，而当发生主从角色切换时，需要把老的Master节点IP用新的Master节点IP替换下来，这就会涉及到配置生效的问题，必然要重启Twemproxy服务，就会影响到本Twemproxy下所有被管理的Redis的正常访问，也就是说，影响是全局的，业务当然不可接受。
目前的初步架构如下：
2、架构描述
(1)、本次设计，又额外引入了2个开源组件
Etcd：
Etcd是一个高可用的 Key/Value 存储系统，主要用于分享配置和服务发现。
简单：支持 curl 方式的用户 API (HTTP+JSON)
安全：可选 SSL 客户端证书认证
快速：单实例可达每秒 1000 次写操作
可靠：使用 Raft 实现分布式
Ansible：
就不多介绍了，网上一大片，本次主要用它来做远程命令执行。
(2)、说说为什么要这么设计
真不想引入这么多开源组件，麻烦
。说到底，还是为了回避Twemproxy不支持平滑重启的问题。
我们只需在Twemproxy的地址列表里填写VIP，而每个VIP绑定在每组Redis Master节点上，当主从切换时，将VIP自动绑定到新的Redis Master节点上，这样前端Twemproxy就无需重启，也就不会影响到整个Redis集群，就算有影响，也只是很小的范围。
引入etcd + ansible就是为了实现VIP自动绑定，大致过程如下：
1、当Redis主从角色发生切换时，会根据“sentinel notification-script”参数事先设置好的脚本，自动将新的Master的固定IP注册到etcd服务（可以参考上图）；
2、Ansible服务定期到etcd服务器，以VIP为key去查询每组Redis集群的Master节点所在的最新IP；
3、Ansibe服务将查询到结果，分发到每组Redis集群，进行地址匹配，当发现最新的Master IP与自身IP相同，就将对应的VIP与其绑定。
3、结论
优点就不用说了，下面我们来说说本架构的一些缺点：
(1)、涉及到较多开源组件，可能会增加一些运维成本；
(2)、每组Redis集群绑定一个VIP，会消耗一定量的IP地址；
(3)、官方原版的Sentinel组件用在生产环境的案例并不算多，稳定性有待考验；
(4)、在扩容、缩容时，还是无法避免Twemproxy服务重启的问题；
接下来，会预研一下codis、redis cluster，目前收集到的信息如下：
codis集群部署实战
http://navyaijm.blog.51cto.com/4647068/1637688
codis实现redis分片和在线扩展
http://quenlang.blog.51cto.com/4813803/1636441
Codis 高可用负载均衡群集的搭建与使用
http://liweizhong.blog.51cto.com/1383716/1639918
QQ交流群：
183613045
240361424
祝大家玩的开心！！！
