RocketMQ 主从复制详解

原创于 2025-07-31 00:23:19 发布 · 1k 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#rocketmq #主从复制

MQ 专栏收录该内容

156 篇文章

订阅专栏

🚀 RocketMQ 主从复制详解：

异步复制 (ASYNC_MASTER) vs 同步双写 (SYNC_MASTER)

深入理解高可用与数据一致性保证

在 RocketMQ 中，主从复制（Replication） 是实现高可用（High Availability） 和 数据容灾 的核心机制。它通过将 Master Broker 的数据同步到一个或多个 Slave Broker，确保在主节点宕机时，系统仍能继续提供服务。

RocketMQ 提供了两种主从复制模式：

异步复制（ASYNC_MASTER）
同步双写（SYNC_MASTER）

本文将深入解析这两种模式的工作原理、性能影响、数据一致性保障及适用场景。

一、主从复制的基本架构

                +------------------+
                |   NameServer     |
                +--------+---------+
                         ↑
                         | 心跳注册
          +--------------+--------------+
          |                             |
          v                             v
+-------------------+         +-------------------+
|    Master Broker  |-------->|    Slave Broker   |
|  (读写)           |  复制   |  (只读或备用)     |
+-------------------+         +-------------------+
          ↑                             ↑
          |                             |
    Producer 发送消息             Consumer 可读取

✅ 角色说明：

Master：可读可写，接收生产者消息
Slave：通常只读，从 Master 同步数据，用于消费或容灾

二、1. 异步复制（ASYNC_MASTER）

✅ 工作原理：

Master 接收消息并写入本地 CommitLog（PageCache）
立即返回 ACK 给 Producer
后台线程异步将消息推送给 Slave
Slave 写入自己的 CommitLog

Producer → 发送消息
   ↓
Master 写入 PageCache → 立即返回 ACK
   ↓
后台线程异步推送给 Slave
   ↓
Slave 写入磁盘

🔧 配置方式：

# broker.conf
brokerRole=ASYNC_MASTER

✅ 优点：

优势	说明
高性能	不阻塞主节点写入，吞吐量高
低延迟	Producer 几乎无等待
适合高并发场景	电商、日志、通知等

❌ 缺点：

问题	说明
可能丢消息	若 Master 宕机且未同步完成，Slave 缺少最新数据
数据一致性弱	Slave 数据滞后于 Master（几秒到几十秒）

🎯 适用场景：

大多数业务场景（如订单、用户行为）
可容忍极小概率数据丢失
追求高吞吐和低延迟

三、2. 同步双写（SYNC_MASTER）

✅ 工作原理：

Master 接收消息
同步将消息发送给 Slave
等待 Slave 确认写入成功
Master 再写入本地 CommitLog 并返回 ACK

Producer → 发送消息
   ↓
Master → 转发消息给 Slave
   ↓
等待 Slave 返回“写入成功”
   ↓
Master 写入本地 CommitLog
   ↓
返回 ACK 给 Producer

🔧 配置方式：

# broker.conf
brokerRole=SYNC_MASTER

✅ 优点：

优势	说明
强数据一致性	Master 和 Slave 数据完全一致
高可靠性	即使 Master 宕机，Slave 也有完整数据
满足金融级要求	适用于不允许丢失的场景

❌ 缺点：

问题	说明
性能低	网络往返 + Slave 写入延迟，显著降低 TPS
延迟高	每次写入都要等待 Slave 响应
依赖网络稳定性	网络抖动会导致主节点阻塞

🎯 适用场景：

金融交易系统（如支付、转账）
对账系统
任何要求“零丢失”的关键业务

四、ASYNC_MASTER vs SYNC_MASTER 对比表

特性	异步复制 (ASYNC_MASTER)	同步双写 (SYNC_MASTER)
数据一致性	弱（Slave 滞后）	强（完全一致）
性能（TPS）	高（接近无复制）	低（下降 30%~60%）
延迟	低	高（受网络影响）
可靠性	一般（可能丢少量）	高（几乎不丢）
网络依赖	低	高（网络抖动影响主节点）
适用场景	大多数业务	金融、强一致场景
推荐使用	✅ 默认推荐	❌ 仅关键场景

五、高可用（HA）机制详解

1. 故障切换（Failover）

RocketMQ 原生 不支持自动主从切换
若 Master 宕机：
- Producer 无法写入（除非配置多个 Master）
- Consumer 可从 Slave 读取消息（需开启 slaveReadEnable=true）
需结合外部工具（如 Dledger、ZooKeeper、K8s）实现自动选主

2. Slave 读取能力

# 允许 Consumer 从 Slave 拉取消息
slaveReadEnable=true

提升读能力，分担 Master 压力
在 Master 宕机时，Consumer 仍可消费历史消息

六、Dledger 模式：更先进的高可用方案（推荐）

由于传统主从模式缺乏自动故障转移，RocketMQ 4.5+ 推出了 Dledger 模式，基于 Raft 协议 实现自动选主。

✅ Dledger 核心优势：

特性	说明
自动选主	节点宕机后自动选举新 Leader
多副本强一致	多数节点确认写入才算成功
最终一致性	数据不丢失，服务不中断
无需手动干预	真正实现高可用

⚠️ 注意：Dledger 模式需使用 DLedgerCommitLog，不兼容传统刷盘配置。

七、最佳实践建议

实践	说明
✅ 生产环境默认使用 `ASYNC_MASTER`	性能与可靠性平衡
✅ 关键业务考虑 `SYNC_MASTER` 或 `Dledger`	保证数据不丢
✅ 配置 `slaveReadEnable=true`	提升读能力，支持故障时读取
✅ Master 和 Slave 部署在不同物理机/可用区	避免单点故障
✅ 监控复制延迟（`brokerStatus` 查看）	及时发现同步问题
✅ 结合 `ASYNC_FLUSH` + `ASYNC_MASTER`	大多数场景的最优组合

八、常见问题排查

问题	可能原因	解决方案
Slave 同步延迟高	网络带宽不足、磁盘慢	优化网络或升级硬件
Slave 无法连接 Master	网络不通、端口未开放	检查防火墙和路由
Master 宕机后无法恢复	无自动切换机制	使用 Dledger 或外部 HA 工具
消费者无法从 Slave 读取	`slaveReadEnable=false`	开启该配置