应用程序在用户组中有以下用户
消费者a收听主题1。主题1有一个分区。对于此使用者，max.poll.interval.time.ms=4小时。
消费者b收听主题2。主题2有5个部分。消费者b并发=5。对于此使用者，max.poll.interval.time.ms=1小时。
应用程序重新启动时发生了什么，以及其中一个主题是否已发布消息
当应用程序重新启动一个创建的使用者示例（consumera1）并订阅topic1时。consumera1找到组坐标（gc）并发送加入组请求。
consumera1从gc得到响应并成为leader。直到这个步骤，其他使用者都没有初始化。
consumera1分配分区并向gc发送syncgroup请求。产生新的任务。这样就完成了第一次再平衡。
主题1上的消息已发布，consumera1获取此消息并开始处理。完成此消息的处理需要大量时间(比如2小时）
现在5个使用者示例逐一初始化，所有示例都订阅了topic2。这些使用者找到gc并发送加入组请求。但是gc没有回应他们。
当consumera1向gc发送heartbeat时，gc响应重新平衡正在进行，但是consumera1不会撤销分区，因为它正在处理消息。
根据重新平衡协议（关于重新平衡的好文章），gc等待所有使用者发送加入组请求。在这种情况下，gc等待从consumera1获取加入组请求。最大等待时间为max.poll.interval.time.ms，在这种情况下为4小时。
根本原因：
组协调器没有在应用程序重新启动后等待所有使用者初始化，因此发生了第一次不必要的重新平衡，因此consumera1从分区中获取消息并开始处理它。
解决方案：为了避免这种不必要的初始重新平衡，kafka提供了一种配置，其中组协调器等待消费者加入新的消费者组。文档
group.initial.rebalance.delay.ms组
检查了my kafka server.properties，设置为0。尝试默认设置，即3秒。避免了初始重新平衡，gc在应用程序重新启动时等待3秒钟，并且在这段时间内所有其他使用者都已初始化。所有使用者都发送了加入组请求，因为所有gc都从所有使用者处获得了请求。总承包商毫不迟疑地作出了回应，重新平衡工作顺利进行并完成。