我们在Java Kafka消费者中看到了意外的重新 balancer ，如下所述 . 这些问题对任何人来说都很熟悉吗？有关API或调试技术的任何提示，以找出重新 balancer 原因？

  • 两个进程正在阅读主题 . 有时，主题上的所有分区都会重新 balancer 到单个读取器进程 . 重新启动两个进程后，分区均衡 .

  • 两个进程正在阅读主题 . 有时，一系列重新 balancer 会使读者之间的分区反弹 . 我们呼吁消费者暂停/恢复背压，这应该可以防止这种情况发生 .

  • 两个进程正在阅读主题 . 有时，当两个进程看起来都正常时，会发生重新 balancer . 之后，阅读工作正常，但这是处理中的一个小问题 .

我们希望分区不会在没有看到某些原因或失败的情况下重新 balancer .

有时 poll() 卡住（超过超时）并且我们使用 wakeup() 和 close() ，然后创建新的消费者 . 有时协调器心跳线程在消费者关闭后继续运行（我们已经看到了数千个） . 时机似乎与重新 balancer 无关，因此重新 balancer 似乎是一个单独的问题，但也许心跳正在打击一个未记录的网络问题 .

我们使用 ConsumerRebalanceListener 来记录和处理某些重新 balancer ，但Kafka API似乎没有公开有关重新 balancer 原因的数据 .

重新 balancer 是间歇性的，难以重现 . 它们以每秒10,000到80,000的消息速率发生 . 我们在日志中看不到明显的错误 .

我们的读取循环很简单 - 基本上“在运行时，使用超时轮询和错误处理，然后将收到的消息排入队列” .

人们提出了很好的相关问题，但答案对我们没有帮助：

组态：

  • Kafka 0.10.1.0（我们've started trying 1.0.0 & don' t还有测试结果）

  • Java 8经纪人和客户

  • 2经纪人，1名动物园管理员，稳定的运行流程，无添加

  • 5个主题，有2个有点繁忙的主题 . 重新 balancer 发生在一个繁忙的（主题"A"） .

  • 主题A有16个分区和复制2，并在消费者启动之前创建 .

  • 一个进程写入主题A;从主题A中读取的两个进程

  • 每个读者进程运行16个消费者 . 当16个分区均衡时，一些消费者处于闲置状

  • 消费者线程在民意调查之间做的很少 . 消息处理在与消费者不同的线程上异步发生 .

  • 主题A的所有消费者都在同一个消费者群组中 .

  • KafkaConsumer.poll() 的超时为1000毫秒 .

  • 影响重新 balancer 的配置是：

  • 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

java multithreading apache-kafka kafka-consumer-api