📊 一、MirrorMaker 1.0(MM1)
⚙️ 核心架构
- 基础模型:基于“Consumer + Producer”组合,单向同步数据。
- 部署模式:
- 单向同步:集群A → 集群B(需手动配置主题映射)。
- 双向同步:需部署两套独立实例(如A→B和B→A),通过主题重命名(如添加
DC1_
、DC2_
后缀)避免循环复制。
- 关键问题:
- 消息循环:相同主题双向同步需业务层过滤或依赖外部工具(如
mirrormaker_topic_rename
)。
- 静态配置:白名单/黑名单更新需重启服务,引发数据堆积和吞吐风暴。
- Offset管理缺失:目标集群无法继承源集群的消费位移,故障切换时需重新消费或依赖时间戳(导致重复数据)。
⚠️ 缺陷总结
问题 |
影响 |
配置不可动态更新 |
运维复杂,扩容需新增N×(N-1)个实例 |
频繁Rebalance |
网络波动时同步延迟波动大 |
无ACL/配置同步 |
需手动维护目标集群权限 |
仅支持至少一次语义 |
数据重复风险高 |
🚀 二、MirrorMaker 2.0(MM2)
⚙️ 架构升级
- 基础模型:基于Kafka Connect框架,整合Source/Sink Connector,支持复杂拓扑(双活、聚合、链式同步)。
- 核心组件:
- MirrorSourceConnector:同步数据及Topic配置。
- MirrorCheckpointConnector:同步Consumer Group Offset(通过
__checkpoint
内部Topic映射位移)。
- MirrorHeartbeatConnector:监控同步链路健康度。
- 动态能力:
- 自动检测新Topic/分区,通过REST API动态更新同步规则(无需重启)。
- 自动同步ACL权限(WRITE权限除外)。
🔧 双活方案实现
- 防循环复制:自动添加集群别名前缀(如
DC_A.TopicX
),过滤本地集群前缀消息。
- 故障切换:
- Producer切换写入目标集群。
- Consumer通过
__checkpoint
定位目标集群Offset,实现无缝续消费。
✅ 优势对比MM1
特性 |
MM1 |
MM2 |
部署复杂度 |
高(N集群需N×(N-1)实例) |
低(N集群仅需N个实例) |
Offset同步 |
不支持 |
通过offset_sync Topic映射 |
动态配置 |
需重启生效 |
REST API实时更新 |
数据一致性 |
至少一次(重复率高) |
至少一次(支持EOS规划中) |
🔧 三、部署实践
📦 MM2部署模式
模式 |
适用场景 |
特点 |
Connect集群模式 |
生产环境(推荐) |
高可用,水平扩展 |
Dedicated集群模式 |
独立资源池 |
专用Driver管理任务 |
Standalone模式 |
测试环境 |
单Worker运行 |
⚙️ K8S部署示例(Strimzi Operator)
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
name: mm2-cluster
spec:
version: 3.7.0
connectCluster: "target-cluster"
clusters:
- alias: "source-cluster"
bootstrapServers: kafka-source:9092
- alias: "target-cluster"
bootstrapServers: kafka-target:9092
mirrors:
- sourceCluster: "source-cluster"
targetCluster: "target-cluster"
sourceConnector:
tasksMax: 4
checkpointConnector:
tasksMax: 1
topicsPattern: ".*"
groupsPattern: ".*"
⚠️ 四、局限性与演进
🔒 当前限制
- 仅至少一次语义:跨集群事务未原子化,可能重复(正开发EOS支持)。
- 同步性能:非对等复制场景需序列化/反序列化,吞吐受限(未来支持二进制流直传)。
⏭️ 演进方向
- Exactly-Once语义(EOS):利用
__checkpoint
Topic与目标集群事务绑定。
- 零拷贝同步:同配置集群间跳过数据处理环节,提升吞吐。
💎 总结:选型建议
- MM1:仅适用于非关键业务的简单同步场景(如日志备份)。
- MM2:生产级双活方案首选,尤其适合要求:
- 动态扩缩容
- 精确Offset恢复
- 自动化运维
- 复杂拓扑(如多活、聚合)