夏周:阿里云 Redis 容灾体系介绍

夏周:阿里云 Redis 容灾体系介绍
阿里云云栖社区

2018.02.22 阅读 760 评论 0 喜欢 0

摘要: 2018数据库直播大讲堂峰会Redis专场,来自阿里云技术专家夏周为大家介绍了阿里云Redis容灾体系。本文主要分单机房主备容灾、同城双机房容灾和异地多机房容灾&多活三部分进行讲解,其中包括它们的产品定位、架构介绍以及同步优化和内核优化等。

2018数据库直播大讲堂峰会Redis专场,来自阿里云技术专家夏周为大家介绍了阿里云Redis容灾体系。本文主要分单机房主备容灾、同城双机房容灾和异地多机房容灾&多活三部分进行讲解,其中包括它们的产品定位、架构介绍以及同步优化和内核优化等。

以下为精彩视频内容整理:

单机房主备容灾

阿里云Redis双副本容灾形态

阿里云Redis推出了4.0版本,架构上有集群版、标准版和读写分离版。标准版是主备版本,提供最好的Redis命令兼容性,当主节点出现宕机时,HA高可用切换模块会去做故障迁移,将Slave提升为Master,原来的Master恢复后作为新的Slave;集群版架构相对复杂,后端有多个DB节点,每个DB节点架构类似于标准版主备形态,多个DB节点数据需要做路由,就需要多个Proxy节点,集群版还增加一个Configserver,该角色保存了集群间元素信息。当某一个DB节点出现宕机,都会有一个独立的切换模块,并更新Configserver和Proxy的信息;读写分离版只有一个DB节点,一个Master上挂了多个只读节点,当读流量进来时,会根据Proxy判断后端只读节点数量做自动负载均衡,当Master出现宕机时,只读节点需要挂载到新的Master上。

高可用(HA)架构

HA本质上是在做Master故障时、Slave自动提升为主,解决关键问题是判断是否要做切换。HA本身多机房部署,保证自身是高可用的,每个机房会有多个HA模块,每个HA模块负责一部分节点HA切换,当某一个工作HA节点宕机后,另外一些HA节点会做争抢式调度。我们优先同机房HA节点做探测,对于后端Redis的探活逻辑也是有很多种策略的,比如从DNS VIP层面探测后端服务的可用性,也会探测本身DB节点是否存活,以及主机、磁盘是否完好。

独立HA线程优化

阿里云Redis在运营过程中进行了优化,Redis本身是单线程的,当做keys、hgetall等时,Redis很容易出现假死情况,HA可能会误切换。主线程仍然可以做任何操作,我们的优化是专门启动了一个状态线程监测主线程是否存活,也会响应HA模块的探活请求,并探测磁盘可用性。另外,状态线程也会吐出状态信息,保证监控采集不会因为主线程hang住而采集不到信息。

同城双机房容灾

同城双机房容灾的产品定位是:对于业务单元化部署或本身就是单一地域的业务,对容灾有需求,主机房故障时,流量能迅速切换到备机房,主机房恢复时,流量可以切回。

目前Redis同城容灾架构如图。下半部分是Redis本身的架构情况,上半部分是底层传输网络情况。购买Redis后,我们可以取得域名和端口,经过DNS解析走到骨干网,流量再通过LVS集群流到Proxy,最后到后端Master节点。当主机房出现掉电或网络不通时,Redis会有一键切换程序,备机房Slave提升为Master,并调用Configserver接口为Proxy推新的路由信息,也会更新MetaDB的一些信息;底层网络走大小段路由方式,优先选择更为细致的路由,当主机房出现故障时,就不会向主机房上传路由明细信息,骨干网只有备机房大段路由信息,这时就会自动把请求路由到备机房。

同步优化——Log Based Replication

当主机房出现故障时流量切换到备机房,当主机房恢复时都会从备机房做同步。Redis最早提供全量同步机制,整机房全量同步会带来灾难性后果,如果所有的Slave都做全量同步,子进程CPU会跑满,还要疯狂的向恢复的主机房传输的RDB写流量,由于流量太大可能导致备机房服务不可用。

我们目前提供的同步机制对Redis持久化机制做了改造,会有slipshot对应日志位点,AOFbinlog不断做最佳写,当AOFbinlog堆积到一定程度,需要重新做slipshot对其进行清理。AOFbinlog每一个操作写命令会增加一些元数据信息Opid,我们给每一个操作增加一个全局唯一的ID,当Slave出现同步中断时,会通知Master同步Opid位点信息,此时位点已经不是offset信息,Master会判断此Opid是否在AOFbinlog中保存,如果在即异步发送AOFbinlog给Slave,Slave不断从Master本地磁盘读缺失增量,当追上Master同步时,再去内存中把一部分增量拿过来。

总结来看,同步位点借鉴了MySQL GTID,实现全局Opid;性能保证上,查找Opid位点信息是后台线程操作,做到无锁,发送AOFbinlog是异步同步,可以去做限流;同时,我们做到向前、向后兼容,可以做平滑升级、回滚。

Slave和Master的具体通信情况如图,当Slave和Master出现同步中断时,Slave给Master发送PSYNC、runnid、offset和Opid信息,Master根据offset判断backlog是否能满足需求,如果可以满足需求,直接从backlog复制数据发给Slave即可,如果不能满足需求,就会通知Slave开始AOF Psync,Master首先会通过Opid找AOFbinlog中同步位点,然后无锁通知主线程,主线程异步发送AOFbinlog,当Slave追上AOFbinlog后,Master还要同步aof_buf&repl_offset 给Slave。

异地多机房容灾&多活

异地多机房容灾&多活的产品定位是:业务对可用性要求极高,如金融类、部分民生类业务等;允许N-1机房断电,任一机房均能承担所有流量。

异地多活架构如图,上海中心和深圳中心都会有两个Redis集群,可以做到互相同步。底层链路有BLS Manager,上海中心生产一些增量数据,通过Collector写入BLS Tunnel,深圳中心Receiver会从BLS Tunnel中消费增量数据,并写入深圳Master集群,这样,上海中心数据就同步到深圳中心了。同理,深圳中心数据同步到上海中心也是如此。BLS Manager会去做一些调度,比如Collector和Receiver挂掉时,BLS Manager负责拉起或创建新的Collector和Receiver,BLS Manager也会对BLS Tunnel做管理。

内核优化

增量生产

获取增量接口是内核以命令方式原生支持的,是一个标准化get接口,支持现有开源SDK,支持增量过滤,包括库级过滤和key模式匹配过滤。Collector消费增量时,会发送opget opid信息,明确从哪一点开始获取oplog,Redis主线程会创建任务通知后台线程,后台线程基于Opid查找增量位点,无锁通知主线程可以从哪开始读,Redis异步读取AOFbinlog并做解析和封装操作,同时缓存客户端状态,然后回复Collector,Collector下次发送opget opid命令时,就不再需要走上述流程了。

增量消费

增量格式本身兼容Redis协议,目的端接收并且执行就可以了。其中,timestamp做时间点恢复。增量消费要避免两个问题:一是复制回源,不能让A复制给B的再从B复制回A,我们会标识标识oplog来源实例(server_id),如果复制回源,直接丢弃即可;一是环形复制,如何避免C通过B复制的数据再次返回A,我们记录了每一个src_server_id,以及src_server_id在C上max_opid情况,通过判断是否发生环形复制。

本文由云栖志愿小组毛鹤整理,编辑百见

生活 转载请联系作者,并注明出处。

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

春光支付宝

支付宝

春光微信

微信


喜欢  |  0

0条评论