3、跨集群同步方案选型：MirrorMaker 2.0、Confluent Replicator、自研方案对比

跨集群数据同步，说白了就是要把数据从一个Kafka集群搬到另一个。听起来简单，但真做起来坑不少。我这些年见过不少团队，上来就拍脑袋选方案，结果后面运维成本高得吓人。

今天咱们就把主流的三种方案掰开揉碎聊一聊。MirrorMaker 2.0、Confluent Replicator、还有自研方案。嗯，每个我都踩过坑，有些经验希望能帮你少走弯路。

3.1 方案全景图

先看一张整体对比图，心里有个谱。

3.2 MirrorMaker 2.0：开源首选

MirrorMaker 2.0（简称MM2）是Apache Kafka官方提供的跨集群同步工具。我记得它刚出来的时候，大家还都在用老版的MirrorMaker，那个只能做单向同步，配置起来也麻烦。

MM2最大的改进是什么？它基于Kafka Connect框架重写了。这意味着你可以用REST API管理它，还能跟现有的Connect生态集成。

3.2.1 核心特性

• 双向同步：支持A→B和B→A同时进行，不会产生循环复制
• 自动Topic创建：目标集群会自动创建源集群的Topic，省去手动操作
• Offset同步：可以同步Consumer Group的偏移量，实现无缝切换
• 心跳机制：通过内部Topic检测链路健康状态

3.2.2 配置示例

一个典型的双向同步配置长这样：

# mm2.properties
clusters = A, B
A.bootstrap.servers = kafka-a:9092
B.bootstrap.servers = kafka-b:9092

A->B.enabled = true
B->A.enabled = true

# Topic 同步配置
topics = .*
groups = .*

# Offset 同步
sync.topic.acls.enabled = true
emit.checkpoints.enabled = true

# 心跳
heartbeats.enabled = true

3.2.3 优缺点分析

优势	劣势
开源免费，无License成本	配置项多，调优门槛高
社区活跃，文档齐全	性能一般，单节点吞吐有限
支持双向同步	监控指标不够丰富
与Kafka版本兼容性好	Offset同步有延迟

3.3 Confluent Replicator：企业级选择

Confluent Replicator是Confluent公司提供的商业方案。说白了，它就是MM2的增强版，加了很多企业级特性。

我最早接触Replicator是在一个金融客户的项目里。他们对数据一致性要求极高，MM2的某些行为满足不了，最后选了Replicator。

3.3.1 核心增强

• Consumer Offset 精确同步：比MM2的Offset同步更可靠，延迟更低
• Schema Registry 集成：自动检查Schema兼容性，防止数据格式不匹配
• Topic 配置同步：包括分区数、副本因子、清理策略等
• 安全传输：支持TLS加密传输，适合跨机房场景

3.3.2 配置示例

# replicator.properties
name=replicator
connector.class=io.confluent.connect.replicator.ReplicatorSourceConnector

src.kafka.bootstrap.servers=kafka-a:9092
dest.kafka.bootstrap.servers=kafka-b:9092

# Topic 白名单
topic.whitelist=order.*,payment.*

# Offset 同步
offset.topic.replication.factor=3
confluent.topic.replication.factor=3

# Schema Registry
key.converter=io.confluent.connect.avro.AvroConverter
value.converter=io.confluent.connect.avro.AvroConverter
key.converter.schema.registry.url=http://schema-registry:8081
value.converter.schema.registry.url=http://schema-registry:8081

3.3.3 优缺点分析

优势	劣势
企业级特性完善	需要商业License，成本高
性能优于MM2	依赖Confluent生态
官方技术支持	社区版功能受限
监控指标丰富	升级需要付费

3.4 自研方案：灵活但代价高

自研方案，说白了就是自己写代码实现数据同步。听起来很酷，但我要泼一盆冷水——这条路不好走。

我曾经在一个项目里自研过同步工具。当时觉得MM2太慢，Replicator太贵，就自己撸了一个。结果呢？开发用了两个月，后面维护了一年还在改Bug。

3.4.1 常见实现方式

• 基于Kafka Consumer/Producer：消费源集群数据，写入目标集群
• 基于Kafka Connect：自定义Connector，利用Connect框架
• 基于日志采集：直接读取Kafka的日志文件，解析后发送

3.4.2 核心挑战

挑战	说明
Exactly-Once语义	保证数据不丢不重，需要事务或幂等性设计
Offset管理	同步Consumer Offset，支持故障恢复
Topic自动创建	源集群新增Topic时，目标集群需要自动感知
配置同步	Topic的分区数、清理策略等需要保持一致
监控告警	同步延迟、错误率等指标需要完善
高可用	单点故障时自动切换，不丢数据

3.4.3 什么时候该自研？

说实话，大部分场景不需要自研。但如果你遇到以下情况，可以考虑：

• 需要自定义数据过滤或转换逻辑
• 需要与内部监控系统深度集成
• 需要支持非标准的传输协议
• 团队有足够的人力维护

3.5 选型决策矩阵

最后给一张决策矩阵，帮你快速判断：

评估维度	MirrorMaker 2.0	Confluent Replicator	自研方案
成本	免费	高	开发人力成本高
部署复杂度	中等	低	高
性能	中等	高	取决于实现
数据一致性	较高	高	取决于实现
运维成本	中等	低	高
灵活性	低	中等	高
社区/支持	活跃社区	商业支持	内部团队