我们在javakafka消费者中看到了意想不到的重新平衡，如下所述。这些问题听上去熟悉吗？有关于API或调试技术的提示来找出重新平衡的原因吗？
两个过程是阅读一个主题。有时，主题上的所有分区都会重新平衡到一个读卡器进程。在重新启动这两个进程之后，分区会得到均衡的平衡。
两个过程是阅读一个主题。有时，一长串的重新平衡会将分区从一个读取器反弹到另一个读取器。我们呼吁暂停/恢复对消费者的背压，这应该防止这一点。
两个过程是阅读一个主题。有时，当两个进程看起来都正常时，就会发生重新平衡。之后，阅读还可以，但这只是处理过程中的一个小插曲。
我们希望分区在没有看到某些原因或失败的情况下不会重新平衡。
有时 poll() 卡住（超过超时时间），我们使用 wakeup() 以及 close() ，然后创建新的消费者。有时候，协调器心跳线程在消费者关闭后继续运行（我们已经看到成千上万个）。时间安排似乎与重新平衡无关，因此重新平衡似乎是一个单独的问题，但可能心跳遇到了一个未锁定的网络问题。
我们使用 ConsumerRebalanceListener 记录和处理某些再平衡，但是kafkaapi似乎没有公开关于再平衡原因的数据。
这种再平衡是断断续续的，很难重现。它们以每秒10000到80000的消息速率发生。我们在日志中没有看到明显的错误。
我们的读取循环很简单-基本上是“在运行时，通过超时和错误处理进行轮询，然后将收到的消息排队”。
人们问了一些很好的相关问题，但答案对我们毫无帮助：
Kafka消费者（群体）触发再平衡的条件
Kafka到底在重新平衡什么？
消费者群体的持续再平衡
配置：
Kafka0.10.1.0（我们已经开始尝试1.0.0，还没有测试结果）
java 8代理和客户端
2个经纪人，1个Zookeeper，稳定的运行过程，没有添加
5个主题，2个有点忙的主题。重新平衡发生在一个繁忙的时刻（主题“a”）。
主题a有16个分区和复制2，是在使用者启动之前创建的。
一个进程写入主题a；从主题a中读取两个进程。
每个读卡器进程运行16个使用者。当16个分区平均平衡时，一些消费者处于空闲状态。
消费者线程在两次投票之间几乎不做任何工作。消息处理在独立于使用者的线程上异步进行。
主题a的所有消费者都在同一个消费者组中。
的超时 KafkaConsumer.poll() 是1000毫秒。
影响再平衡的配置是：
max.poll.interval.ms=50000 max.poll.records=100 request.timeout.ms=40000 session.timeout.ms=20000 我们使用默认值： heartbeat.interval.ms=3000 （经纪人） group.max.session.timeout.ms=300000 （经纪人） group.min.session.timeout.ms=6000