kafka 中参数：session.timeout.ms 和 heartbeat.interval.ms的区别

给大家推荐一款好用的优快云云服务，新人首购折扣哦，点击下图跳转：

---

涉及到三个参数：

• session.timeout.ms：group coordinator检测consumer发生崩溃所需的时间。一个consumer group里面的某个consumer挂掉了，最长需要 session.timeout.ms 秒检测出来。它指定了一个阈值—10秒，在这个阈值内如果group coordinator未收到consumer的任何消息（指心跳），那coordinator就认为consumer挂了。
• heartbeat.interval.ms：每个consumer 都会根据 heartbeat.interval.ms 参数指定的时间周期性地向group coordinator发送 hearbeat，group coordinator会给各个consumer响应，若发生了 rebalance，各个consumer收到的响应中会包含 REBALANCE_IN_PROGRESS 标识，这样各个consumer就知道已经发生了rebalance，同时 group coordinator也知道了各个consumer的存活情况。
• max.poll.interval.ms：如果consumer两次poll操作间隔超过了这个时间，broker就会认为这个consumer处理能力太弱，会将其踢出消费组，将分区分配给别的consumer消费 ，触发rebalance 。

总结：new KafkaConsumer对象后，在while true循环中执行consumer.poll操作拉取消息中，会有两个线程执行：一个是heartbeat 线程，另一个是processing线程。

• processing线程可理解为调用consumer.poll方法执行消息处理逻辑的线程，
• 而heartbeat线程是一个后台线程，对程序员是"隐藏不见"的。heartbeat线程每隔heartbeat.interval.ms向coordinator发送一个心跳包，证明自己还活着。但是如果group coordinator在一个heartbeat.interval.ms周期内未收到consumer的心跳，就把该consumer移出group，这有点说不过去。事实上，有可能网络延时，有可能consumer出现了一次长时间GC，影响了心跳包的到达，说不定下一个heartbeat就正常了。而如果group coordinator在session.timeout.ms 内未收到consumer的心跳，那就会把该consumer移出group。

而max.poll.interval.ms参数，在consumer两次poll操作间隔超过了这个时间，即consumer的消息处理逻辑时长超过了max.poll.interval.ms，该消费者就会被提出消费者组。

---

---

多个业务往向一个Kafka topic发送消息，有些业务的消费量很大，有些业务的消息量很小。因Kafka尚未较好地支持按优先级来消费消息，导致某些业务的消息消费延时的问题。

一种简单的解决方案是再增加几个Topic，面对一些系统遗留问题，增加Topic带来的是生产者和消费者处理逻辑复杂性。

一种方法是使用Kafka Standalone consumer，先使用consumer.partitionFor("TOPIC_NAME")获取topic下的所有分区信息，再使用consumer.assign(partitions)显示地为consumer指定消费分区。

另一种方法是基于consumer group 自定义Kafka consumer的分区分配策略，那这时候就得对Kafka目前已有的分区分配策略有所了解，并且明白什么时候、什么场景下触发rebalance？

1、heartbeat.interval.ms

Kafka consumer要消费消息，哪些的分区的消息交给哪个cons