这问题我之前帮同事排查过类似的，结合你给出的消费者配置和现象，核心问题大概率出在主题分区数量或者分区分配逻辑上，咱们一步步来拆解：

最可能的原因：主题分区数不足 #

Kafka的消费者组有个核心规则：同一个消费者组内，每个分区只能被一个消费者消费。如果你的目标主题只有3个分区，那不管你启动多少个消费者，最多只有3个能分配到分区并接收消息，剩下的2个会处于空闲状态，完全收不到数据——这正好匹配你的现象。

怎么验证？ #

用Kafka自带的命令行工具查看主题详情：

kafka-topics.sh --describe --topic <你的目标主题名> --bootstrap-server localhost:9092

重点看输出里的PartitionCount字段，如果数值是3，那这就是问题根源。

解决方法 #

如果业务允许，直接给主题增加分区（注意：Kafka主题分区数只能增加不能减少）：

kafka-topics.sh --alter --topic <你的目标主题名> --partitions 5 --bootstrap-server localhost:9092

增加到5个分区后，消费者组会自动触发重新平衡，很快5个消费者就能各自分到1个分区，都能收到消息了。

第二步：检查消费者组的分区分配状态 #

不管分区数是否足够，先确认当前消费者组的分配情况，用以下命令：

kafka-consumer-groups.sh --describe --group temp_topic_group1 --bootstrap-server localhost:9092

重点看ASSIGNMENT列，你会看到：

• 正常的3个消费者会显示分配到的分区ID
• 故障的2个消费者对应的ASSIGNMENT会是空的

如果是这种情况，要么是分区数不够，要么是分配策略导致的不均。

其他可能的排查点 #

1. 消费者配置一致性 #

确认故障消费者的group.id是不是和正常消费者完全一致（你的配置里是temp_topic_group1），别不小心写错了；另外检查bootstrap.servers是否能被故障服务器访问——如果Kafka的listeners配置只绑定了localhost，那其他服务器的消费者根本连不上Kafka集群，这时候看故障消费者的日志，会有大量连接超时的错误。

2. 分区分配策略的影响 #

你当前用的是RangeAssignor策略，这个策略会按主题分区的序号范围分配给消费者。如果是单个主题，当分区数小于消费者数时，就会出现部分消费者无分区可分的情况；如果是多主题，可能会出现分配不均，但你的场景更偏向单主题的分区数问题。

如果分区数足够（比如>=5）但还是分配不均，可以尝试换成RoundRobinAssignor策略，修改消费者配置：

partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RoundRobinAssignor]

重启消费者后，会按轮询的方式均匀分配分区。

总结 #

先去查主题的分区数，这是最常见的原因；如果分区数没问题，再看消费者组的分配状态和配置一致性。一般按照这个流程下来，问题都能解决。

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