mirrormaker 是 kafka 自带的独立同步工具，非 java sdk；java 项目通过 rest api 管理 mm2 任务、jmx 监控指标、动态配置实现运维自动化，需做好命名隔离、offset 同步和网络互通三件事。
Kafka 跨机房多活架构中，MirrorMaker 不是 Java 代码里“调用”的库，而是 Kafka 自带的同步工具。Java 项目本身不直接参与消息搬运，但可以用来驱动、监控和管理整个同步流程。
明确 MirrorMaker 的角色定位
MirrorMaker 是独立运行的进程（底层用 Java 编写），不是 SDK 或 API。你不会在 Java 里写 new MirrorMaker()，也不会用它收发消息。它的作用就是：从 A 机房集群消费 → 写入 B 机房集群。双向多活时，需部署两套 MirrorMaker（A→B 和 B→A）或直接用 MM2 原生支持双向。
MM2 是多活落地的关键选择
相比 MM1，MM2 基于 Kafka Connect 架构，更适合生产级多活场景：
- 支持自动发现新 topic，无需每次新增 topic 都改配置重启
- 内置 offset 同步机制，能准确映射源/目标集群的消费位点，避免重复或丢失
- 通过 REST API 管理 connector，Java 服务可动态创建、暂停、更新同步任务
- Worker 集群具备高可用，单节点故障不影响整体同步
- 所有指标暴露在 JMX，Java 程序可采集 lag、吞吐、错误率等做告警
Java 如何真正参与多活同步
Java 不干活，但管干活的人。典型集成方式包括：
- 调用 Connect REST 接口提交 MM2 配置（如
POST /connectors），实现同步任务的自动化启停 - 轮询
/connectors/{name}/status获取运行状态，异常时触发告警或自动重试 - 读取 JMX 的
kafka.connect:type=connector-metrics,connector=.*指标，计算端到端延迟和积压量 - 监听 Kafka 内部 topic（如
mm2-offset-syncs.dc-a.dc-b）验证 offset 映射是否及时生效 - 结合配置中心（如 Nacos、Apollo），动态下发 topic 白名单、限流参数等，避免重启 MM2 进程
必须做好的三件基础事
否则多活会出环、丢数或不可控：
-
命名隔离：给同步 topic 加前缀，比如 A 机房的
orders同步过去变成dc-a.orders，B 机房的同名 topic 变成dc-b.orders，防止 A→B 后又被 B→A 回写 -
offset 同步启用：配置
sync.group.offsets.enabled=true，并确保__checkpointtopic 在目标集群存在且可写（建议 replication.factor ≥ 2） -
网络与认证互通：MM2 进程必须同时能连通源集群和目标集群的
bootstrap.servers，SASL/SSL、ACL、防火墙策略都要双向配齐
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
