Kafka MirrorMaker 2.0 可稳定实现跨数据中心双向同步，需通过命名隔离（如dc-a.orders）、启用offset同步（sync.group.offsets.enabled=true）及双集群网络互通来规避循环复制。
Kafka MirrorMaker 本身不原生支持双向同步，但通过合理架构设计和工具选型（尤其是 MirrorMaker 2.0），可以稳定实现跨数据中心双向消息同步。关键不在“单个命令”，而在于拓扑设计、配置隔离与循环复制规避。
优先用 MirrorMaker 2.0（MM2）而非 MM1
MM1 是单向、静态、无 offset 同步的简单 consumer-producer 模型，要实现双向必须部署两套独立实例（A→B 和 B→A），手动管理 topic 映射与 group id，极易因配置重叠导致消息无限循环。MM2 基于 Kafka Connect，天然支持双向同步能力：
- 内置 MirrorSourceConnector 负责拉取源集群数据和 topic 元信息
- 内置 MirrorCheckpointConnector 同步 consumer group offset（通过
__checkpointtopic 翻译位移） - 内置 MirrorHeartbeatConnector 发送心跳检测链路健康状态
- 支持正则自动发现新 topic，无需重启即可动态增删同步规则
双向同步必须做 topic 命名隔离
两个集群若直接镜像同名 topic（如都叫 orders），A→B 写入后 B 又会触发 B→A 的镜像，形成死循环。标准做法是添加数据中心标识前缀：
- A 集群（dc-a）中 topic 命名为
orders - B 集群（dc-b）中对应 topic 命名为
dc-a.orders - 在 MM2 配置中启用
topics.regex和replication.policy.class，使用DefaultReplicationPolicy自动添加/剥离前缀 - 例如设置
source.cluster.alias=dc-a，target.cluster.alias=dc-b，MM2 会自动将 dc-a 的orders同步为 dc-b 的dc-a.orders
正确配置 offset 同步与消费组映射
双向场景下，consumer group 的 offset 必须可迁移，否则故障切换后会出现重复或漏消费：
立即学习“Java免费学习笔记（深入）”；
- 启用
checkpoints.topic.replication.factor和checkpoints.topic.num.partitions，确保__checkpointtopic 在目标集群可写 - 设置
sync.group.offsets.enabled=true，让 MM2 把源集群 group 的 offset 翻译成目标集群等效位置 - 避免业务 consumer 直接消费镜像 topic；应统一接入带前缀的 topic（如
dc-a.orders），并由应用层按需路由
网络与权限需双向打通
MM2 实例需同时能访问两个集群的 bootstrap servers 和 ZooKeeper/KRaft 元数据服务（取决于 Kafka 版本）：
- 每个 MM2 Worker 必须配置双 cluster 连接参数：
clusters = dc-a, dc-b，并分别定义dc-a.bootstrap.servers和dc-b.bootstrap.servers - 目标集群需开放 WRITE 权限给 MM2 使用的 SASL 用户（ACL 需手动或通过
sync.acls.enabled=true自动同步，除 WRITE 外） - 建议将 MM2 部署在中立网络区域（如云上跳板机），避免单边网络分区导致数据丢失
