Kafka 跨集群复制与容灾：MirrorMaker 2 实战与故障切换

单集群的 Kubernetes 集群高可用解决的是「节点故障」；地域级故障（机房宕机、可用区失联）只能靠多集群。Kafka 的 MirrorMaker 2（MM2） 是官方跨集群复制方案：把一个集群的 Topic 消息实时镜像到另一个集群，并同步消费偏移量，让你在故障时能快速切换消费位置。本文讲透 MM2 的工作原理、复制拓扑、偏移量同步，并给出容灾切换演练的完整流程。

1. 为什么需要跨集群复制

1.1 单集群的边界

单集群 HA（多副本、ISR、控制器切换）解决的是单机房内的故障：

1.2 跨集群复制解决的问题

• 地域容灾：主备两个机房，一个挂了切另一个；
• 就近消费：读流量分流到本地集群，降低跨机房延迟；
• 数据搬迁：上云、机房迁移、集群版本升级；
• 多活与共享：多个业务中心共享一份事件流。

1.3 复制不等于备份

重要认知：复制解决的是「可用性」，不是「备份」。镜像集群是实时副本，若源集群有错误数据/误删，镜像也会继承——备份仍需要快照/归档。

一句话：单集群解决「节点级」，跨集群解决「地域级」——MM2 让事件流跨机房镜像、消费位置可切换，但它替代不了备份。

2. MirrorMaker 2 架构与工作原理

2.1 MM2 是什么

MM2 是 Kafka 内置的复制工具（kafka-mirror-maker2.sh），本质是一组 Connect Connector：用 Source Connector 从源集群拉取消息，写到目标集群，并同步 offset。

源集群 A ──(Source Connector)──► MM2 Connect ──(Sink 到)──► 目标集群 B
     └──(检查点/心跳 Topic)──────────────────────────────► B 的 __consumer_offsets

2.2 核心机制

2.3 复制策略与 Topic 命名

默认策略把源 Topic orders 镜像成目标集群的 A.orders（<source-alias>.<topic>），避免回环与命名冲突：

源集群 A：orders        → 目标集群 B：A.orders
源集群 B：payments      → 目标集群 A：B.payments

可自定义 ReplicationPolicy 去掉前缀（适合严格主备场景，切到备份后下游仍读 orders）。

2.4 一条复制消息的生命周期

① Source Connector 从源集群拉取 orders 分区消息
② 记录源 (topic, partition, offset)
③ 写入目标集群 A.orders 对应分区（保留原 key/timestamp）
④ 检查点任务把映射 <A.orders, offset> → <orders, offset> 写目标集群
⑤ 故障切换时，下游按映射从源 offset 位置继续消费

一句话：MM2 = Connect Connector 把源消息镜像到目标 + 检查点记录偏移映射——让「切到备份后从哪接着读」有据可依。

3. 复制拓扑：三种模式怎么选

3.1 Active-Standby（主备）

主集群 A（写） ──► 备集群 B（只读镜像）
    正常：业务读写 A，B 做灾备/只读查询
    故障：切换 DNS/客户端指向 B（B 恢复为主）

• 优点：简单、无脑裂；
• 缺点：备集群利用率低，切换有 RPO（恢复点）。

3.2 Active-Active（双活）

A ◄──► B 双向复制
  不同业务写不同集群，事件流互相镜像

• 优点：双机房利用充分、就近写；
• 缺点：冲突与回环风险高（同一条消息在两个集群各写一次）、需依赖分区键与幂等语义消解。

3.3 Hub-Spoke（星型）

        ┌──► B（业务域）
数据中心 ──► A（中心/聚合）──► C（分析域）
        └──► D（归档域）

• 优点：多下游共享一份上游事件，治理清晰；
• 缺点：中心集群是瓶颈点。

3.4 选型建议

一句话：拓扑没有银弹——主备最稳、双活最高效但最复杂、星型最灵活；一致性要求越高，越别碰双活。

4. 偏移量同步与消费位置管理

4.1 偏移量为何要单独同步

消费偏移量存在 __consumer_offsets（每集群独立）。故障切换时，若下游 Consumer 直接用备份集群的偏移量，会从备份集群自己的消费位置开始——而备份集群的消费进度未必和源集群一致。MM2 用检查点把源集群的偏移量同步到目标集群，让切换后的 Consumer 能接着源集群的位置读。

4.2 检查点机制

Consumer group G 在源集群 A 消费 orders
  进度：partition-0 → offset 50000

MM2 检查点任务周期写入目标集群 B：
  __consumer_offsets 里记录：
    group=G, topic=A.orders, partition=0, source offset=50000

故障切换后，G 的消费者连 B，读 A.orders：
  MM2 把源偏移量映射为 B 的实际偏移量 → 从源位置继续

4.3 偏移量同步的局限

• 检查点是周期性的：同步延迟内切换会回放重复（at-least-once 语义内可接受）；
• 不同步事务状态：事务消息的精确位置需要事务标记，MM2 的 EOS 支持需版本配套；
• group 维度：偏移量按 (group, topic, partition) 同步，group 需在两侧同名。

一句话：检查点让切换后接着源集群的位置读（不丢进度），但它是周期性快照——切换点附近存在少量重复，按 at-least-once + 幂等消费兜住即可。

5. 故障切换流程与演练

5.1 切换决策树

主集群故障？
 ├─ 短暂抖动（几十秒）→ 观察，不切换
 ├─ 可用区失联（小时级）→ 准备切换
 └─ 机房级灾难（T+1 以上）→ 立即切换

5.2 主备切换标准流程

# ① 停掉生产写主集群（或自动路由到备）
# ② 验证备集群复制链路健康（心跳/检查点无滞后）
# ③ 切换客户端 bootstrap.servers 指向备集群
# ④ 消费者从备集群继续消费（靠检查点接着源位置）
# ⑤ 确认读写稳定后，备升级为主，重建复制方向

5.3 演练清单（Runbook）

5.4 回切（Fallback）

主集群恢复后，先单向反向复制把切换期间的增量搬回主，验证一致后再把客户端指回主，最后恢复原有复制方向——不要直接双写，避免脑裂。

一句话：切换不是「拔插头」，而是决策树 + 标准流程 + 演练 Runbook——练到「备份切换像日常发布一样熟练」，容灾才真正成立。

6. 复制方案对比：MM2 / Replicator / 集群联邦

6.1 三大方案

6.2 关键差异

• Schema 同步：Confluent 方案可同步 Schema Registry，MM2 需自行同步 _schemas；
• 双向冲突：Replicator/Cluster Linking 对双活有更好支持；
• 运维：MM2 用 Kafka Connect 框架，生态成熟；
• 成本：MM2 免费，商业方案提供治理与支持。

6.3 自研 vs 现成

需求简单（单向往备）→ MM2 足够
需求复杂（Schema 同步、部分 Topic、严格 EOS）→ 评估 Confluent 方案
自研：要处理偏移映射、回环、冲突 → 成本高，一般不推荐

一句话：MM2 免费够用，商业方案在 Schema 同步与双活上更强——先跑通 MM2，确有治理需求再评估升级。

7. 常见坑与最佳实践

7.1 常见坑

7.2 最佳实践清单

• 明确 RPO/RTO，检查点周期按 RPO 设定；
• 心跳 Topic 监控，复制链路异常即告警；
• 切换前验证备份完整性与 Lag；
• 定期演练，把切换 Runbook 当生产事故预演；
• Schema 随消息一起同步；
• 复制方向单向、切换有序，避免脑裂。

8. 总结

本文搭建了 Kafka 跨集群容灾的完整认知：

一句话记住：跨集群复制 = 把事件流镜像到异地 + 把消费位置也带过去——MM2 用 Connect 做复制、用检查点做偏移映射、用心跳做健康探针，让地域级故障也能在 RPO/RTO 内切换。切换练到熟练、复制纳入监控、备份别被复制替代，容灾才算闭环。