开发中遇到的一些Kafka问题以及它的Rebalance机制介绍

项目开发过程中遇到的一些问题：

问题1：环境中配置的replica.fetch.max.bytes该值偏大，导致有节点下线后同步数据会出现网卡塞满的情况，建议该值在百兆网下配置10M，千兆网20M左右。

 

问题2：kafka不消费数据。后来发现是超时时间设置的的太短，消费还未处理完就已经被kafka认为超时，导致消费失败，offset不提交，所以一直消费那一批数据。修改超时时间即可。

 

问题3：自己管理offset的时候，在发生ConsumerRebalance时需要清除保存的信息，不然在下次切换时可能存在offset大量回退，原因如下：

如0,1共两个partition，线程1消费0，线程2消费1,在发生切换时，两个线程都没有清除原始的记录，会出现线程1保存0、1,线程2也保存0、1，而实际消费中线程1中只会拉去1，线程2只会拉取0，而不会更新其他的partition的offset，导致下次再发生切换时没有更新的partition被提交到kafka中就会出现大量回退。

 

补充： Kafka Consumer的Reblance机制介绍

Reblance本质上是一种协议，规定了一个Consumer Group下的所有的Consumer如何达成一致来分配订阅Topic的每个Partition。比如某个group下有5个consumer，它订阅了一个具有10个分区的topic。正常情况下，Kafka平均会为每个consumer分配2个分区。这个分配的过程就叫rebalance。

 

Rebalance的触发条件：

1.有新的消费者加入Consumer Group

2.有消费者下线，可能由于长时间未向GroupCoordinator(协调者)发送心跳，GroupCoordinator会认为其已下线

3.有消费者主动退出Consumer Group

4.订阅的topic分区出现变化

5.调用unsubscribe()取消对某Topic的订阅

即Consumer或者Topic自身发生变化时，会触发Rebalance。

 

GroupCoordinator(协调者)：

GroupCoordinator是协调消费者组完成消费者Rebalance的重要组件，每一个broker都会启动一个GroupCoodinator，Kafka 按照消费者组的名称将其分配给对应的GroupCoodinator进行管理；每一个GroupCoodinator只负责管理一部分消费者组，而非集群中全部的消费者组。

 

分区的分配策略主要有三种：

1.RangePartitionAssignor：

针对每一个topic：

n = 分区数/消费者数量

m = 分区数%消费者数量

前m个消费者每个分配n+1个分区，后面的 （消费者数量-m）个消费者每个分配n个分区

 

2.RoundRobinAssignor：

将所有的Topic和Partition按照字典顺序排序，然后对每个Consumer进行轮询分配

 

3.自定义分配策略：实现AbstractPartitionAssignor类的assign()方法

 

 

参考：

www.cnblogs.com/huxi2b/p/6223228.html(Kafka reblance流程分析)