禧云Redis跨机房双向同步实践 _Rotter

一、项目介绍
Rotter是禧云自主研发的跨机房redis双向同步解决方案（下文简称为方案），具有零侵入、高吞吐量、低延时、高堆积能力等特点。当前版本支持Sentinel模式和单点模式Redis架构。从2019年Q2上线至今，服务于三个独立业务线，线上运行稳定，同步延时基本在50ms以内。
1.1 系统架构
整个Redis跨机房双向同步系统分为三层：

控制台Manager
节点发现和数据传输层（ZK+Redis）
数据同步层Rotter

【禧云Redis跨机房双向同步实践】系统架构如图1-1

文章插图
图1-1
其中，

Manager负责任务配置、数据展示、监控报警等，各机房独立部署；
ZK为跨机房集群，A机房为Leader节点，B机房为Follow节点。ZK在方案中负责Rotter节点的注册发现和任务调度。
多活Redis在方案中扮演数据队列的角色，降低了Manager和Rotter节点之间的耦合度。
Rotter是Redis同步任务的执行者，包含replicator和sync两个角色。
replicator是国人开源的基于JAVA语言的redis主从协议实现者redis-replicator，负责解析redis节点指令。
sync负责redis指令跨机房写入，处理同步回环，同步指令监控等。

1.2 同步流程
Rotter中采用链式处理同步数据，任何一个Filter返回失败，该指令将不会同步。链式流程如图1-2

文章插图
图1-2

ParseEventFilter：格式化同步指令；生成指令回环校验key；赋值指令所属DB；过滤Rotter自身产生的指令
DBFilter：过滤掉不需要同步的DB
KeyFilter：过滤掉不需要同步的KEY
CircleSyncFilter：过滤掉回环指令和删除保护指令
MultiThreadFilter：多线程分发，提高同步效率
OvertimeFilter：经过队列积压，判断该指令是否已经过期
DeleteKeyFilter：生成删除保护KEY
RateLimitFilter：限流，包括带宽和指令数
SendTargetFilter：执行目标redis写入
MonitorFilter：监控和上报正在同步的指令
ComputeRateFilter：计算同步速率、带宽、队列积压长度等

二、背景&目标
2.1 背景
异地多活系统自2018年Q2上线以来，各核心业务系统都已陆续接入异地双活架构。异地多活已经成为我司保障服务高可用的常规武器。在我司的异地双活解决方案中，首先通过动态域名和阿里云全局流量管理服务达到用户流量的初步划分，然后在Nginx层根据流量规则对用户流量精准转发，确保同一个用户的请求能够稳定地请求到同一个机房，从而保证两个机房不会同时修改同一份数据。
即便如此，可靠的跨机房的数据同步仍然是双活方案最基本要求。多活业务依赖非多活业务数据或者流量调度时都依赖数据同步服务。MySQL层的数据同步是通过阿里巴巴开源的otter完成的，Redis的跨机房双向数据同步业内缺少合适解决方案。
没有Redis双向同步，往往需要牺牲业务的时效性，或者业务系统需要写一些额外的代码来处理缓存数据缺失的情况；另外，用户会话数据需要落到MySQL中来确保流量调度时用户无感知。
2.2 目标
基于背景部分阐述，我们可以知道，我司的跨机房Redis同步方案是跨机房异地多活方案的一个延伸，最根本的诉求就是让我司的业务不会因为接入多活系统受到限制，让我们工程师可以像实现单机房业务一样实现多机房业务。
所以，在项目启动之初就定下以下目标：