卡夫卡重新平衡和听众陷阱

Question

我正在阅读Kafka:The Definitive Guide,并希望更好地理解重新平衡监听器.本书中的示例简单地使用a HashMap来维护已处理的当前偏移量,并在撤销分区时提交当前状态.我担心的是:

我在代码示例中有两个问题/问题:

1. 使用的语言让我假设这些回调是在不同的线程上进行的.那么,在应用当前偏移量时,是否应该考虑线程安全性？此外,在提交后,当前批次是否应该取消？
2. 它说使用commitSync确保在重新平衡进行之前提交偏移量.然而,这仅在该消费者中是同步的.有没有一种机制让协调员在收到所有订阅消费者的回复之前不会继续进行？

Answer 1

1. 我重新阅读了本书中的内容，我也感到有些困惑！

   该Javadoc中指出：

   每当分区分配更改时，此回调将仅作为poll（long）调用的一部分在用户线程中执行。

   我看了一下代码，确认再平衡监听器方法确实在拥有使用者的同一线程中被调用。

2. 是的commitSync()，在重新平衡监听器中提交时应该使用。

   为了解释原因，让我们看一下黄金路径示例。我们从一个愉快地消费并定期向协调员心跳的消费者开始。协调器有时会REBALANCE_IN_PROGRESS向心跳请求返回错误。这可能是由于新成员想要加入组，成员离开或心跳失败或正在从订阅中添加/删除新分区引起的。此时，所有消费者都需要重新加入该组。

   尝试重新加入该组之前，使用者将同步执行 ConsumerRebalanceListener.onPartitionsRevoked()。侦听器返回后，消费者将向该协调器发送一个JoinRequest以重新加入该组。

   就是说，我想这就是您的想法，如果您的回调花费太长时间（> session.timeout.ms）提交，则该组可能已经存在于另一代中，并且尝试将具有偏移量的分区分配给另一个成员。在这种情况下，即使提交是同步的，提交也将失败。但是通过commitSync()在侦听器中使用，可以确保使用者在完成提交之前不会重新加入该组。