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
相关推荐
孙克旭_5 小时前
第三章 分布式缓存Redis
redis·分布式·缓存
SlothLu7 小时前
Debezium-BinaryLogClient
java·mysql·kafka·binlog·多线程·debezium·数据迁移
天冬忘忧8 小时前
Kafka 消费者全面解析:原理、消费者 API 与Offset 位移
大数据·kafka
jlting1959 小时前
《智慧教育实时数据分析推荐项目》详细分析
大数据·redis·sql·kafka·database
好看资源平台9 小时前
网络爬虫——分布式爬虫架构
分布式·爬虫·架构
_Matthew9 小时前
学习Zookeeper
分布式·zookeeper·云原生
JoyousHorse10 小时前
单体架构、集群架构和分布式架构概述
分布式·架构·软件工程·软考·系统架构设计师
油头少年_w11 小时前
Hadoop进阶原理(HDFS、MR、YARN的原理)
大数据·hadoop·分布式
圆蛤镇程序猿12 小时前
【什么是RabbitMQ】
分布式·rabbitmq
张彦峰ZYF13 小时前
接口性能优化宝典:解决性能瓶颈的策略与实践
java·redis·分布式·后端·算法·性能优化·架构