Redis - 解读三种方案实现Redis跨机房数据同步

---

Pre

Redis-入门到精通

Redis进阶系列

Redis进阶 - Redis主从工作原理详解

Redis-18Redis主从同步

Redis-19Redis哨兵Sentinel模式-Centos6.5上3台主机1主2从3哨兵的配置及通过代码访问哨兵

Redis - 高可用实现方案解析：主从复制与哨兵监控

Redis - 三种Redis集群实现方案之_客户端分片

Redis - 三种Redis集群实现方案之_基于代理的分片

---

概述

随着业务规模不断扩大，多机房部署成为保障系统高可用性、容灾和低时延访问的重要手段。作为高性能内存数据库的Redis，其跨机房数据同步方案备受关注。本文将详细探讨业界常见的三种数据同步方案：主从服务器模式、代理服务器模式和多活服务器模式，分析各自的实现原理、优缺点以及适用场景，为系统架构设计提供参考。

1. 主从服务器模式

实现原理

在主从服务器模式中，通过伪装成一个从服务器（即伪从服务器）来利用Redis原生的PSYNC命令完成数据同步。

其基本流程如下：

• 数据同步：通过实现一个数据同步模块，并且伪装成一个从服务器（伪从服务器），向主服务器发送PSYNC命令，获取全量RDB文件以及增量执行命令，对这些数据进行封装压缩、加密等一系列优化操作，并通过实现自有的数据通信协议进行传输，当另一个机房的同步服务接收到数据之后对其实现解压处理，并且加载到从服务器文件存储路径，同时将增量命令执行写入从服务器。
• 同步服务高可用：通过一个注册中心来实现同步服务的故障发现，它们有主从备份，如果其中一个同步服务器宕机，可以拉起备用服务节点代替主同步服务。
• Redis自身高可用：通过主从模式及哨兵模式来实现，哨兵检测到主服务器宕机后，会切换到从服务器来进行替代

种模式只能做到单向数据传输，无法实现数据的双活。

优缺点与适用场景

• 优点：
  • 利用原生PSYNC机制，技术实现相对简单。
  • 可对传输过程进行定制化优化（如压缩与加密）。
• 缺点：
  • 仅支持单向数据传输，无法满足双向数据同步需求。
• 适用场景：
  • 适用于灾备、备份场景或数据传输方向固定的应用。

常见实现包括阿里云Redis&MongoDB团队的 redis-shake 以及携程框架部门的 Xpipe。

---

2. 代理服务器模式

实现原理

代理服务器模式在每个Redis节点前部署一层代理，该代理层负责拦截所有写入请求并实现数据的转发与同步：

• 上层业务无需感知数据同步逻辑，所有数据写入同时传递到本地Redis和其他机房的节点。
• 数据同步通过代理自动完成，保持机房内外数据一致性。

优缺点与适用场景

• 优点：
  • 对业务层完全透明，无需改动应用代码。
  • 自动实现机房内外的数据同步。
• 缺点：
  • 每个节点需要额外部署代理，增加了运维管理复杂性。
  • 写入性能较原生Redis有所下降，尤其是节点数量增加时。
  • 同步策略不够灵活，无法针对性选择部分数据进行同步。
• 适用场景：
  • 适用于对业务透明性要求高、对性能影响可控的场景。

Netflix开源的 Dynomite 是这种模式的代表性实现。

---

3. 多活服务器模式

多活服务器模式旨在实现跨机房的双向数据写入，即各机房的Redis均可同时读写。常见的实现方式主要有以下几种：

（1）业务层写入模式

• 原理：业务在写入Redis的同时，将数据同步写入消息队列，由消息队列自带的机房同步机制实现跨机房数据传递。
• 优缺点：
  • 优点：实现简单、直观。
  • 缺点：对业务有较强侵入性，不同业务间难以共享同步组件。

---

（2）监听Redis变更事件模式

• 原理：利用Redis的数据变更监听机制捕捉写操作，通过消息队列完成数据同步。为防止循环复制，通常在数据中加入标记字段（如source）来区分数据来源。

在这种模式下，数据同步监听Redis的变更操作事件，机房1到机房2有同步，同时机房2到机房1也有同步，这样就会出现双向同步下数据循环复制的问题。那么如何解决这个问题呢？

可以采取添加数据源标记的方式来解决，例如添加source字段，通过该字段标记数据从哪个机房同步过来，如果机房1发现数据是从机房2同步过来的则接收，如果数据标记字段是机房1，说明产生了循环复制，则丢弃此次同步的数据。Redis 监听事件的模式的最大弊端在于处理的性能有限。由于Redis监听事件通知性能有限，因此使用这种模式需要谨慎评估线上数据对时延的容忍度，如果业务对时延的容忍度很低，那么这种模式不太适合。

• 优缺点：
  • 优点：独立于业务层，减少业务侵入性。
  • 缺点：Redis事件监听机制在高并发下性能有限，可能无法满足极低延时要求。

---

（3）伪装从服务器获取写入命令模式

• 原理：与主从模式类似，通过伪装成从服务器获取全量RDB及增量命令。解析后，通过消息队列传递到目标机房，写入时可利用时间戳确保顺序正确，同时通过数据标记避免循环复制问题。

基于伪从服务器的Redis多活同步过程包含以下几点。

• 拉取服务：伪装成一个Redis的从服务器（图3-17中的伪从服务器），并对主服务器发送PSYNC命令，发送这个命令之后，伪从服务器首先会获取到一个全量同步的RDB（Redis DataBase）文件，之后就依据runid offset获取增量操作的命令进行增量同步。

• 解析服务：解析服务主要是解析RDB文件，RDB文件是以二进制格式存储的，按照文件存储的格式进行读取，RDB的文件格式以及解析在这里限于篇幅不详述，可以参考开源工具，推荐通过redis-rdb-tools来了解具体的解析逻辑。

• 回放服务：回放服务是将已经解析的Redis命令写入目的Redis集群，这里有一个问题，由于采取消息队列（message queue，MQ）进行传输，并且是多活写入，因此存在数据回放的顺序问题，可以在写入消息队列的时候带上时间戳，通过时间戳的先后顺序进行覆盖。

• 发送/接收服务：将解析后的数据写入消息队列，以及从消息队列接收数据传递给回放服务。另外消息队列多向同步仍然会遇到数据循环复制的问题，解决方案和前面介绍的一致，这里不赘述。

• 优缺点：

  • 优点：借助PSYNC机制，可以较容易实现数据同步。
  • 缺点：数据解析和命令回放流程较为复杂，存在性能瓶颈风险。

---

（4）AOF日志信息同步模式

• 原理：利用Redis的AOF日志，每条操作日志扩展为包含全局唯一ID和逻辑时钟信息的操作记录。通过消息队列传递后，在目标机房利用CRDT（无冲突复制数据类型）策略进行数据合并，确保“exactly once”同步及数据最终一致性。

基于AOF的Redis多活实现方案要解决的一些核心问题如下。

• 日志同步：把每一条AOF格式日志信息扩展为操作日志，以方便对操作信息的写入、对操作日志的同步，并保障同步操作是exactly once。-

• 唯一标识：每条oplog包含一个全局唯一ID，ID又包含两部分，一部分是Redis实例ID，用于解决循环同步的问题，另一部分是递增数字，保证有序和唯一。

• 数据最终一致性：操作日志包含逻辑时钟信息，在目标端Redis执行合并时，使用无冲突复制数据类型（conflict-free replicated data type，CRDT）策略解决数据一致性问题。

• 优缺点：

  • 优点：能有效保证数据一致性，适用于复杂的多活场景。
  • 缺点：实现过程较为复杂，对系统性能和设计要求较高。

阿里云ApsaraDB for Redis的多活实现便采用了类似方案。

---

方案选型对比

方案	数据方向	性能影响	运维复杂度	典型场景
主从模式	单向	低	低	灾备、读写分离
代理模式	双向	中	高	小规模多活
多活-伪从	双向	中	中	通用多活场景
多活-AOF同步	双向	高	高	强一致性要求场景

---

实践建议

1. 防循环复制：所有方案需通过标记字段（如机房ID）过滤本地数据。
2. 数据一致性：优先选择支持CRDT或时间戳覆盖的同步策略。
3. 性能优化：
   • 批量压缩传输降低网络开销
   • 异步回放减少写入延迟
4. 监控体系：需建设同步延迟、数据差异等核心指标监控。

---

总结

• 主从服务器模式：利用PSYNC实现数据单向传输，技术实现简单，适用于备份与灾备场景，但不支持双向数据同步。
• 代理服务器模式：通过部署代理层实现数据透明同步，适合对业务无侵入要求的场景，但运维和性能上存在一定挑战。
• 多活服务器模式：提供双向写入能力，通过业务层写入、事件监听、伪从服务器模式及AOF日志同步等多种方式实现数据同步，各有优缺点，需根据具体业务需求进行权衡。

以上各种模式的解决方案可以相互借鉴，例如消息的唯一标识、数据防止循环复制、数据最终一致性处理等。数据同步通道也不一定是消息队列，本节只是为了大家理解和使用方便，因此以消息队列来说明，原则上任意数据传输服务（data transmission service，DTS）都是可行的

随着Redis 7.0推出的ACL增强和复制协议优化，未来跨机房同步将朝着更安全、更高效的方向持续演进。