前言
重分配？
这是 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，必须是仅有，且不能被用于再参加同一顾客组的其他成员。
Properties props = new Properties();
props.put("group.instance.id", "consumer-instance-1");
调整会话超时参数和心跳时刻距离
依据你的顾客负载和网络推迟，可恰当添加会话超时参数和心跳时刻距离，以防由于这些因素导致的不必要的再平衡。
例如，“heartbeat.interval.ms”设置为3000，“session.timeout.ms”设置为10000。
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 能协助你更好地进行设置和优化。
