前言

重分配？

这是 kafka 应对消费组成员发生变动时，重新分配工作的机制，让你的消费组中的消费者尽可能的得到"公平"的工作量。

消费组停止消费了？

你有没有遇到过，消息只增不减，消息越积越多的情况？可能你的消费组正在重分配，而且可能是频繁的重分配。

当消费组进入重分配阶段时，消费组将暂停消费，直到重分配完成。

排查

Kafka 提供了重平衡机制来保证多个消费者公平地从 Kafka Topic 中消费消息，即当消费者的数量变化时，Kafka 会重新将 Topic 的 Partition 分配给所有的消费者。若遇到 Kafka 重分配问题，我们可以从以下几个方面查找解决方案：

检查消费者组中的消费者数量以及 Topic 的分区数量

确保消费者数量不大于 Topic 的分区数量，因为一个分区在一个时刻只能被一个 Consumer Group 中的一个 Consumer 消费。

检查消费者代码

在消息处理中，若处理时间过长或者在处理消息时，消费者挂起，都将可能引发 Consumer Rebalance。所以需要保证消息处理的逻辑尽可能地快，并要处理好异常，避免 Consumer Crash。

设置合理的 Session Timeout 和 Heartbeat Interval

Kafka Broker 利用 Session Timeout 来判定一个消费者是否死亡。当 Kafka Broker 在 Session Timeout 时间内没有收到 Consumer 的心跳时，就认为这个 Consumer 已经挂了，并触发 Consumer Rebalance。

为了避免不必要的 Rebalance，我们可以将 Session Timeout 设置地大一些，并缩短 Heartbeat Interval，使得 Consumer 可以更频繁地发送心跳。

精确控制消费进度

确保在消费者关闭或进程结束时，消费进度已经保存，这样新的消费者在接管分区后，不会发生消息的重复消费。

升级 Kafka 版本

一些较旧的 Kafka 版本存在处理 Rebalance 问题的 Bug，升级 Kafka 版本可能解决这些问题。

总的来说

总的来说，Kafka 的 Rebalance 机制对于实现 Consumer 的伸缩性和容错性非常重要，但是不合适的使用方法和配置会导致频繁的 Rebalance 现象，降低系统的整体性能。

理解其工作机制并进行合理配置，是解决问题的关键。

更进一步

除了上述提到的，确实还有一些其他可能的策略来解决 Kafka 中频繁重平衡的问题：

静态消费者组成员关系

在 Kafka 2.3.0 及更新版本中，提供了静态消费者成员关系选项。在这个模式下消费者组成员可以保持其 GroupInstanceId，即使会话超时也不会被认为是离开的，可以有效的减少不必要的再平衡。

设置静态成员，需要在消费者配置中设置 group.instance.id，必须是唯一，且不能被用于再加入同一消费者组的其他成员。

ini 复制代码

Properties props = new Properties();
props.put("group.instance.id", "consumer-instance-1");

调整会话超时参数和心跳时间间隔

根据你的消费者负载和网络延迟，可适当增加会话超时参数和心跳时间间隔，以防由于这些因素导致的不必要的再平衡。

例如，"heartbeat.interval.ms"设置为3000，"session.timeout.ms"设置为10000。

java 复制代码

Properties props = new Properties();
props.put("heartbeat.interval.ms", "3000");
props.put("session.timeout.ms", "10000");

使用最新的Kafka Consumer API

如果你仍在使用老版本的 Kafka Consumer API，可以考虑升级。最新版本的 API 提供了更好的管理和控制消费者进行数据消费，包括调用 poll 的频率，处理消息的时间等。

关闭不必要的消费者

减少消费者组中消费者的数量，尽可能的保持消费者的稳定，频繁的新增或关闭消费者会导致消费者组重新平衡。

如果这些措施都试过了仍无法解决，建议做进一步的系统和网络状况调查以找出问题的根源。

参数调整

在 Kafka 中，你可以通过以下参数进行调整来消除或者减少消费者的重新分配（Rebalance）：

max.poll.interval.ms

这个参数用于控制两次 poll 操作之间的最大允许延迟。

如果设置过小，消费者处理时间如果超过这个值，就会被认为是失败的，从而触发 Rebalance。根据你的业务，如果处理逻辑可能会比较耗时，就需要适当提高这个值。

max.poll.records

这个参数用于控制单次 poll 操作的最大记录数。

如果设置为一个大值，那么 poll 函数可能会阻塞很长时间用来等待足够数量的记录，这可能导致 consumer 无法在 session.timeout.ms 规定的时间内发送心跳，从而导致 Rebalance。如果你的业务允许，适当降低这个值可以避免此问题。

heartbeat.interval.ms

这个参数主要用于设置消费者向 Kafka 服务器发送心跳的频率，这个频率在 session.timeout.ms 的基础上设定。

如果这个值设置过大，可能导致长时间没有发送心跳导致 Rebalance。通常来说，应设置为：session.timeout.ms 的 1/3。

session.timeout.ms

这个参数主要用于设置服务器等待消费者心跳的超时，超过设定值没有收到消费者的心跳，就会触发 Rebalance。如果网络环境不佳，或者消费者处理逻辑复杂，需要适当提高这个值。

这几个参数需要根据具体的业务需求以及 Kafka 集群的状态进行权衡和调整。理解每个参数的含义以及怎么影响 Rebalance 能帮助你更好地进行设置和优化。

kafka重分配，消费组停止消费？

前言