《Kafka: The Definitive Guide》 第8章： Cross-Cluster Data Mirroring

一、跨集群镜像的场景与价值

1. 多区域低延迟访问

   • 将业务数据从主集群实时复制到多个地理区域的集群，缩短消费者跨区读取延迟。

2. 灾备切换

   • 当主集群出现故障时，可快速将消费流量切换到镜像集群，确保业务连续性。

3. 集群升级与迁移

   • 在不中断生产环境的前提下，向新集群同步全量与增量数据，实现平滑迁移。

4. 合规与隔离

   • 不同地域或部门的数据隔离需求，可在各自集群中维护副本，满足安全与法规要求。

---

二、MirrorMaker 2 体系架构回顾

MirrorMaker 2（以下简称 MM2）基于 Kafka Connect 框架扩展而来，核心组件包括：

• Source Cluster Connector：在源集群消费指定 topics。
• Target Cluster Connector：以生产者身份将消息写入目标集群。
• Heartbeat Topic：用于检查跨集群链路健康。
• Checkpoint Topic：跟踪镜像进度，确保精准无漏。
• Replication Policy：控制在目标集群中 Topic、Group ID、ACL 等命名转换与权限映射。

其运行流程大致为：

1. MM2 从源集群的 __heartbeat、__checkpoint 以及业务 topics 拉取消息。
2. 根据 Replication Policy，将消息写入目标集群对应的镜像 topic（默认为 <sourceCluster>.<topic>）。
3. 定期写入 checkpoint，方便故障重启后接续。
4. 通过心跳机制监控链路状态，及时发现滞后或中断。

---

三、详细配置解读

以下示例配置展示了一个从集群 A ➔ B 的单向镜像，以及双向互镜的关键选项。

# mm2-cluster.properties
clusters = A, B# 集群 A 配置
A.bootstrap.servers = a1:9092,a2:9092
# 集群 B 配置
B.bootstrap.servers = b1:9092,b2:9092# 单向镜像：A ➔ B
A->B.enabled = true
A->B.topics = orders, payments      # 指定需要镜像的 topics 列表或正则
A->B.sync.topic.configs = true      # 同步源端 topic 的所有配置
A->B.emit.heartbeats.enabled = true # 开启心跳消息
A->B.emit.checkpoints.enabled = true# 双向互镜（可选）
B->A.enabled = true
B->A.topics = .*

• topics：支持逗号分隔、通配符正则或 .*（全部）。
• sync.topic.configs：建议开启，确保分区数、压缩方式等一致。
• replication.policy.class：可自定义命名策略，如去除前缀、添加地域标识等。

启动命令：

bin/connect-mirror-maker.sh mm2-cluster.properties

---

四、镜像一致性与故障恢复

1. Checkpoint 恢复

   • MM2 定期在源集群的 __checkpoint topic 写入偏移量，并在目标集群中消费，再将进度存至本地状态。
   • 重启后自动读取上次 checkpoint，继续从上次位置拉取，避免漏 / 重复。

2. 心跳监控

   • __heartbeat topic 用于监测源集群是否活跃，以及链路健康度。
   • 可结合 Prometheus 抓取 kafka_mirrormaker2_heartbeat_lag 等指标，及时报警。

3. 网络抖动与重试

   • MM2 继承 Kafka Connect 的重试机制：

     errors.retry.timeout = 600000     # 重试总时长（毫秒）
     errors.retry.delay.max.ms = 60000 # 最大重试间隔
     

   • 对于短暂的网络抖动或目标端不可用，自动重试，无需人工干预。

---

五、高级用例：多活与环形复制

• 多活部署：

  • 在多个机房同时开启 A⇄B、A⇄C、B⇄C 镜像，实现三活互备。
  • 需注意：环形复制易产生回环，必须开启 replication.policy.class = org.apache.kafka.connect.mirror.DefaultReplicationPolicy，并默认过滤已镜像的前缀。

• 渐进式迁移：

  1. 全量同步：先将历史数据复制到新集群。
  2. 增量镜像：开启 MM2 单向镜像，捕获实时写入。
  3. 切流：消费者切换到新集群后，停用原链路。

---

六、监控与调优

指标名称	含义	建议
checkpoint-lag	已复制偏移与源端最新偏移的差值	<1000 messages
heartbeat-latency	心跳写入与消费的延迟	<1s
replication-backlog	待发送消息缓冲区大小	根据带宽调优
task-poll-interval-ms	Connector 拉取轮询间隔	10–100 ms
consumer/max-poll-records	每次拉取消息数	100–500

• 带宽与并发：可通过 tasks.max 提升并行度，分散分区负载；
• 压缩：开启生产端压缩（如 compression.type=snappy），减少网络传输量；
• 安全：跨 DC 建议启用 TLS/SASL，配置 client.dns.lookup=use_all_dns_ips 及 connections.max.idle.ms 保持稳定连接。

---

七、最佳实践总结

1. 分离全量与增量

   • 对于历史数据量较大时，采用工具（如 kafka-replay-log-dirs）先行全量导入，再开启 MM2 进行增量镜像。

2. 命名策略统一

   • 定制 replication.policy.class，将源集群标识、地区前缀或版本号统一加到 Topic 名称，便于追踪与管理。

3. 定期故障演练

   • 模拟主集群故障或链路中断，验证镜像集群能否快速接管，检验监控告警与自动恢复流程。

4. 流量切分

   • 对于高吞吐主题，可单独配置专属 MM2 进程，确保单一链路不因其他主题瓶颈拖慢。

5. 权限与隔离

   • 使用 Kafka ACL，严控跨集群 MirrorMaker 的读写权限，防止误操作。