开头之前有同学在技术群里问了一个比较经典的问题线上 Kafka 消费者出现消息堆积他们第一时间想到的是“多开几个消费者”结果分组里消费者数量加了之后堆积不仅没有明显缓解反而频繁看到rebalance日志部分分区甚至一段时间内没有消费者在拉取。这种情况在很多团队都出现过。Kafka 消息堆积确实是最常见的线上问题之一但它的根因往往不只是“消费速度不够快”。如果没弄清楚堆积发生在哪个环节盲目加消费者不仅浪费资源还会引入新的问题。本文将围绕 Kafka 消息堆积从“堆积是怎么产生的”“为什么加消费者不一定有效”出发完整梳理诊断思路、消费端参数调优、分区治理和工程最佳实践适合已经写过 Kafka 生产者消费者代码、想深入理解性能问题的后端开发者。1. 先理解消息堆积的本质1.1 消息堆积到底是什么Kafka 是一个基于发布订阅模型的分布式消息中间件核心组件包括生产者Producer、主题Topic、分区Partition、消费者Consumer和消费者组Consumer Group。一条消息从生产到被消费完大致经过以下流程生产者将消息写入 Topic 的某个分区。Broker 将消息持久化到磁盘并维护分区内的 offset偏移量。消费者从分区中拉取消息处理完成后提交 offset。如果消费者处理速度跟不上生产速度未提交 offset 的这部分消息就会在 Kafka 中累积形成“消费滞后”。在 Kafka 中有一个指标专门衡量这个滞后程度叫Consumer Lag计算公式为Lag 分区当前最新 offset - 消费者已提交 offset如果每个分区的 Lag 持续增长说明消费端处理不过来这就是大家常说的消息堆积。1.2 消息堆积的生产者消费者模型视角Kafka 本质上实现的是经典的生产者消费者模型。生产者和消费者之间通过 Broker 解耦生产者不关心消费者什么时候处理完消费者也不关心生产者什么时候发送。这个模型有一个隐含前提消费者处理消息的速率必须大于等于生产者生产消息的速率。否则消息会在中间件中堆积。在实际系统中堆积出现的原因可以分为三类生产端瞬时写入流量过高超过消费端常态处理能力。比如大促、定时任务集中触发、数据同步高峰。消费端处理能力下降。比如消费逻辑中调用的下游接口变慢、数据库连接池打满、线程阻塞、GC 停顿。消费端配置不合理。比如单次拉取消息数量过大、提交 offset 方式不正确、消费线程模型设计有问题。很多人在排查时只盯着第二类而且解决方法也很单一加消费者。但实际上前两类原因同样常见而且加消费者未必能解决。2. 为什么“加消费者”不一定能解决堆积2.1 消费者数量和分区数的关系Kafka 消费端的并行度由分区数决定。一个分区在同一个消费者组内只能被一个消费者实例消费换句话说同一个分区不会被同一个消费组中的多个消费者同时消费。假设一个 Topic 有 6 个分区当前消费者组有 2 个消费者那么每个消费者可以分配到 3 个分区。如果你把消费者数量增加到 6 个每个消费者负责 1 个分区消费并行度确实提升了。但如果继续增加到 10 个就会出现 4 个消费者分配不到任何分区处于空闲状态。所以加消费者是否有效首先取决于分区数。对于一个只有 3 个分区的 Topic你把消费者加到 20 个真正消费消息的还是 3 个消费者其他 17 个全在空转。这里建议先执行一条命令确认分区和消费者的分配情况。Kafka 自带的命令行工具可以查看消费者组详情kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-group输出类似GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID order-group order-topic 0 1000 1500 500 consumer-1-xxx /192.168.1.10 consumer-1 order-group order-topic 1 1000 1500 500 consumer-1-xxx /192.168.1.10 consumer-1 order-group order-topic 2 800 1500 700 consumer-2-xxx /192.168.1.11 consumer-2从输出可以看出这个 Topic 只有 3 个分区即使消费者组中有更多消费者实例分区也只能分配给其中 3 个。2.2 单分区消息有序带来的约束Kafka 保证单个分区内的消息是有序的但 Kafka 并不保证 Topic 级别的消息有序。因此如果你的业务严格要求同一订单、同一用户的消息按顺序处理通常在生产者端会按照业务 ID 作为 key让相同 key 的消息进入同一个分区。这种情况下如果你盲目增加消费者并不会提高单个分区的消费速度。因为同一个分区只会被组里的某一个消费者消费新增消费者并不能把单个分区的消费任务拆成多份。所以当堆积集中出现在少数几个分区时加消费者的意义非常有限。真正的问题可能是 key 设置不合理导致大量消息集中在某个分区形成“热分区”。2.3 频繁 Rebalance 会放大堆积问题每次向消费者组中添加或移除消费者实例时Kafka 都会触发 Rebalance也就是重新分配分区。在 Rebalance 期间所有消费者会暂停消费等到分区分配完成后再继续。如果堆积严重时频繁增加消费者会导致多次 Rebalance。每一次 Rebalance 都是一段“空窗期”消息还在持续生产但消费端已经暂停堆积只会更严重。而且如果一个消费者处理消息时间过长超过了max.poll.interval.ms默认 300000也就是 5 分钟Kafka 会认为该消费者已经“失联”主动将其踢出消费者组再次触发 Rebalance。这也是堆积场景下很常见的“越积越多、消费者不断进出组”的恶性循环。2.4 消费者组扩容的正确姿势加消费者不是完全不行而是需要满足两个前提Topic 分区数充足还有可以分配给新增消费者的空闲分区。消息分区相对均匀不存在严重的热分区。在这两个前提下增加消费者才能提升并行消费能力。否则更值得做的事情是先通过监控确定堆积的根因再选择扩容分区、优化消费逻辑、调整 poll 参数等方案。3. 环境准备与版本说明本文的排查思路和示例基于 Kafka 2.x 到 3.x 的常用版本使用 Kafka 自带的命令行工具和 Spring Boot 集成 Kafka 的典型配置。Kafka 在不同大版本之间的命令参数略有差异比如部分版本使用--bootstrap-server替代了--zookeeper你需要在执行前先确认当前环境版本。建议环境如下Kafka 服务端2.13-3.4.0 或更高版本通过 Docker 或本地集群部署均可。JDK1.8 及以上。构建工具Maven 3.6。客户端依赖spring-kafka2.9.x 或适配你 Spring Boot 版本的依赖。命令行工具Kafka 安装目录下的bin目录。可视化工具可选Offset Explorer用于连接本地 Kafka 查看 Topic 分区、消费者组和 Lag 信息。如果你的项目不是 Spring Boot而是纯 Java 客户端核心结论同样适用因为底层都是 Kafka Consumer 的 poll 模型。4. 消息堆积的标准诊断步骤4.1 查看消费组 Lag 概况诊断堆积第一步不是改代码而是搞清楚“哪些分区堆积了”“每个分区堆积了多少”。使用命令行工具查看kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-group执行结果会列出每个分区的CURRENT-OFFSET、LOG-END-OFFSET和LAG。如果所有分区的 LAG 都在持续增长说明是整体消费能力不足。如果只有个别分区的 LAG 很高其他分区正常那么大概率是数据倾斜或热分区问题。4.2 按照时间线观察 Lag 变化单次查看 Lag 只能说明当前时刻的状态不足以定位问题。更推荐每隔 1 到 5 分钟记录一次 Lag 值观察趋势Lag 持续快速上涨消费能力远低于生产速率。Lag 在某个时间点突然上涨可能对应上游批量任务、数据补偿或大促流量。Lag 缓步上涨消费能力和生产能力差距不大但长期无法追平。Lag 有涨有跌消费能力基本够用只是偶尔出现尖峰。这一步如果能配合 Kafka 监控面板如 Kafka Lag 监控、Prometheus Grafana 等排查效率会高很多。如果公司暂时没有监控体系可以写一个简单的定时任务把 Lag 信息输出到日志中再导入 Excel 看趋势也能定位问题。4.3 查看消费者分配情况继续使用--describe输出中的CONSUMER-ID字段统计每个消费者分配的分区数确认是否存在分配不均的情况。正常情况下6 个分区分配给 2 个消费者每个消费者分到 3 个分区是比较均衡的但如果消费者组刚发生过 Rebalance或者使用了 RangeAssignor 且 Topic 分区数较少有可能出现一个消费者分到 5 个分区、另一个只分到 1 个分区的情况。4.4 诊断消费耗时这是最容易忽略的一步。很多时候 Lag 上涨不是因为 Kafka 拉取慢而是因为消费者拿到消息后在业务逻辑中停留太久。可以在消息处理方法入口和出口分别记录时间用日志打印单条消息处理耗时或者用 Micrometer 等指标工具统计 P99 耗时。示例代码如下// 文件路径src/main/java/com/example/kafka/consumer/OrderConsumer.java Component public class OrderConsumer { private static final Logger log LoggerFactory.getLogger(OrderConsumer.class); KafkaListener(topics order-topic, groupId order-group) public void onMessage(ConsumerRecordString, String record) { long start System.currentTimeMillis(); try { // 模拟业务处理写数据库、调用下游接口等 process(record.value()); } finally { long cost System.currentTimeMillis() - start; if (cost 1000) { log.warn(message process too slow, partition{}, offset{}, cost{}ms, record.partition(), record.offset(), cost); } } } }如果日志中频繁出现超过 1 秒的处理耗时说明业务逻辑是堆积的主要原因。这时候加消费者往往只能缓解整体吞吐但单分区的头部阻塞问题依然存在。5. 根因分类与实战调优5.1 消费逻辑阻塞导致堆积消费端处理一条消息时如果涉及以下操作很容易成为瓶颈同步调用下游 HTTP 接口或 RPC 接口且接口响应慢。批量写数据库但 SQL 执行效率低或连接池不足。对 Redis 做大量读写网络往返耗时高。本地锁或分布式锁竞争线程等待时间长。在消费线程中处理复杂计算或大文件。这种情况下需要先优化单条消息的处理速度而不是先加消费者。优化的方向有三种异步化、批量化和超时控制。异步化示例将同步的远程调用改为异步提交 回调或者先写入本地队列由独立线程池去执行下游调用。// 文件路径src/main/java/com/example/kafka/consumer/AsyncOrderConsumer.java Component public class AsyncOrderConsumer { private static final Logger log LoggerFactory.getLogger(AsyncOrderConsumer.class); private final ExecutorService notifyPool new ThreadPoolExecutor( 8, 16, 60, TimeUnit.SECONDS, new ArrayBlockingQueue(10000), new ThreadPoolExecutor.CallerRunsPolicy() ); KafkaListener(topics order-topic, groupId order-group) public void onMessage(ConsumerRecordString, String record) { // 消费线程只负责把任务提交到线程池快速返回避免 poll 超时 notifyPool.submit(() - { try { notifyUser(record.value()); } catch (Exception e) { log.error(notify user failed, offset{}, record.offset(), e); } }); } }需要注意异步化会引入两个新问题一是消息可能丢失因为消费线程已经提交了 offset但异步任务还没执行完二是消息可能乱序因为同一个分区的消息可能被不同线程并发执行。所以异步化只适用于对顺序不敏感、允许短暂延迟、且能接受少量重复消费的场景。对于必须严格保证顺序的业务可以采用“分区内单线程 业务侧批量聚合”的方案而不是简单异步化。如果异步化后仍然堆积再考虑提升线程池大小或改用独立的消息处理中间件如将任务转发到其他队列逐步消费。5.2 分区分配不均与热分区热分区在日志上的表现是同一个消费者组中只有一个或少数几个分区的 Lag 很高其余分区 Lag 接近 0。产生热分区的原因通常有几种生产者发送消息时使用了业务 ID 作为 key但某个业务 ID 对应的消息量特别大。生产者没有指定 key但分区器默认使用轮询策略如果消息量本身不大可能出现短暂的不均匀。消息字段中某个枚举值数量极多业务处理时会按该字段走同一套慢逻辑。排查方式查看--describe输出的分区 LAG 分布再结合消费者日志确认高 Lag 分区的消息内容。解决思路修改生产者端的 key 策略让消息更均匀地分布到各个分区。比如在业务 ID 基础上拼接一个随机后缀但要注意这会破坏相同 key 消息的顺序性。增加 Topic 分区数让单分区承担的压力变小。单独处理热点业务类型例如将热点消息路由到独立的 Topic配置更高的消费者优先级。修改分区数命令kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic order-topic --partitions 12执行前需要确认增加分区数不会与现有消费者的分配逻辑冲突并且下游逻辑不依赖分区数量固定。5.3 poll 参数配置不合理Kafka Consumer 使用拉取模式消费者不断调用poll()拉取消息。poll()的行为由几个关键参数控制fetch.min.bytes每次拉取的最小字节数如果数据量不够消费者会等待。fetch.max.wait.ms在fetch.min.bytes未满足时最多等待多久。max.poll.records单次poll()返回的最大消息条数。max.poll.interval.ms消费者处理消息的最大间隔时间超过后会被认为失联。session.timeout.ms消费者与 Broker 之间的会话超时时间。有些团队为了提高吞吐把max.poll.records调得很大比如一次拉取 5000 条。但消费端每条消息都要写数据库处理 5000 条需要很长时间如果超过max.poll.interval.ms消费者会被踢出组触发 Rebalance反而降低整体消费速度。合理的配置思路是max.poll.records不要设置得过大建议先按单条消息处理耗时来估算。如果单条消息平均 50ms那么一次 poll 300 条处理时间大概是 15 秒在默认 5 分钟的max.poll.interval.ms范围内是安全的。Spring Boot 中配置示例spring.kafka.consumer.bootstrap-serverslocalhost:9092 spring.kafka.consumer.group-idorder-group spring.kafka.consumer.auto-offset-resetearliest spring.kafka.consumer.enable-auto-commitfalse spring.kafka.consumer.max-poll-records300 spring.kafka.consumer.properties.fetch.min.bytes1024 spring.kafka.consumer.properties.fetch.max.wait.ms500 spring.kafka.consumer.properties.max.poll.interval.ms300000同时建议手动提交 offset并在确保消息处理成功后再提交。使用 Spring Kafka 时可以配置AckMode.MANUAL_IMMEDIATE// 文件路径src/main/java/com/example/kafka/config/KafkaConsumerConfig.java Configuration public class KafkaConsumerConfig { Bean public ConcurrentKafkaListenerContainerFactoryString, String kafkaListenerContainerFactory( ConsumerFactoryString, String consumerFactory) { ConcurrentKafkaListenerContainerFactoryString, String factory new ConcurrentKafkaListenerContainerFactory(); factory.setConsumerFactory(consumerFactory); factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.MANUAL_IMMEDIATE); return factory; } }对应的消费代码在手动确认消息处理成功后调用 ack// 文件路径src/main/java/com/example/kafka/consumer/AckOrderConsumer.java Component public class AckOrderConsumer { KafkaListener(topics order-topic, groupId order-group) public void onMessage(ConsumerRecordString, String record, Acknowledgment ack) { try { process(record.value()); ack.acknowledge(); } catch (Exception e) { // 记录失败消息后续补偿处理 log.error(process message failed, offset{}, record.offset(), e); } } }手动提交 offset 可以避免“消息还没处理完就提交 offset导致消息丢失”的问题但也需要注意如果某条消息始终处理失败且没有 ack会造成该分区 Lag 一直无法下降。这种情况下应该引入死信队列或重试机制而不是无限重试。5.4 消费者数量和线程模型不合理当你确认 Topic 分区数足够多、分区分布也均匀但消费并发度仍然不足时就需要检查消费者线程模型的配置。Spring Kafka 中ConcurrentKafkaListenerContainerFactory的并发度由setConcurrency()控制。一个常见的误区是默认并发度为 1即使消费者组中有多个实例如果concurrency没有设置每个实例可能只启动一个消费线程。配置示例factory.setConcurrency(6);如果 Topic 有 12 个分区这个配置会让每个监听容器启动 6 个消费线程Broker 会把 12 个分区尽量平均分配给这 6 个线程。需要注意的是concurrency的值不能无限调大。单机线程数超过分区数时多余线程空闲线程数过大还会带来上下文切换开销和数据库连接压力。一个更稳妥的模型是单个消费线程负责快速拉取和分发消息多个工作线程负责执行业务逻辑消费线程与工作线程之间通过队列解耦。这种模型能有效提高吞吐但带来的问题是消息处理顺序和 offset 提交时机更难控制需要根据业务场景权衡。5.5 生产端峰值和 Broker 瓶颈有时候消费端已经很快但堆积依然出现原因是生产端瞬时流量远超消费端常态处理能力。这种情况常见的特征是Lag 上涨发生在每天的固定时间段且持续一段时间后自行下降。比如定时任务在凌晨集中补推数据或者运营在某个时间点群发消息。针对这种场景通常不需要永久扩容消费端而是优先做到以下几点给消费端预留足够的缓冲能力在高峰期能快速追上。生产端做削峰填谷比如将批量消息分批发送控制发送速率。保证 Broker 的磁盘、网络和分区副本状态正常避免 Broker 侧本身成为瓶颈。如果堆积出现在大促或活动流量高峰可以考虑临时增加分区数或消费者数量但活动结束后要评估是否回滚配置否则会造成资源浪费。另外如果生产者在发送消息时报错比如cluster authorization failed或error while fetching metadata则说明客户端连接、权限或 Broker 状态存在问题这类问题不会直接影响堆积但会导致消息发送失败和重试间接影响生产速率也需要一并排查。6. 最佳实践与工程建议6.1 使用监控和告警代替人工排查消息堆积不是一个能靠“打开命令行看一眼”就长期解决的问题。建议在项目中接入 Kafka Lag 监控并设置分级告警Lag 持续 5 分钟超过阈值发送警告级告警。Lag 持续 30 分钟超过阈值发送紧急告警。消费者组成员数量变化超过预期时发送告警。在实施层面如果公司已有 Prometheus Grafana可以集成 Kafka Exporter 采集消费者组 Lag。如果没有现成体系也可以用一个定时任务执行kafka-consumer-groups.sh --describe并将结果上报到日志平台或自研监控系统花费不大但收益明显。6.2 消费端设计建议消费端的代码设计对堆积问题的影响非常大建议从以下角度把握单条消息处理要做超时控制避免下游接口死等导致消费线程阻塞。优先使用批量消费减少网络和数据库交互次数。根据业务允许的延迟合理设置max.poll.records和fetch.max.wait.ms。对重复消息做幂等处理便于在堆积场景下临时增加消费者也不会因为重复消费产生脏数据。尽量不把耗时的任务放在KafkaListener方法内同步执行除非业务对顺序有严格要求。6.3 分区规划建议Topic 分区数的规划要结合业务增长来评估。分区过少会导致消费并发度上不去分区过多会带来文件句柄和副本同步的开销。实际项目中可以参考以下思路每个分区的吞吐量按 1 到 5 MB/s 估算。根据高峰期消息总量和单分区吞吐能力预留 30% 到 50% 的余量。分区数尽量设置为 3 的倍数便于在多 Broker 集群中尽量均匀分布。如果 Topic 创建初期分区数设置不合理后续可以通过kafka-topics.sh --alter调整但这是一个在线操作需要考虑对消费端的影响建议在低峰期执行。6.4 生产变更的最小权限与验证原则如果需要在生产环境调整 Kafka 参数、增加分区或修改消费者配置请遵循最小权限和先验证后变更的原则先在测试环境复现堆积场景验证参数调整的效果。生产环境变更前备份当前配置记录变更时间点。变更后观察 Lag 趋势至少 30 分钟确认问题是否缓解。不要直接在生产环境执行大批量分区扩容或消费者重启操作特别是在 Rebalance 可能被触发的场景下。7. 常见问题与排查清单以下是在使用 Kafka 过程中容易出现的问题汇总可以直接作为排查参考。问题现象常见原因解决思路所有分区 Lag 都在上涨消费能力整体不足或生产流量过高先查看消费耗时再决定增加消费者或优化业务逻辑只有个别分区 Lag 很高热分区、key 分布不均调整 key 策略、增加分区数、单独处理热点消息增加消费者后堆积没有缓解消费者数量已超过分区数增加分区数或者优化单消费者处理效率消费者频繁触发 Rebalance单条消息处理时间超过 max.poll.interval.ms减小 max.poll.records异步化处理检查消费者健康状态消费端重启后重复消费手动提交 offset 失败或提交时机不对确认消息处理成功后再 ack配合幂等设计Spring Boot 应用启动后消费不到消息消费组与 Topic 不匹配或不存在的 offset reset 设置检查 group-id、auto-offset-reset配置确认分区分配情况生产者发送消息报 metadata 错误客户端无法连接 Broker 或 Topic 不存在检查 bootstrap.servers、Topic 元数据、acl 权限使用 Docker 搭建 Kafka 后客户端连接失败容器内外网络隔离broker 注册了容器内地址配置 advertised.host 或 advertised.listeners 为宿主机可达地址再给一个沉淀下来的排查清单遇到消息堆积时按顺序走确认当前消费者组 Lag 数据和分区分布。观察 Lag 是整体上涨还是局部上涨。查看消费单条消息耗时确认是否存在业务逻辑阻塞。检查消费者数量与分区数的关系。检查 max.poll.records、max.poll.interval.ms 配置是否合理。检查是否有 Rebalance 日志评估 Rebalance 频率。检查生产端写入速率是否在短时间内出现峰值。检查 Broker 磁盘、网络、CPU 是否存在瓶颈。根据根因选择优化业务逻辑、调整 poll 参数、增加分区、增加消费者或生产端限流。8. 总结与下一步学习建议排查 Kafka 消息堆积的关键不是一上来就加消费者而是先回答三个问题堆积在哪些分区所有分区还是部分分区消息从拉取到处理完成的耗时是多少瓶颈在拉取还是业务逻辑消费者数量和分区数的关系是否合理是否有频繁 RebalanceKafka 消息堆积是一个综合性问题它涉及生产端写入速率、消费端处理能力、Topic 分区设计、消费者参数配置以及 Broker 集群状态。只有把这几层结合起来分析才能快速定位根因。本文给出的诊断流程、参数配置和排查清单是我在实际项目中反复验证过的一套思路希望能给正在排查类似问题的你提供参考。下一步可以继续学习的内容包括Kafka 的消费者组 Rebalance 协议、Kafka 生产端批量发送和幂等机制、Spring Kafka 的容器线程模型以及基于 Kafdrop、Offset Explorer 等图形化工具进行日常运维。如果你正在用 Spring Boot 集成 Kafka建议抽时间对比一下默认配置与你业务场景的差异很多堆积隐患在早期就能避免。希望这篇笔记对你有帮助也欢迎在实际排查中验证这些思路是否适用于你的业务场景。