单Pod微服务同Kafka Topic收发时无法接收其他服务消息问题排查

核心原因：单实例下Kafka消费者的分区独占与顺序拉取特性导致业务消息被重试消息挤占 #

以下是具体细节拆解：

• 消费者组的分区独占分配
  当Service1以同一个消费者组ID运行单Pod实例时，Kafka会将Topic A的所有分区全部分配给这个实例。Service3发送的消息确实会进入Topic A的某个分区，但该分区的消费权完全被当前Service1实例掌握。

• 顺序拉取导致重试消息优先被消费
  Confluent Kafka消费者默认按分区内的offset顺序拉取消息。Service1每次发送的重试消息会被追加到分区消息队列的末尾，成为最新消息。当Service1处理完一条重试消息后，又立即发送新的重试消息，消费者下一次拉取时会优先获取这条最新的重试消息——Service3每分钟发送的消息因为产生频率极低，会被淹没在不断产生的重试消息队列中，始终得不到处理的机会。

• 单实例消费资源被占满
  单Pod的Service1的消费能力被持续产生的重试消息完全占用，没有多余的资源去拉取和处理Service3的消息。而扩容Pod后，多个实例属于同一个消费者组，Kafka会重新平衡分区分配，Service3的消息可能被分配到未陷入重试循环的实例上，该实例处理完Service3的消息后更新数据库状态，最终让所有Service1实例退出重试循环。

• 重试消息与业务消息未隔离
  将重试消息和业务消息放在同一个Topic A是设计上的隐患。重试消息的产生速度远高于Service3的业务消息，会直接挤占业务消息的消费通道。如果将重试消息拆分到单独的重试Topic（比如topic-a-retry），让Service1单独消费重试Topic，就能避免业务消息被重试消息淹没的问题。

内容的提问来源于stack exchange，提问作者Kumar Rahul