kafka集群跨区域跨集群同步方案MirrorMaker1 —— 筑梦之路

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会导致延迟