kafka中MirrorMaker1和MirrorMaker2的区别

kafka中MirrorMaker1和MirrorMaker2的区别

一、MM1和MM2的区别

1、工作原理与架构

MM1:

  • 本质上是Kafka的消费者(Consumer)和生产者(Producer)的结合体。
  • 通过消费源集群的数据,并将其生产到目标集群,实现数据的复制和同步。
  • 使用了Kafka client的high level API。

MM2:

  • 基于Kafka Connect框架开发,利用了Kafka Connect的source connector和sink connector。
  • Source connector负责读取远端数据中心的数据,sink connector负责将拉回来的数据写入本地的数据中心。
  • 提供了更高级的同步机制,如自动探测新topic、自动同步topic配置和ACL(访问控制列表)等。

2、功能与特性

MM1:

  • 功能相对简单,主要实现数据的复制和同步。
  • 缺乏监控手段,无法实时了解同步任务的状态和性能。
  • 在处理active-active场景时,需要手动配置来解决循环同步问题。

MM2:

  • 提供了丰富的监控指标和管理接口,可以实时监控复制任务的状态和性能。
  • 支持跨版本兼容,可以方便地在不同版本的Kafka集群之间进行数据复制和同步。
  • 提供了更高的灵活性和可扩展性,可以根据实际需求进行配置,满足不同的数据同步需求。
  • 支持active-active集群对以及任意数量的active集群,支持跨IDC同步、aggregation和其他复杂拓扑。

3、部署与维护

MM1:

  • 部署相对复杂,需要为每个需要同步的Kafka集群对配置一个MirrorMaker实例。
  • 在维护方面,需要定期检查和调整配置,以确保同步任务的正常运行。

MM2:

  • 部署更加简单,可以通过Kafka Connect集群来管理多个同步任务。
  • 提供了更简洁的配置方式,降低了维护成本。

4、性能与稳定性

MM1:

  • 在网络不稳定或负载较高的情况下,可能会遇到频繁的rebalance问题,影响同步的稳定性和效率。

MM2:

  • 采用了更先进的同步机制,避免了频繁的rebalance问题。
  • 提供了更高的吞吐量和更低的延迟,适用于大数据场景下的数据同步。

二、MM1局限性

  • 静态的黑名单和白名单
  • topic信息不能同步
  • 必须通过手动配置来解决active-active场景下的循环同步问题
  • rebalance导致的性能问题
  • 缺乏监控手段
  • 无法保证Exactly Once
  • 无法提供容灾恢复

三、kafka带来的MM2

1、MM2简介

kafka开源社区也终于在kafka2.4带来了自己的企业级解决方案MirrorMaker-V2(MM2)。MM2修复了MM1所存在的局限性。

MM2是基于kafka connect框架开发的。与其它的kafka connecet一样MM2有source connector和sink connetor组成,不熟悉kafka connect概念的同学可以这样认为,source connector就是MM1中的消费者,它负责读取远端数据中心的数据。sink connetor是生产者,他负责将拉回来的数据写入本地的数据中心。

MM2共含有4种类型的connector:

MirrorSourceConnector

MirrorSinkConnector

MirrorCheckpointConnector

MirrorHeartbeatConnector

与MM1不同的是,MM2的source和sink两个connector包含了,源数据的消费者,远端数据的生产者,和一对AdminClient用来同步topic配置信息。

它的部署方式跟MM1相同,都是部署在目标集群方。

2、MM2具有如下特性:

  • 基于Kafka Connect framework和生态

  • 自动探测新topic, partition

  • 自动同步topic配置,自动同步topic acl

  • 支持active-active集群对,以及任意数量的active集群

  • 支持跨IDC同步, aggregation和其他复杂拓扑

  • consumer offset等meta信息的同步和翻译

  • no rebalance,减少同步波动

  • 提供广泛的指标,例如跨多个数据中心/集群的端到端复制延迟

  • 容错和水平可扩展

3、MM2配置详解:

java 复制代码
#定义集群别名
clusters = A, B
A.bootstrap.servers = A_host1:9092, A_host2:9092, A_host3:9092 # 设置A集群的kafka地址列表
B.bootstrap.servers = B_host1:9092, B_host2:9092, B_host3:9092 # 设置B集群的kafka地址列表
A->B.enabled = true # 开启A集群向B集群同步
A->B.topics = .* # 允许同步topic的正则

B->A.enabled = true # 开启B集群向A集群同步
B->A.topics = .* # 允许同步topic的正则

#MM2内部同步机制使用的topic,replication数量设置
checkpoints.topic.replication.factor=1
heartbeats.topic.replication.factor=1
offset-syncs.topic.replication.factor=1

offset.storage.replication.factor=1
status.storage.replication.factor=1
config.storage.replication.factor=1

#自定义参数
sync.topic.configs.enabled=true #是否同步源topic配置信息
sync.topic.acls.enabled=true #是否同步源ACL信息
emit.heartbeats.enabled=true #连接器是否发送心跳
emit.heartbeats.interval.seconds=5 #心跳间隔
emit.checkpoints.enabled=true #是否发送检查点
refresh.topics.enabled=true #是否刷新topic列表
refresh.topics.interval.seconds=5 #刷新间隔
refresh.groups.enabled=true #是否刷新消费者组id
refresh.groups.interval.seconds=5 #刷新间隔
readahead.queue.capacity=500 #连接器消费者预读队列大小
replication.policy.class=org.apache.kafka.connect.mirror.DefaultReplicationPolicy #使用LegacyReplicationPolicy模仿MM1
heartbeats.topic.retention.ms=1 day #首次创建心跳主题时,设置心跳数据保留时长
checkpoints.topic.retention.ms=1 day #首次创建检查点主题时,设置检查点数据保留时长
offset.syncs.topic.retention.ms=max long #首次创建偏移量主题时,设置偏移量数据保留时长
replication.factor=2 #远端创建新topic的replication数量设置

4、MM2启动

java 复制代码
bin/connect-mirror-maker.sh config/connect-mirror-maker.properties
相关推荐
qq_12498707538 小时前
基于Hadoop的信贷风险评估的数据可视化分析与预测系统的设计与实现(源码+论文+部署+安装)
大数据·人工智能·hadoop·分布式·信息可视化·毕业设计·计算机毕业设计
ask_baidu9 小时前
KafkaUtils
kafka·bigdata
洛豳枭薰10 小时前
消息队列关键问题描述
kafka·rabbitmq·rocketmq
lucky670711 小时前
Spring Boot集成Kafka:最佳实践与详细指南
spring boot·kafka·linq
Coder_Boy_11 小时前
基于Spring AI的分布式在线考试系统-事件处理架构实现方案
人工智能·spring boot·分布式·spring
袁煦丞 cpolar内网穿透实验室12 小时前
远程调试内网 Kafka 不再求运维!cpolar 内网穿透实验室第 791 个成功挑战
运维·分布式·kafka·远程工作·内网穿透·cpolar
岁岁种桃花儿12 小时前
CentOS7 彻底卸载所有JDK/JRE + 重新安装JDK8(实操完整版,解决kafka/jps报错)
java·开发语言·kafka
人间打气筒(Ada)12 小时前
GlusterFS实现KVM高可用及热迁移
分布式·虚拟化·kvm·高可用·glusterfs·热迁移
xu_yule12 小时前
Redis存储(15)Redis的应用_分布式锁_Lua脚本/Redlock算法
数据库·redis·分布式
難釋懷17 小时前
分布式锁的原子性问题
分布式