常见原因是消费者组配置未隔离或源/目标集群 bootstrap.servers 指向同一套 zookeeper 或共用 group id；mirrormaker 1.x 不维护独立偏移量，会覆盖源集群消费进度，必须单独指定不与业务冲突的 group.id，并确保源/目标集群网络与认证配置物理隔离。
为什么 kafka-mirror-maker.sh 启动后没同步、也没报错？
常见原因是消费者组配置未隔离，或源/目标集群的 bootstrap.servers 指向了同一套 ZooKeeper 或共用 group ID。MirrorMaker 1.x 本质是「一个消费者 + 一个生产者」的桥接程序，它不维护独立偏移量存储，而是把源集群的 offset 直接提交到目标集群的 __consumer_offsets（如果用了 --consumer.config 中的 group.id），这会导致：源集群消费进度被覆盖、重复拉取、甚至阻塞。
- 必须为 MirrorMaker 单独指定
group.id，且不能与业务消费者重名 - 源集群的
bootstrap.servers和目标集群的bootstrap.servers必须物理隔离（跨机房时尤其注意 DNS 解析和网络策略） - 若源集群启用了 SASL/SSL，
--consumer.config和--producer.config必须分别配置对应认证参数，不能复用同一份文件 - 默认不复制内部 topic（如
__consumer_offsets），也不同步 topic 配置（如 retention.ms），这些需额外脚本配合
如何只同步指定 topic 并避免正则误匹配？
MirrorMaker 1.x 的 --whitelist 参数实际是 Java 正则，不是 glob。写成 --whitelist "myapp-.*" 看似合理，但若目标集群已有 myapp-user-event-v2，而源集群 topic 名是 myapp-user-event，就可能因大小写或分隔符差异漏匹配。
- 推荐用精确匹配：
--whitelist "myapp-order,myapp-payment,myapp-refund" - 避免
.*开头（如.*-order），它会匹配所有以-order结尾的 topic，包括系统 topic - 若必须用正则，请锚定开头和结尾：
--whitelist "^myapp-(order|payment|refund)$" - 启动前先用
kafka-topics.sh --list --bootstrap-server <source></source>确认源集群真实 topic 名，注意隐藏字符和大小写
kafka-mirror-maker.sh 同步延迟高，怎么定位瓶颈？
跨机房场景下，延迟通常卡在三处：网络往返（RTT）、目标集群写入吞吐、MirrorMaker 自身线程模型。它默认只起 1 个消费者线程和 1 个生产者线程，无法利用多核，也难以应对高吞吐。
- 用
tcpdump或ping测源→目标集群的 RTT，超过 50ms 就要警惕；Kafka 生产请求是同步等待响应的，高延迟会直接拖慢消费速度 - 检查目标集群
NetworkProcessorAvgIdlePercent是否长期低于 30%，说明网络线程忙不过来 - 增加
--num.streams N（N > 1）可启多个消费者线程，但要注意：每个 stream 独立消费全量 topic 分区，会造成重复拉取 —— 这不是 bug，是设计使然，仅适合幂等写入场景 - 更稳妥的做法是部署多个 MirrorMaker 实例，用不同
group.id+--whitelist拆分 topic，避免单点瓶颈
目标集群 topic 分区数和副本数能自动对齐吗？
不能。kafka-mirror-maker.sh 只负责数据转发，不管理元数据。如果源集群 topic 是 12 分区 × 3 副本，目标集群对应 topic 是 6 分区 × 1 副本，MirrorMaker 会照常发送，但可能触发 NotEnoughReplicasException 或因分区数不一致导致 producer 批量失败。
- 必须提前在目标集群创建好同名 topic，且
--partitions和--replication-factor匹配源集群（可用kafka-topics.sh --describe查） - 不要依赖
--create-topic-enabled（MirrorMaker 1.x 不支持该参数；2.x 的MirrorMaker2支持，但需额外配置topics.exclude避免同步内部 topic） - 跨机房时，目标集群的
min.insync.replicas建议设为 1（否则网络抖动易触发写入失败），但要接受短暂的数据一致性风险
真正难的不是跑起来，是让 offset 对得上、延迟稳得住、扩容不翻车。跨机房同步里，网络不可靠是常态，MirrorMaker 1.x 的简单模型反而成了优势——出问题时链路短、日志干净。别急着堆参数，先确认 consumer group 隔离干净、topic 元数据人工对齐、网络基线摸清楚。
