Kafka Consumer 越多，消费吞吐一定越高吗？
面试怎么回答
不一定。同一 Consumer Group 内，一个 Partition 同时只分配给一个 Consumer，所以活跃并行度首先受 Partition 数限制，超过后新增实例会空闲。我还会检查 Partition Lag 是否均匀、单条处理和下游写入是否成为瓶颈，以及扩容引起的 Rebalance 成本。只有分区有余量且处理链路可横向扩展时，增加 Consumer 才能有效提高吞吐。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多人看到消费积压，第一反应就是：
“多加几个 Consumer。”
扩容有时有效，但同一个 Consumer Group 内，一个 Partition 同一时刻只会分配给一个 Consumer。Consumer 数量超过 Partition 数后，多出来的实例只能空闲。
消费并行度先受 Partition 数限制，最终吞吐还受单条处理、下游写入和 Rebalance 成本限制。
第一层上限：Partition 数量
假设 Topic 有 6 个 Partition：
- 3 个 Consumer：每个大约负责 2 个 Partition
- 6 个 Consumer：每个大约负责 1 个 Partition
- 8 个 Consumer：最多 6 个工作，至少 2 个空闲
所以在同一个 Group 内，活跃消费并行度不会超过订阅 Topic 可分配的 Partition 总数。
第二层上限：单个 Consumer 的处理能力
即使 Consumer 数量还没达到 Partition 数，也要看耗时花在哪里：
- 拉取消息是否慢
- 反序列化和业务计算是否重
- 是否逐条请求外部接口
- 是否单条写数据库
- 批处理大小是否合理
如果瓶颈在外部接口或数据库，单纯增加 Consumer 可能把压力转移到下游，甚至让整体失败率更高。
第三层上限：热点 Partition
总 Partition 数足够，不代表负载均匀。
如果消息 Key 分布不均，一个热点 Partition 可能承担大部分流量。它仍只能由一个 Consumer 消费，其他 Consumer 即使空闲，也无法分担这个 Partition 内的顺序工作。
这时要检查 Key 设计、分区策略和业务顺序要求，而不是继续堆 Consumer。
第四层成本：扩容会触发 Rebalance
Consumer 加入或退出 Group 会导致分区重新分配。频繁弹性扩缩容可能带来暂停、状态恢复和重复处理成本。
因此扩容前应该先确认：
- 当前 Consumer 数是否小于 Partition 数；
- 每个 Partition 的 Lag 是否均匀；
- 单条处理和下游写入是否已优化；
- Group 是否正在频繁 Rebalance。
一个典型场景
比如 Topic 只有 6 个 Partition，消费组已经有 6 个 Consumer。出现积压后又扩到 12 个实例。
结果仍然只有 6 个实例拿到 Partition，其余实例空闲；同时扩容触发 Rebalance，短时间内消费反而暂停。
进一步排查发现，其中一个 Partition 因热点 Key 承担了大部分 Lag。真正需要解决的是分区热点和下游处理，而不是继续加 Consumer。
扩容前先确认并行度天花板在哪里。