Kafka 为什么会消息堆积?

server/2025/3/3 7:54:52/

Kafka 定期清理 Partition,但消息堆积(backlog) 依然可能发生,主要是因为 Kafka 的清理机制和消息消费进度是两回事。我们可以用一个 快递仓库 的类比来解释。


类比:Kafka 就像一个快递仓库

  • 生产者(Producer) = 快递员,不断往仓库里送包裹(消息)。
  • 消费者(Consumer) = 快递员从仓库取件,派送给客户。
  • Kafka 的清理机制 = 仓库的定期清理,把 太久没人取走的包裹 扔掉,以免仓库爆满。

消息堆积的核心原因:清理 ≠ 消费

Kafka 定期清理 Partition 主要是为了 删除“太旧的消息”,而不是为了 确保消费者能及时消费消息。如果生产的速度 > 消费的速度,消息就会在 Kafka 里堆积,导致以下几种情况:

1. 消费者太慢(消费跟不上生产)

  • 生产速度快递员(Producer)送货快
  • 消费速度快递员(Consumer)取件慢,导致仓库越来越满。
  • 结果:未被清理的消息越来越多,Partition 里的消息堆积。

示例:

  • 某个 Consumer 处理一条消息需要 5 秒,但 Producer 每秒生产 10 条消息,结果消息越积越多。

解决方案:

  • 提高消费能力:增加 Consumer 数量,采用 Consumer Group 并行消费。
  • 优化消费逻辑:减少不必要的处理延迟(如数据库写入、网络请求等)。
  • 启用批量消费:减少每条消息的处理开销,提高吞吐量。

2. 清理策略不适用于当前负载

Kafka 主要有两种日志清理策略:

  • 基于时间(log.retention.hours):比如“只保留最近 7 天的数据”。
  • 基于大小(log.retention.bytes):比如“每个 Partition 最多 1GB”。

问题是:

  • 如果清理时间长(比如 7 天),那 7 天内的所有未消费消息都可能堆积。
  • 如果清理大小设得很大,Kafka 仍然会存下大量未消费的消息。

示例:

  • 某个 Topic 设定 “7 天后才清理消息”,但 Consumer 3 天内都没消费,这 3 天的消息就会积压。

解决方案:

  • 调整 log.retention.* 设置,减少 Kafka 存储压力。
  • 使用 log.cleanup.policy=delete(而不是 compact),确保老消息能被删除。

3. Consumer 发生故障或重平衡

  • 如果 Consumer 挂掉了,或者在重启过程中,Kafka 不会自动删除它未消费的消息,这些消息会一直在 Kafka 里等着它恢复。
  • Consumer Group 发生 Rebalance(比如有新 Consumer 加入或离开),可能会导致短时间内 Consumer 不能消费数据,造成短暂的消息堆积。

示例:

  • 某个 Consumer Group 只有一个消费者,突然宕机了,Kafka 还会保留消息等它回来,这期间新消息就会堆积。

解决方案:

  • 使用多台机器分摊消费,避免单点故障导致积压。
  • 监控 Consumer 状态,防止意外掉线(如健康检查)。
  • 合理配置 session.timeout.msheartbeat.interval.ms,避免 Rebalance 过于频繁。

4. Producer 生产太快,Kafka 写入瓶颈

  • Kafka 依赖磁盘写入和网络传输,如果磁盘 I/O、网络带宽、Partition 数量等瓶颈达到上限,即使消费者再快,Kafka 也会积压消息。
  • 分区不均衡:如果某些 Partition 的 Leader 节点压力过大,而其他节点压力较小,可能会导致消息在特定 Partition 上堆积。

示例:

  • 一个 Kafka Broker 只有 1GB/s 的磁盘吞吐量,但 Producer 的数据写入速率高达 1.5GB/s,导致 Kafka 本身就写不动,积压在磁盘队列里。

解决方案:

  • 扩展 Kafka 集群:增加 Partition 和 Broker,提高并行吞吐量。
  • 优化 Kafka 磁盘性能:使用 SSD、优化磁盘 I/O、增加 Page Cache。
  • 控制生产速率:使用 Kafka 的流控策略(如 acks=allbatch.size)。

5. 消息 TTL 过长,导致 “僵尸” 消息

  • 如果 Kafka 允许消息存储很久(比如 log.retention.hours=168 表示 7 天),但 Consumer 长时间没消费某些 Partition,这些 Partition 里的消息就会堆积。
  • Kafka 不会主动丢弃未过期的消息,即使它们从未被消费

示例:

  • 某个 Consumer Group 绑定了 auto.offset.reset=earliest,但 3 天内都没消费,Kafka 依然保留这些消息,导致堆积。

解决方案:

  • 减少消息保留时间,避免不必要的堆积。
  • 优化 Offset 提交策略,确保 Consumer 及时提交 Offset,避免重新消费已处理的消息。

总结

原因解释解决方案
消费者太慢生产 > 消费,导致消息积压增加 Consumer 数量、优化消费逻辑
清理策略不适用清理的是“旧消息”,而不是积压消息适当调整 log.retention.* 配置
Consumer 故障或重平衡Consumer 崩溃或 Rebalance,导致无法消费增加 Consumer 副本,优化 Rebalance 逻辑
Kafka 磁盘或网络瓶颈Kafka 本身处理不过来,消息写入太快增加 Partition/Broker,提高硬件性能
消息 TTL 过长未消费但未过期的消息长期堆积降低 log.retention.hours,优化 Offset 提交

总结一句话

Kafka 的 清理机制只是“定期倒掉老水”,但如果 生产的水流太快、消费的水泵太慢,或者仓库太小,消息还是会堆积。所以 Kafka 需要合理优化生产、消费、存储策略,才能避免消息积压

这样解释的话,Kafka 为什么会消息堆积,是不是更清楚了?


http://www.ppmy.cn/server/172010.html

相关文章

5分钟看懂Deepseek开源周之六:Deepseek-V3/R1推理系统设计----揭开深度求索模型系统设计和运营成本之谜

前言 众所周知,四大天王一般有五个人。所以开源周五连发有第六天也很正常。贴上了开源周活动的github主贴,大家可以不上推特就能了解详情。 deepseek-ai/open-infra-index: Production-tested AI infrastructure tools for efficient AGI development a…

docker利用docker-compose-gpu.yml启动RAGFLOW,文档解析出错【亲测已解决】

0.问题说明 想要让RAGFLOW利用GPU资源跑起来,可以选择docker-compose-gpu.yml启动。(但是官网启动案例是86平台的不是NVIDIA GPU的,docker-compose-gpu.yml又是第三方维护,所以稍有问题) 1.问题 docker利用docker-c…

JUC模块

JUC(Java Util Concurrent) 是 Java 标准库中用于支持并发编程的模块,提供了丰富的工具类和框架,帮助开发者编写高效、线程安全的并发程序。JUC 模块自 Java 5 引入,是 Java 并发编程的核心部分。 1. JUC 的核心组件 …

常见报错及解决方案

精心整理了最新的面试资料和简历模板,有需要的可以自行获取 点击前往百度网盘获取 点击前往夸克网盘获取 1、启动Tomcat出现 报错 Could not open ServletContext resource [/database.properties] 解决 在locaition对应的路径前要加上classpath:,这样spring才能找…

【vue-echarts】——05.柱状图

文章目录 一、柱状图基本设置1.实现代码2.结果展示二、柱状图效果实现11.代码实现2.结果展示三、柱状图效果实现21.代码实现2.结果展示一、柱状图基本设置 柱状图:一种图表类型,因为构成是由一根一根类似柱子的数据条组合而成的坐标平面,所以命名为柱状 图。主要是用来反应对…

考研408数据结构线性表核心知识点与易错点详解(附真题示例与避坑指南)

一、线性表基础概念 1.1 定义与分类 定义:线性表是由n(n≥0)个相同类型数据元素构成的有限序列,元素间呈线性关系。 分类: 顺序表:元素按逻辑顺序存储在一段连续的物理空间中(数组实现&…

聊一聊 IM 如何优化数据库

IM 系列 im doc 实时通讯文档仓库 聊一聊 IM 是什么? IM 即时通讯系统概览 聊一聊 IM 要如何设计? 聊一聊 IM 要如何设计功能模块? 聊一聊 IM 要如何进行架构设计? 聊一聊 IM 要如何进行技术选型? 聊一聊 IM 要…

线程 -- 线程池

线程池 谈起线程池之前,我们可以联想到常量池,那什么是常量池呢? 常量池:字符串常量,在 Java 程序最初构建的时候,就已经准备好了。等程序运行的时候,这样的常量也就加载到内存中了。因此剩下…