Apache Kafka 3.2.1定义了744个不同的配置参数，分布在Broker、生产者、消费者和其他组件中。当然，其中大部分都有合理的默认值，以使技术的入职成为可能。你可能甚至不需要知道其中的大部分，而其他的参数可能会对你的解决方案--以及你的度假计划--造成直接的危险。
"我们看不到任何更新，我们认为这与Kafka有关"
这是我在暑假期间准备与一些朋友共进美好午餐时听到的第一句话。
"看来，消费者正在反复处理同样的信息...... "他们继续说道
在放弃我的午餐计划，打开笔记本电脑，滚动浏览一些应用程序的日志后，我可以得出结论，他们最初的分析似乎是正确的：对于某个主题，消费者被卡住了，反复处理相同的记录，这意味着目标系统从未像预期的那样更新。奇怪的是，在生产的几年里，这个流程从来没有出现过这种问题。
然而，我很快意识到，这只是另一个 "缓慢的消费者 "的案例，我们以前也有过几次。像以前一样，解决方案是调整max.poll.records和/或max.poll.interval.ms的默认设置。
作为参考，这是我们的日志中显示的内容，注意Kafka在INFO（！）级别上记录了这个内容。
Consumer clientId=status-listener, groupId=status-groupId] Member my-member sending LeaveGroup request to coordinator hostname.net:9093 (id: 2147483646 rack: null) due to consumer poll timeout has expired. This means the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time processing messages. You can address this either by increasing max.poll.interval.ms or by reducing the maximum size of batches returned in poll() with max.poll.records.
默认情况下，Kafka没有为慢速消费者配置。
对于一个消费者来说，我们的代码和Kafka客户端库之间的接口可以归结为poll()方法。这个方法将从经纪人那里获取记录，并向我们的代码返回0或更多的记录，这取决于主题上是否真的有任何未消耗的记录。上面的配置值就是在这里发挥作用的。
- 我们将最多得到max.poll.records
- 我们必须每隔max.poll.interval.ms 至少调用一次该方法，否则客户端库会认为我们的代码不再对消费感兴趣（或者已经死了之类的）而离开消费组。这种行为使其他一些消费者实例能够接上并继续。
(在我们的案例中，我们使用Spring Kafka，它抽象了poll()方法，只给我们一个回调处理程序)
这两个配置属性基本上对我们的代码提出了以下要求：它需要能够在max.poll.interval.ms毫秒内消耗max.poll.records。这些的默认值是。500和300000（5分钟），平均每条记录给代码0,6秒。现在，如果你对每条记录有一些处理（在我们的例子中：几个数据库操作），600ms可能是一个相当苛刻的限制。正如你可能已经猜到的，在这个场合，我们的消费者比这个速度要慢。然后发生的事情是，这些记录一直没有被提交，另一个实例拿起了同一批记录，过了一会儿又遇到了完全相同的问题。所以消费者只是一遍又一遍地重新处理同一批记录，没有取得任何进展。
一个棘手的问题是，这个问题只有在批次变得足够大时才会表现出来。例如，如果消费者被关闭了一段时间，或者我们的生产记录突然激增，这种情况就会发生。但只要消费者不明显滞后，批次就足够小，它就能在max.poll.interval.ms ms内完成。在我们的案例中，花了大约2年时间，直到这个问题出现。
摘要
请仔细注意，默认的消费者配置是假设一个相当快的消费者。如果不是这样，你应该考虑重新配置max.poll.records或max.poll.interval.ms（或两者）。
- 降低max.poll.records不会影响某些故障场景的反应速度，但有一个缺点，即由于整体开销增加（批处理减少）而降低吞吐量。
- 增加max.poll.interval.ms不会影响吞吐量，但会导致消费者重新平衡的响应速度变慢。
