2022-02-15 带宽瓶颈导致kafka消费无法rebalance成功

美西机器消费宁夏kafka集群 跨洋网络消费 公司带宽有限制为20m

应用消费topic多 concurrency高 两台机器加起来有200+线程同时消费

问题：重启机器后 kafka rebalance期间 两台机器cpu同时飙高99% 跨洋专线带宽占满 导致服务端收不到心跳 又重新开始rebalance 进入恶性循环

原因：每次rebalance完成后，所有消费者线程获知各自被分配的partition，同时去kafka服务器拉取消息，导致瞬间带宽被占满，

稳定消费时带宽占用没有这么高是由于各消费线程拉取消息的时机不是完全同步

解决：每次服务端kafka消费线程收到rebalance完成自己被分配的消费分区时，不马上开始拉取消息，而是阻塞一段时间，错开rebalance完成后第一次消费的时机，减少瞬间带宽占用

earliest： 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费

latest： 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据

none： topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常

简单来说，如果partition里已经有数据，但还没有消费，earliest就会从没消费的起始点来消费，反观latest就不会去消费；如果partition已经有已消费的数据，再放新的数据进去，那么它们都会从新的数据开始消费。

offset会保存在kafka内部，一开始发送数据到kafka的时候就有offset，只是有没有提交而已。而使用spring-kafka时，客户端在监听topic的时候，它有2种提交offset的方式：

1、自动提交，设置enableautocommit=true，更新的频率根据参数autocommitintervalms来定。这种方式也被称为at most once，fetch到消息后就可以更新offset，无论是否消费成功。

2、手动提交，设置enableautocommit=false，这种方式称为at least once。fetch到消息后，等消费完成再调用方法consumercommitSync()，手动更新offset；如果消费失败，则offset也不会更新，此条消息会被重复消费一次。

spring-kafka版本255，官网 >

消费者要从头开始消费某个topic的全量数据，需要满足2个条件（spring-kafka）：

（1）使用一个全新的"groupid"（就是之前没有被任何消费者使用过）; （2）指定"autooffsetreset"参数的值为earliest；

注意：从kafka-09版本及以后，kafka的消费者组和offset信息就不存zookeeper了，而是存到broker服务器上，所以，如果你为某个消费者指定了一个消费者组名称（groupid），那么，一旦这个消费者启动，这个消费者组名和它要消费的那个topic的offset信息就会被记录在broker服务器上。

比如我们为消费者A指定了消费者组（groupid）为fg11，那么可以使用如下命令查看消费者组的消费情况：

bin/kafka-consumer-groupssh --bootstrap-server 17217610:9092 --describe --group fg11

在kafka官网可以看到 >

以上就是关于2022-02-15 带宽瓶颈导致kafka消费无法rebalance成功全部的内容，包括:2022-02-15 带宽瓶颈导致kafka消费无法rebalance成功、kafka消费者和offset的关系，以及异常处理问题、kafka如何从头消费历史数据等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！