这是我们在负载测试环境中看到的Kafka重复消费场景的概念描述:
- GIVEN两个应用程序实例在单独的EC2实例上，每个实例有一个Kafka消费者，每个消费者组ID相同。
- 使用Spring batchacknowledgement messagelistener进行给定消费，该listener同步消费一个批处理，然后调用acknowledgement .acknowledge()。
- 给定单线程ConcurrentMessageListenerContainer与AckMode MANUAL_IMMEDIATE和syncCommits启用
- 当其中一个应用程序实例关闭(它的消费者离开消费者组)
- THEN消费者组被重新平衡，以便剩余的消费者获得所有分区。
- 当第一个应用实例再次启动(它的消费者加入消费者组)。
- 然后重新平衡消费者组，以便每个消费者获得一半的分区。
- 然后少数消息被两个消费者成功地消费。
- THEN在分区撤销被记录之前，被撤销一半分区的消费者会记录一个或多个这种类型的消息:
2022-11-17 08:24:21,809 INFO [consumer-0-C-1] o.a.k.c.c.i.ConsumerCoordinator [ConsumerCoordinator.java:1156] [Consumer clientId=consumer-xms-batch-mt-callback-3, groupId=xms-batch-mt-callback] Failing OffsetCommit request since the consumer is not part of an active group
在中等流量负载(每秒消耗1000条记录)下执行应用程序实例重新启动的测试用例时，有时会发生这种情况。相反，当没有重复时，首先记录分区撤销，然后才记录失败偏移提交的日志条目。
在这个用例中，重复消费是预期的行为吗?我不这么认为，而且我很难理解同步消费者怎么可能做到这一点。我的理解是，侦听器线程总是按顺序进行轮询和消费，分区撤销发生在轮询期间。我们使用的是kafka-client版本3.1.1和spring-kafka版本2.8.6，我还没有发现任何已知的导致重复的缺陷。
我们从AckMode MANUAL开始，然后更改为MANUAL_IMMEDIATE，以防它可能与延迟提交绑定。
报告为spring-kafka缺陷，修复将包含在3.0.1版本中。