分类： 数据库开发技术
2022-09-28 10:04:45
公司基于业务发展以及战略部署，需要实现在多个数据中心单元化部署，一方面可以实现多数据中心容灾，另外可以提升用户请求访问速度。需要保证多数据中心容灾或者实现用户就近访问的话，需要各个数据中心拥有一致的全量数据，如果真正实现用户就近读写，也就是实现真正的业务异地多活，数据同步是异地多活的基础，这就需要多数据中心间数据能够双向同步。
原生 redis 并没有提供跨机房的主主同步机制，仅支持主从同步；如果仅利用 redis 的主从数据同步机制，只能将主节点与从节点部署在不同的机房。当主节点所在机房出现故障时，从节点可以升级为主节点，应用可以持续对外提供服务。但这种模式下，若要写数据，则只能通过主节点写，异地机房无法实现就近写入，所以不能做到真正的异地多活，只能做到备份容灾。而且机房故障切换时，需要运维手动介入。
因此，想要实现主主同步机制，需要同步工具模拟从节点方式，将本地机房中数据同步到其他机房，其他机房亦如此。同时，使用同步工具实现跨数据中心数据同步，会遇到以下一些问题。
数据回环的意思是，A 机房就近写入的数据，通过同步工具同步到 B 机房后，然后又通过 B 机房同步工具同步回 A 机房了。所以在同步的过程中需要识别本地就近写入的数据还是其他数据中心同步过来的数据，只有本地就近写入的数据需要同步到其他数据中心。
同步过程中的命令可能因断点续传等原因导致重复同步了，此时需要保证同一命令多次执行保证幂等。
以双写冲突为例，如下图所示：
DC1 写入 set a 1，同时 DC2 写入 set a 2，当这两条命令通过同步工具同步到对方机房时，导致{BANNED}最佳终 DC1 中保存的 a 为 2，DC2 中保存的 a 为 1，也就是说两个机房{BANNED}最佳终数据不一致。
针对瞬时的断开重连、从节点重启等场景，redis 为了提高该场景下的主从同步效率，在主节点中增加了环形复制缓冲区，主节点往从节点写数据的同时也往复制缓冲区中也写入一份数据，当从节点断开重连时，则只需要通过复制缓冲区把断开期间新增的增量数据发送给从节点即可，避免了全量同步，提升了这些场景下的同步效率。
但是，该内存复制缓冲区一般来说不会太大，生产目前默认设置为 64M，跨数据中心同步场景下，网络环境复杂，断线的频率和时长可能比同机房更频繁和更长；同时，跨数据中心同步数据也是为了机房级故障容灾，所以要求能够支持更长时间的断点续传，无限增大内存复制缓冲区大小显然不是一个好主意。
下面来看看我们支持 redis 跨数据中心同步的优化工作。
为了支持异地多活场景，我们对原生 redis 代码进行了优化改造，主要包括以下几个方面：
为了支持更高效的断点续传，以及为了解决数据回环问题，我们在 redis 主节点中对每条需要同步给从节点的命令（大部分为写命令）增加了 id，并且扩展了 RESP 协议，在每条相关命令的头部增加了形如 #{id}\r\n 形式的协议。
本地业务客户端写入的数据依然遵循原生 RESP 协议，主节点执行完命令后，同步到从节点的写命令在同步前会进行协议扩展，增加头部 id 协议；非本地业务客户端（即来自其他数据中心同步）写入的数据均使用扩展的 RESP 协议。
为了支持更长时间的断点续传，容忍长时间的机房级故障，本地业务客户端写入的写命令在进行协议扩展后，会顺序写入日志文件，同时生成对应的索引文件；为了减少日志文件大小，以及提高通过日志文件断点续传的效率，来自其他数据中心同步过来的数据不写入日志文件中。
原生 redis 数据同步分为全量同步和部分同步，并且每个主节点有一个内存环形复制缓冲区；初次同步使用全量同步，断点续传时使用部分同步，即先尝试从主节点环形复制缓冲区中进行同步，同步成功的话则同步完缓冲区中的数据后即可进行增量数据同步，如果不成功，则仍然需要先进行全量同步再增量同步。
由于全量同步需要生成一个子进程，并且在子进程中生成一个 RDB 文件，所以对主节点性能影响比较大，我们应该尽量减少全量同步的次数。
为了减少全量同步的次数，我们对 redis 同步流程进行改造，当部分同步中无法使用环形复制缓冲区完成同步时，增加先尝试使用日志 rlog 进行同步，如果同步成功，则同步完日志中数据后即可进行增量同步，否则需要先进行全量同步。
分为索引文件与日志文件，均采用顺序写的方式，提高性能，经测试与原生 redis 开启 aof 持久化性能一致；但是 rlog 会定期删除，原生 redis 为了防止 aof 文件无限膨胀，会定期通过子进程执行 aof 文件重写，这个对主节点性能比较大，所以实质上 rlog 对 redis 的性能相对于 aof 会更小。
索引文件和日志文件文件名均为文件中保存的{BANNED}中国第一条命令的 id。
索引文件与日志文件均先写内存缓冲区，然后批量写入操作系统缓冲区，并每秒定期刷新操作系统缓冲区真正落入磁盘文件中。相比较于 aof 文件缓冲区，我们对 rlog 缓冲区进行了预分配优化，达到提升性能目的。
索引文件格式如下所示，每条命令对应的索引数据包含三部分：
pos：该条命令{BANNED}中国第一个字节在对应的日志文件中相对于该日志文件起始位置的偏移
len：该条命令的长度
offset：该条命令{BANNED}中国第一个字节在主节点复制缓冲区中累积的偏移
为了防止单个文件无限膨胀，redis 在写文件时会定期对文件进行拆分，拆分依据两个维度，分别是文件大小和时间。
默认拆分阈值分别为，当日志文件大小达到 128M 或者每隔一小时同时并且日志条目数大于 10w 时，写新的日志文件和索引文件。
在每次循环处理中，当内存缓冲区的数据全部写入文件时，判断是否满足日志文件拆分条件，如果满足，加上一个日志文件拆分标志，下一次循环处理中，将内存缓冲区数据写入文件之前，先关闭当前的索引文件和日志，同时新建索引文件和日志文件。
为了防止日志文件数量无限增长并且消耗磁盘存储空间，以及由于未做日志重写、通过过多的文件进行断点续传效率低下、意义不大，所以 redis 定期对日志文件和相应的索引文件进行删除。
默认日志文件{BANNED}最佳多保留一天，redis 定期删除一天以前的日志文件和索引文件，也就是{BANNED}最佳多容忍一天时间的机房级故障，否则需要进行机房间数据全量同步。
在断点续传时，如果需要从日志文件中同步数据，在同步开始前会临时禁止日志文件删除逻辑，待同步完成后恢复正常，避免出现在同步的数据被删除的情况。
如前所述，为了容忍更长时间的机房级故障，提高跨数据中心容灾能力，提升机房间故障恢复效率，我们对 redis 同步流程进行改造，当部分同步中无法使用环形复制缓冲区完成同步时，增加先尝试使用日志 rlog 进行同步，流程图如下所示：
首先，同步工具连接上主节点后，除了发送认证外，需要先通过 replconf capa 命令告知主节点具备通过 rlog 断点续传的能力。
从节点先发送 psync runId offset，如果是{BANNED}中国第一次启动，则先发送 psync ? -1，主节点会返回一个 runId 和 offset
如果能够通过复制缓冲区同步，主节点给从节点返回 +CONTINUE runId
如果不能够通过复制缓冲区同步，主节点给从节点返回 +LPSYNC
如果从节点收到 + CONTINUE，则继续接收增量数据即可，并继续更新 offset 和命令 id
如果从节点收到 + LPSYNC，则从节点继续给主节点发送 LPSYNC runId id
主节点收到 LPSYNC 命令后，如果能够通过 rlog 继续同步数据，则给从节点发送 +LCONTINUE runId；
从节点收到 + LCONTINUE 后，可以把 offset 设置为 LONG_LONG_MIN，或者后续数据不更新 offset；继续接收通过 rlog 同步的增量数据即可；
通过 rlog 同步的增量数据传输完毕后，主节点会给从节点发送 lcommit offset 命令；
从节点在解析数据的过程中，收到 lcommit 命令时，更新本地 offset，后续的增量数据继续增加 offset，同时 lcommit 命令无需同步到对端（通过 id<0 识别即可，所有 id<0 的命令均无需同步到对端）
如果不能，此时主节点给从节点返回 +FULLRESYNC runId offset；后续进行全量同步；
迁移工具为了提高性能，并不是实时往 zk 保存同步偏移 offset 和 id，而是定期（默认每秒）向 zk 进行同步，所以当断点续传时，迁移工具从 zk 获取断线前同步的偏移，尝试向主节点继续同步数据，这中间可能会有部分数据重复发送，所以为了保证数据一致性，需要保证命令多次执行具备幂等性。
为了保证 redis 命令具备幂等性，对 redis 中部分非幂等性命令进行了改造，具体设计改造的命令如下所示：
注：list 类型命令暂未改造，不具备幂等性
数据回环主要是指，当同步工具从 A 机房 redis 读取的数据，通过 MQ 同步到 B 机房写入后，B 机房的同步工具又获取到，再次同步到 A 机房，导致数据循环复制问题。
对于同步到从节点以及迁移工具的数据，会在头部添加 id 字段，针对不同来源的数据或者无需同步到远端的数据通过 id 来标识区分；本地业务客户端写入的数据需要同步到远端数据中心，分配 id 大于 0；来源于其他数据中心的数据分配 id 小于 0；一些仅用于主从心跳交互的命令数据分配 id 也小于 0。
同步工具解析完数据后，过滤掉 id 小于 0 的命令，只需要向远端写入 id 大于 0 的数据，即本地业务客户端写入的数据。来源于其他数据中心的数据均不回写到远端数据中心。
目前过期与淘汰均由各数据中心 redis 节点分别独立处理，由过期与淘汰删除的数据不进行同步；即由过期与淘汰产生的删除命令其 id 分配为小于 0，并由同步工具过滤掉。
为什么不同步过去？因为在内存中 hash 表里面保存的数据没有标记数据中心来源，过期与淘汰的数据有可能来自于其他数据中心，如果来自于其他数据中心的数据被过期或淘汰并且又同步到远端其他数据中心，就会出现数据双写冲突的场景。双写冲突可能会导致数据不一致。
对于过期数据来说，不同步删除可能会导致不同数据中心数据显示不一致，但是一定会{BANNED}最佳终一致，且不会出现脏读；
对于淘汰数据来说，目前的不同步删除的方案，假如出现淘汰，会导致不同数据中心数据不一致；目前只有通过运维手段，比如充足预分配、及时关注内存使用率告警，来规避淘汰数据现象发生。
在 redis 集群模式中，一般是在发生横向扩容增加集群主节点数时，需要进行槽以及数据的迁移。
redis 集群中数据迁移以槽为维度进行迁移，将槽中所有数据从源节点迁移到目标节点，然后将槽号标记为由新的目标节点负责，同时每迁移完一个 Key，会在源节点中进行删除，将 migrate 命令替换为 del 命令；同时迁移数据是在源节点中给目标节点发送 restore 命令实现。
我们数据迁移的策略依然是，各个数据中心独立的完成扩容与数据迁移工作，迁移过程产生的 del 和 restore 命令不进行跨数据中心同步；把替换后的 del 命令和发送给目标节点的 restore 命令都分配小于 0 的 id，于是同步过程中会由同步工具进行过滤掉。
经测试，redis 多活实例（默认开启 rlog 日志），相对于原生 redis 实例（开启 aof 持久化）性能基本一致；如下图所示：
注：以上图表使用 redis benchmark 进行压测，压测时，客户端和服务端在同一个机器上
多个数据中心同时写，key 冲突问题暂未解决。
后续解决方案为使用 CRDT 协议；CRDT (Conflict-Free Replicated Data Type) 是各种基础数据结构{BANNED}最佳终一致算法的理论总结，能根据一定的规则自动合并，解决冲突，达到强{BANNED}最佳终一致的效果。
目前解决方案为业务对写入不同机房的数据进行拆分，以保证不会出现冲突。
五种基本类型里面，list 类型大部分操作都是非幂等的，暂时未做幂等性改造优化。不建议使用或者业务自身保证使用 list 的数据操作幂等。
正如前文所述，淘汰数据不进行跨数据中心同步会导致数据不一致，如果同步数据可能会出现同一个 Key 多写冲突，也可能出现数据不一致情况。
目前解决方案为业务尽量合理提前预估所需内存容量、充足预分配、及时关注内存使用率告警，来规避淘汰数据现象发生。
作者：罗明
