📊 一、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.0connectCluster: "target-cluster"clusters:- alias: "source-cluster"bootstrapServers: kafka-source:9092- alias: "target-cluster"bootstrapServers: kafka-target:9092mirrors:- sourceCluster: "source-cluster"targetCluster: "target-cluster"sourceConnector:tasksMax: 4checkpointConnector:tasksMax: 1topicsPattern: ".*"groupsPattern: ".*"
⚠️ 四、局限性与演进
🔒 当前限制
- 仅至少一次语义:跨集群事务未原子化,可能重复(正开发EOS支持)。
- 同步性能:非对等复制场景需序列化/反序列化,吞吐受限(未来支持二进制流直传)。
⏭️ 演进方向
- Exactly-Once语义(EOS):利用
__checkpoint
Topic与目标集群事务绑定。 - 零拷贝同步:同配置集群间跳过数据处理环节,提升吞吐。
💎 总结:选型建议
- MM1:仅适用于非关键业务的简单同步场景(如日志备份)。
- MM2:生产级双活方案首选,尤其适合要求:
- 动态扩缩容
- 精确Offset恢复
- 自动化运维
- 复杂拓扑(如多活、聚合)