Redis集群初步设计

1、需求背景

最近为满足业务推广活动的需求,需要对Redis集群做容灾,刚开始考虑采用最近比较火的开源方案codis。但考虑到可能会有很多坑,暂不推荐使用,作为后期预研方案。


我们之前一直在采用Twemproxy做数据分片,也运行得比较稳定,所以本次出于容灾的考虑,我们又引入了Redis Sentinel来做主从切换。


但问题又来了,Twemproxy本身不支持平滑重启(也就是所谓的reload)。正常情况下,Twemproxy的servers列表里填写为Redis Master节点IP,而当发生主从角色切换时,需要把老的Master节点IP用新的Master节点IP替换下来,这就会涉及到配置生效的问题,必然要重启Twemproxy服务,就会影响到本Twemproxy下所有被管理的Redis的正常访问,也就是说,影响是全局的,业务当然不可接受。


目前的初步架构如下:

wKioL1U6cVixz8TcAAQtskSyGas406.jpg


2、架构描述

(1)、本次设计,又额外引入了2个开源组件

Etcd:

Etcd是一个高可用的 Key/Value 存储系统,主要用于分享配置和服务发现。
简单:支持 curl 方式的用户 API (HTTP+JSON)
安全:可选 SSL 客户端证书认证
快速:单实例可达每秒 1000 次写操作
可靠:使用 Raft 实现分布式

Ansible:

就不多介绍了,网上一大片,本次主要用它来做远程命令执行。


(2)、说说为什么要这么设计

真不想引入这么多开源组件,麻烦j_0067.gif。说到底,还是为了回避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


祝大家玩的开心!!!j_0057.gif




你可能感兴趣的:(redis,集群,设计)