Kafka集群跨区域跨集群同步方案MirrorMaker1

Kafka集群跨区域跨集群同步方案MirrorMaker1

引用

CSDN

1.

https://blog.csdn.net/qq_34777982/article/details/138917374

在分布式系统中，Kafka集群的数据同步是一个常见的需求，特别是在跨区域部署的场景下。MirrorMaker作为Kafka官方提供的跨集群数据复制工具，其工作原理和配置细节对于系统架构师和运维工程师来说至关重要。本文将详细介绍MirrorMaker1的工作原理、配置方法以及使用中的注意事项。

MirrorMaker原理架构

上图展示了一种常见的MirrorMaker使用场景，这里作为记录。下面介绍一个实战案例。

网络架构

配置日志采集器filebeat

配置从哪里采集日志

输出到kafka集群

配置MirrorMaker消费者

参数说明：

• bootstrap.servers：指定消费哪个kafka的数据
• group.id：指定消费者加入哪个消费组，一条消息可以被多个消费组消费，在一个消费组内只能被一个消费者消费
• enable.auto.commit：默认true, 指定false表示不允许自动提交消费偏移量，避免重复消费、数据丢失
• request.timeout.ms：设置请求的超时时间，发起请求不一定能很快收到响应
• heartbeat.interval.ms：心跳间隔，确定消费者存活和退出检测机制
• session.timeout.ms：消费者会话过期时间 必须大于心跳间隔 小于请求超时
• max.poll.interval.ms：消费者处理逻辑的最大时间
• max.poll.records：消费者每次取到的消息最大数量，过大会影响在指定时间内无法完成
• auto.offset.reset：消费者在无效偏移量、没有偏移量的情况下如何处理，默认是latest，从最新记录读取，容易丢失数据，这里设置为从头开始，避免丢失数据。

配置MirrorMaker生产者

参数说明：

• bootstrap.servers：生产者的地址
• acks：指定在集群中有多少个分区副本收到消息，生产者才会认为消息写入成功，对于消息是否丢失有比较大的影响，有3个值可选，0 1 all , 其中0 、1都可能会丢失数据，all安全性最高，效率最低，2个以上分区副本时不丢失任何数据
• batch.size：生产者批量发送的基本单位
• linger.ms：限制batch无论是否写满在指定时间内必须发送,避免消息长期驻留在内存中一直不发送的情况
• max.block.ms：获取kafka集群元数据时生产者阻塞时间，超出后生产者会抛超时异常
• compression.type：指定消息发送到kafka broker前使用哪种压缩算法，gzip可降低网络传输、磁盘存储开销
• request.timeout.ms：生产者发送数据等待kafka集群响应的超时时间

启动MirrorMaker

启动先后顺序说明

查询消费情况

注意事项

这里采用的MirrorMaker1的方式来实现，kafka 2.4以后已经支持MirrorMaker2的方式。

MM1不足之处

1. 目标集群的Topic使用默认配置创建，但通常需要手动repartition。
2. acl和配置修改的时候不会自动同步，给多集群管理带来一些困难
3. 消息会被
   DefaultPartitioner
   打散到不同分区，即对一个topic ，目标集群的partition与源集群的partition不一致。
4. 任何配置修改，都会使得集群变得不稳定。比如比较常见的增加topic到whitelist。
5. 无法让源集群的producer或consumer直接使用目标集群的topic。
6. 不保证exactly-once，可能出现重复数据到情况
7. mm1支持的数据备份模式较简单，比如无法支持active <-> active互备
8. rebalance会导致延迟