Kafka消息队列核心原理、参数调优与故障排查实践

凌晨两点半被电话叫起来，说订单系统里的状态和库存系统对不上，差了小两千条记录。爬起来一查，问题不在业务代码，而是两边靠定时任务扫数据库表同步，中间某个时段任务卡住，数据就断了一段。那次之后，团队把这条链路整体换成了 Kafka，问题不再复现，但新的问题也跟着来了：消费组莫名其妙重平衡、消息重复、磁盘三天写满。这篇内容就是这几年在几套集群上摸爬滚打攒下来的东西，从整体设计思路一路讲到参数怎么调、坑怎么排。

Kafka 这东西，本质上是一个分布式的、基于追加写日志的发布订阅系统。它最常被拿来当消息队列用，但实际上它的能力远不止于此：日志聚合、流式处理的数据源、事件溯源、CDC 数据的落地缓冲、系统间的解耦总线，都是它的主场。适合谁看？如果你正在纠结要不要引入消息中间件、正在被消费积压折磨、或者准备从零搭一套集群，那这里的内容基本能覆盖你 80% 的疑问。下面不按教科书的顺序讲，按我理解的“为什么这么设计”来拆。

1. 先把 Kafka 放回它该在的位置

1.1 从一个“数据对不上”的场景说起

前面提到的那个订单与库存不一致的问题，本质上是同步方式选错了。定时扫表这种做法的耦合度极高：上游表结构一变，下游就得跟着改；上游写库慢一点，下游就漏数据；两边还都得为对方的存在而承担额外的数据库压力。这类问题的通用解法是把“谁需要数据”这件事从上游剥离出去，上游只负责把“发生了什么”广播出来，谁关心谁自己去取。这就是发布订阅模型的价值。

但发布订阅的实现方式有很多种，为什么最后落到 Kafka 上？这里有个关键的判断标准：你的数据是“任务”还是“事实”。如果一条消息被消费完就该消失（比如发短信、发邮件的指令），那传统的队列型中间件更合适，因为它天然支持“消费即删除”和优先级。但如果一条消息代表的是“某件事已经发生了”这个不可变的事实，而且可能有多个下游、可能需要回溯、可能需要重放，那 Kafka 的日志模型就是更对路的选择。订单创建成功、库存扣减完成、支付回调到达，这些都是事实，都值得被多个系统反复读取。

我在选型时一般会问三个问题：数据需不需要被多个消费方独立消费？需不需要保留一段时间以便回溯重放？写入量是不是远超单机数据库的承受能力？三个里有两个答“是”，我就倾向于 Kafka。反过来，如果只是两个系统之间传个指令、QPS 只有几十、还要求严格的优先级和延迟队列，那硬上 Kafka 就是给自己找麻烦——它的延迟队列支持很弱，靠主题模拟出来的方案维护成本不低。

1.2 三个反直觉的设计决定了它的性格

Kafka 有几个设计和大多数人的第一直觉相反，理解了这几点，后面所有的参数调优都不用死记硬背。

第一，消息被消费之后不会删除。这可能是最多人误解的地方。消费者读消息只是移动了自己的位置指针（offset），消息本身还在磁盘上躺着。删除是另一套机制干的，按时间或者按大小来（默认保留七天）。这个设计带来两个直接后果：一是下游可以随时把位点重置回过去，重新消费一遍历史数据，这在修复下游 bug 时简直是救命稻草；二是容量规划不能按“消费完就释放”来算，必须按“写入速率 × 保留时长”来算，这也是很多人磁盘写满的根本原因。

第二，一个分区内的消息严格有序，跨分区不保证。这个限制看起来是缺陷，其实是性能的来源。要保证全局有序，就得把所有消息塞进一个队列串行处理，吞吐量立刻掉一个数量级。Kafka 的做法是把数据切成分区，分区内部用追加写保证顺序，分区之间并行。所以正确用法是：把需要保证顺序的维度（比如同一个订单号）作为分区键，让相关消息落到同一个分区里。这样一来，“局部有序”就够用了，全局有序的需求在业务上其实很少见。

第三，它把大量工作交给了操作系统。写消息是追加到文件末尾，读消息是顺序扫描，这两种操作在机械盘上都能跑到很高的吞吐，因为它们避免了随机寻道。更关键的是它大量依赖操作系统的页缓存：写入时先进页缓存，由内核决定什么时候刷盘；读取时如果数据还在页缓存里，根本不碰磁盘。这也是为什么 Kafka 的 JVM 堆内存不建议开太大——堆开大了，页缓存就小了，反而更慢。

1.3 该上就上，不该上别硬上

说几个我见过的不太合适的用法。第一种是把 Kafka 当数据库用，期望它能按某个业务字段做查询。它做不到，也不该做，它只认 offset。第二种是拿它做延迟任务调度，靠“等 N 分钟再消费”这种技巧，实现起来极其别扭。第三种是单机部署还只配一个副本，然后抱怨它不可靠——这跟 Kafka 没关系，是配置问题。

反过来说，有几个场景我觉得特别合适：跨系统的数据分发，一份数据多个下游各取所需，加一个下游不用改上游一行代码；削峰填谷，前端流量洪峰先写进 Kafka，后端按自己的能力匀速消费；变更数据捕获的落地层，数据库的增量变更先落 Kafka，再由各个下游按自己的节奏消费入库；流式计算的输入源，配合流处理框架做实时统计。这几个场景的共同点是：数据是事实、有多个消费者、需要缓冲或回溯。

2. 一条消息的完整旅程：核心概念逐层拆

2.1 Topic、Partition、Offset 三件套

Topic 是逻辑上的分类，比如“订单事件”“用户行为”。但 Topic 只是个名字，真正干活的是 Partition。每个 Topic 被分成若干个分区，分区是并行度的基本单位，也是有序性的边界。分区数一旦定下来，只能增加不能减少——因为减少意味着要合并数据，而合并会破坏 offset 的连续性，下游的位点全得重来。所以分区数的规划要稍微留点余量，但也不能瞎开：分区多了，每个分区的文件句柄、内存开销、副本同步的压力都会上去，而且再平衡的耗时也会变长。

Offset 是消息在分区内的唯一编号，单调递增，从 0 开始。注意它只在分区内唯一，不是一个全局唯一的 ID。同一个 offset 在不同分区里指向的是完全不同的消息，这点在排查问题时很容易搞混。消费位点（consumer offset）记录的是“下一条要读的位置”，不是“最后读过的位置”，差一位，写代码的时候要注意。

分区键的选择直接决定了数据分布。不指定 key 的时候，生产者会轮询或者按批次粘性地分发，数据比较均匀；指定了 key，就用hash(key) % 分区数决定落点，同一个 key 一定落同一个分区，顺序有保证，但可能倾斜。我见过一个案例：某个业务用城市编码做 key，结果一线城市的流量占了七成，一个分区被打爆，其他分区空转。这种时候要么把 key 拆得更细（城市+业务线），要么接受乱序改用不带 key 的写入。

2.2 副本、ISR 与 Leader 选举

每个分区可以有多个副本，分布在不同的节点上。其中一个是 Leader，负责处理读写；其余是 Follower，只负责从 Leader 拉数据做同步。客户端只和 Leader 打交道，这一点很重要——它意味着副本机制对客户端是透明的。

ISR 是“同步副本集合”的缩写，指的是当前和 Leader 保持着“足够近”的同步状态的副本。这个“足够近”由replica.lag.time.max.ms控制，默认 30 秒：如果一个 Follower 超过这个时间没追上 Leader 的最新数据，就会被踢出 ISR。Leader 挂了之后，新 Leader 只能从 ISR 里选，这是为了保证不丢数据。如果 ISR 空了怎么办？那就得看unclean.leader.election.enable，这个参数默认是 false，意思是宁可这个分区不可用，也不让一个落后的副本当 Leader。把它打开能提高可用性，但会丢数据——这是个纯纯的取舍，金融类业务想都别想，日志类业务可以考虑。

这里必须把acks和min.insync.replicas放在一起讲，因为它们是一场“双人舞”。acks=all的意思是 Leader 要等到 ISR 里的所有副本都确认收到，才给生产者回成功。但“ISR 里所有副本”这个说法有个陷阱：如果 ISR 缩到只剩 Leader 一个，那 acks=all 也只等它自己，等于没保证。所以必须配上min.insync.replicas=2，意思是至少要有 2 个副本在 ISR 里，写入才被允许；ISR 不足 2 个的时候直接报错，让生产者自己决定重试还是降级。这套组合拳才是真正的“写入不丢”。

2.3 Controller 与元数据管理

集群里有一个特殊的角色叫 Controller，负责分区的 Leader 选举、副本分配、Topic 的创建删除这些管理工作。老版本的 Controller 依赖外部的协调服务来选主，新版本已经内置了一套基于共识算法的元数据管理机制，不再需要外部依赖，部署也简单了不少。不管是哪种模式，Controller 都是单点的逻辑角色，它挂了会重新选一个，切换期间管理类操作会短暂不可用，但数据读写不受影响——这是设计上的隔离。

元数据这块，很多人不知道消费者组的位点存在哪。答案是存在一个内部主题里，这个主题默认有 50 个分区，按消费组 ID 做哈希分布。这个主题如果膨胀得厉害，会影响消费者组的加入速度，所以定期检查它的体积是有必要的。另外，位点提交频率太高会拖慢消费，太低又会在崩溃时造成大量重复消费，后面讲位移提交的时候细说。

2.4 磁盘上的日志：段、索引与清理

一个分区在磁盘上不是一个文件，而是一个目录，里面有一堆段文件（segment）。每个段包含一个数据文件.log、一个偏移量索引.index、一个时间戳索引.timeindex。当前正在写的那个叫活跃段，大小到log.segment.bytes（默认 1GB）就滚动出一个新段。为什么分段？因为清理和查找都是以段为单位进行的，一个段整体删除比在单个大文件里挖洞简单得多。

索引是为了快速定位。消费者要从某个 offset 开始读，如果没有索引，就得从头扫。有了稀疏索引（默认每 4KB 数据记一条），可以先二分找到最接近的段，再在段内二分找到位置，最后顺序扫几条就到了。这个设计的精髓在于“稀疏”，索引文件很小，可以整个放进内存，查找的代价极低。

清理策略有两个：delete 和 compact。delete 就是按时间或大小删掉整个旧段，适合事件流。compact 是保留每个 key 的最新值，把旧的同 key 记录清掉，适合“状态快照”类的场景，比如把数据库的变更流压缩成一张表的最新状态。还有一种组合策略，先压实再删除，用在需要长期保留最新状态、同时也要控制总量的话题上。我踩过一个坑：给一个 key 基数极高的主题开了 compact，结果压实线程天天在后台跑，磁盘 IO 拉满，因为几乎每个 key 都是唯一的，压实根本没收益。compact 只对“key 有重复更新”的场景有意义。

2.5 零拷贝与页缓存：吞吐量的真正来源

Kafka 的高吞吐经常被归功于“零拷贝”，但只用零拷贝来解释是不完整的。完整链条是：顺序追加写 + 页缓存 + 批量发送 + 零拷贝读取。

写的时候，消息先写到操作系统的页缓存里，然后立刻返回。落盘是内核根据脏页策略异步做的，应用层不等。这就是为什么 Kafka 的写入延迟能压到毫秒级，而磁盘明明是很慢的设备。当然代价是机器断电时页缓存里还没刷盘的数据会丢，所以副本机制才是真正的可靠性保障，单机的刷盘策略只是补充。

读的时候，如果消费者追得上最新数据，数据大概率还在页缓存里，根本不碰磁盘。如果追不上要读历史，用的是零拷贝技术：数据从页缓存直接送到网卡，不经过用户态缓冲区，省掉了两次内存拷贝和两次上下文切换。这个优化在“一份数据被多个消费者读”的场景下收益巨大。

需要注意，零拷贝在开启某些特性时会失效，比如消息格式需要做转换的时候（老版本客户端和新版本服务端之间的格式兼容），或者开启了 TLS 加密的时候——数据必须先解密才能发出去。这也是为什么有时候你发现吞吐量比预期低，一查是客户端版本太老，一直在触发格式转换。

3. 生产者与消费者：每个参数背后都是一笔账

3.1 生产者可靠性三件套

生产者的可靠性就三个参数：acks、retries、enable.idempotence。

acks=0是发出去就不管，性能最高，丢了也不知道。acks=1是 Leader 写完就返回，如果 Leader 在返回之后、Follower 同步之前挂了，消息就丢了。acks=all（也可以写成 -1）是最稳的，配合前面说的min.insync.replicas使用。

retries控制重试次数。但重试会带来一个副作用：如果第一条消息发送超时但实际写成功了，重试又写了一遍，就重复了。而且如果同时有多个请求在途，重试还可能导致乱序。这就是幂等性的用武之地。

enable.idempotence=true打开之后，生产者为每条消息带一个序列号，Broker 侧根据序列号去重，保证单个分区内不重复、不乱序。打开这个开关后，acks会被强制设为 all，retries会被设成一个很大的值，这是一套打包的保障。需要注意的是，幂等只在单个生产者会话内有效，生产者重启后序列号重置，跨会话的精确一次要靠事务。

事务的用法是给生产者配一个transactional.id，先初始化，再开启事务，发完消息后提交。消费端要配isolation.level=read_committed，这样只能读到已提交事务的消息，未提交的和已中止的会被过滤掉。这套机制能做“读-处理-写”的原子性，比如从 A 主题读、处理完写到 B 主题，要么都成功要么都不算。但它有代价：事务会增加协调开销，吞吐会掉一截，而且要求消费端配合。我的建议是，除非业务真的需要跨主题的精确一次，否则用“至少一次 + 下游幂等”的简单方案，维护成本低得多。

3.2 吞吐与延迟的取舍

批量相关的参数有三个：batch.size（默认 16KB）、linger.ms（默认 0）、buffer.memory（默认 32MB）。

linger.ms=0意味着消息来了立刻发，延迟最低，但批量效果差。稍微调大一点，比如 5 到 20 毫秒，生产者会等这么久攒一批再发，吞吐能提升好几倍，代价是最坏情况多这点延迟。这个值怎么定？看业务能容忍的端到端延迟，如果预算是 100ms，那给生产者 10ms 完全合理。

batch.size是单批次的上限，不是目标值。批次攒满了立刻发，攒不满就等linger.ms到期。把这个值调大，单次网络请求的载荷更大，压缩率也更高。

buffer.memory是生产者本地缓冲的总量。如果生产速度超过发送速度，缓冲会被填满，此时max.block.ms（默认 60 秒）内生产者会阻塞，超时后抛异常。这个参数很关键：如果你的应用是同步调用发送，缓冲满了就意味着业务线程被卡住。我一般会把发送改成异步加回调，避免业务线程被网络问题拖死。

压缩是另一个提升吞吐的大杀器。compression.type可选 gzip、snappy、lz4、zstd。经验值是：lz4 或 zstd 是首选，压缩比和 CPU 开销平衡得好，zstd 的压缩比更高但 CPU 略贵。gzip 压缩比最高但最慢，适合带宽极度受限的场景。文本类数据（JSON）压缩比能到 5 到 10 倍，二进制数据效果差一些。压缩是在批次层面做的，所以批量越大，压缩收益越高。

3.3 消费者组、分区分配与再平衡

消费者组是 Kafka 实现“一条消息只被组内一个消费者处理”的机制。组内的消费者数量超过分区数时，多出来的消费者会闲着，这是设计使然，不是 bug。所以横向扩容消费者的上限就是分区数，分区数规划的时候要把未来的消费能力算进去。

分区分配策略有几种。Range 是按主题逐个分配，容易在分区数不能整除时出现倾斜；RoundRobin 是全局轮询，均衡性好一些；Sticky 是在均衡的基础上尽量保持原有分配，减少再平衡时的数据迁移；CooperativeSticky 是配合增量再平衡协议用的，能做到“只迁移需要迁移的分区”，而不是全量停摆。新版本默认的组合基本能用，但如果你的消费者数量多、分区多，强烈建议用增量协议，再平衡的停顿时间能从几十秒降到几百毫秒。

再平衡的触发条件有三个：组内成员数量变化、订阅的主题分区数变化、订阅关系变化。每次再平衡期间，所有消费者都会暂停消费（增量协议下只暂停受影响的分区），这就是“消费卡顿”的常见来源。减少再平衡的手段：给消费者配group.instance.id变成静态成员，这样短暂重启不会触发再平衡；把session.timeout.ms和heartbeat.interval.ms调合理，别让网络抖动误判为成员掉线；最重要的是控制单次 poll 的处理时间，别超过max.poll.interval.ms（默认 5 分钟），超了就会被踢出组。

3.4 位移提交与三种投递语义

位移提交有三种姿势。自动提交是enable.auto.commit=true，每隔auto.commit.interval.ms（默认 5 秒）在 poll 的时候顺手提交一次。省事，但你没法控制提交时机，可能“消息还没处理完就提交了”，进程一挂就丢；也可能“处理完了没来得及提交”，重启就重复。

同步提交是处理完业务逻辑后手动调commitSync()，语义最清晰，但会阻塞，吞吐受影响。异步提交是commitAsync()，不阻塞，但失败时不会自动重试（因为重试可能覆盖掉更新的位点）。实践中的常见做法是“异步提交为主 + 关闭前同步提交兜底 + 处理失败时重置位点”。

这三种组合就对应了三种投递语义：最多一次（先提交后处理，挂了就丢）、至少一次（先处理后提交，挂了就重复）、精确一次（事务或幂等 + 位点原子提交）。绝大多数业务用“至少一次 + 下游幂等”就够了。下游幂等的实现方式很多：用业务唯一 ID 建唯一索引、用 Redis 记录已处理的 ID、或者干脆让操作本身幂等（比如“设置为某状态”而不是“增加某数值”）。

4. 从单机到集群：一套可复现的落地过程

4.1 环境与部署方式的选择

本地验证用单机就行，但要记住单机只能验证功能，验证不了可靠性。生产环境至少三个节点，副本数配 3，这样任意一台挂了都不影响读写。部署方式有三种：直接跑二进制包、容器化部署、用托管服务。二进制包最灵活，调参方便，适合自己掌控；容器化适合已有编排平台的团队，但要注意存储卷的持久化和网络标识的稳定性；托管服务省心，但参数可调范围有限，排查问题时也拿不到底层指标。

新版本已经内置了元数据管理机制，不再需要额外的协调组件，部署时少一个进程，运维负担明显轻了。如果是从老版本迁移过来的，注意规划好迁移路径，别在生产高峰做这件事。配置文件里最关键的几项：

# 节点标识，集群内唯一 broker.id=1 # 监听地址，区分内外部访问时要注意 advertised.listeners listeners=PLAINTEXT://0.0.0.0:9092 advertised.listeners=PLAINTEXT://10.0.0.11:9092 # 数据目录，多块盘用逗号分隔，能显著提升吞吐 log.dirs=/data1/kafka-logs,/data2/kafka-logs # 默认分区数与副本数，建主题时没指定就用这两个 num.partitions=6 default.replication.factor=3 # 副本同步的容忍时间 replica.lag.time.max.ms=30000 # 禁止落后副本当 Leader，保证不丢数据 unclean.leader.election.enable=false # 网络与 IO 线程，按 CPU 核数调整 num.network.threads=6 num.io.threads=12 # 段大小与保留策略 log.segment.bytes=1073741824 log.retention.hours=168

注意：advertised.listeners是最容易配错的一项。客户端拿到的连接地址是这个值，如果配成了内网地址而客户端在外网，就会出现“连上了但一直超时”的诡异现象。

4.2 关键配置逐项说明

log.dirs配多块盘的时候，Kafka 会把不同的分区目录分散到不同的盘上，等于把写入压力摊开了。但要注意，同一个分区的所有数据一定在同一块盘上，所以分区数要足够多才能充分利用多盘。

JVM 堆内存是个经典误区。很多人习惯性给个 16G、32G，结果发现性能反而下降。原因是堆占得越多，留给页缓存的内存越少，而 Kafka 的性能极度依赖页缓存。经验值是堆开 6G 到 8G，剩下的物理内存全留给页缓存。GC 用 G1，把最大停顿时间目标设在 50 到 100 毫秒就行。

num.io.threads建议设成磁盘数量的倍数，num.network.threads设成 CPU 核数左右。这两个值调得过大反而会因为线程切换而变慢。

4.3 代码侧：生产与消费的最小闭环

先建主题，命令行最快：

# 创建主题，6 个分区，3 副本 kafka-topics.sh --bootstrap-server 10.0.0.11:9092 \ --create --topic order-events \ --partitions 6 --replication-factor 3 # 查看主题详情，重点看 ISR 是否完整 kafka-topics.sh --bootstrap-server 10.0.0.11:9092 \ --describe --topic order-events

生产者的核心配置和发送逻辑：

Properties props = new Properties(); props.put("bootstrap.servers", "10.0.0.11:9092,10.0.0.12:9092,10.0.0.13:9092"); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); // 可靠性：等所有同步副本确认 props.put("acks", "all"); // 幂等，防重复防乱序 props.put("enable.idempotence", "true"); // 压缩算法 props.put("compression.type", "lz4"); // 攒批等待时间，10ms，按业务延迟预算调整 props.put("linger.ms", "10"); // 单批次大小 64KB props.put("batch.size", 65536); // 本地缓冲 64MB props.put("buffer.memory", 67108864); KafkaProducer<String, String> producer = new KafkaProducer<>(props); // 用订单号做 key，保证同一订单的事件落到同一分区且有序 ProducerRecord<String, String> record = new ProducerRecord<>("order-events", orderId, payload); // 异步发送 + 回调，避免业务线程被网络阻塞 producer.send(record, (metadata, exception) -> { if (exception != null) { // 落到本地重试队列或告警，别静默吞掉 log.error("send failed, orderId={}", orderId, exception); } });

消费者的关键点在于“什么时候提交位点”和“单次拉多少条”：

Properties props = new Properties(); props.put("bootstrap.servers", "10.0.0.11:9092,10.0.0.12:9092,10.0.0.13:9092"); props.put("group.id", "order-sync-group"); props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); // 关闭自动提交，手动控制 props.put("enable.auto.commit", "false"); // 无位点时从头读，生产环境慎用 latest 之外的选项 props.put("auto.offset.reset", "earliest"); // 单次最多拉 200 条，控制单批处理时长 props.put("max.poll.records", "200"); // 单条消息最小字节数，配合下面的等待时间提升批量效率 props.put("fetch.min.bytes", "1048576"); props.put("fetch.max.wait.ms", "500"); // 处理超时上限，默认 5 分钟，业务慢就调大 props.put("max.poll.interval.ms", "600000"); KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList("order-events")); while (running) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500)); if (records.isEmpty()) continue; try { for (ConsumerRecord<String, String> r : records) { handle(r); // 业务处理，需要自己做幂等 } // 处理完再提交，保证至少一次 consumer.commitSync(); } catch (Exception e) { // 不提交，下一轮从上次位点重来；必要时 seek 回退 log.error("handle failed, will retry", e); } }

4.4 容量估算与监控指标

容量估算有个简单公式：日增数据量 × 保留天数 × 副本数 × 1.1（索引与元数据开销）/ 压缩比。举个例子，日均写入 500GB 原始数据，压缩比按 3 算，保留 7 天，3 副本，那就是 500 × 7 × 3 × 1.1 / 3 ≈ 3850GB，接近 4TB。这个数字再加上 20% 到 30% 的缓冲，就是你要准备的磁盘量。很多人算的时候忘了乘副本数或者忘了除压缩比，结果偏差好几倍。

分区数的估算反过来：目标写入吞吐 / 单分区吞吐。单分区的写入能力受磁盘、网络、副本同步影响，经验值在几 MB/s 到十几 MB/s 之间。如果你的峰值写入是 100MB/s，按单分区 10MB/s 算，至少 10 个分区，再留一倍余量就是 20 个。分区数不是越多越好，超过一定数量后，再平衡的耗时和元数据的开销会显著上升。

监控上，我只盯几个核心指标：未同步副本数（大于 1 就要查，说明有副本掉队了）、分区 Leader 分布是否均衡（不均匀说明有节点负载过高）、消费延迟（每个消费组的 lag，持续上涨就是消费能力不足）、磁盘使用率（80% 就该动手了，别等写满）、请求处理时间分位数（P99 突然上升往往是磁盘或网络出了问题）。别的指标可以看着玩，这五个是真正能提前预警的。

5. 排查实录：那些年踩过的坑

5.1 消息丢失的四种典型路径

丢消息这件事，一定是在某个环节的配置上留了口子。按发生率排序，我遇到的四种情况是这样的。

第一种，生产者用了 acks=1 加不重试。表面看没问题，实际上 Leader 写完返回成功之后，如果这台机器立刻宕机，数据还没同步到 Follower，新的 Leader 选出来就不包含这条消息。加上 acks=all 和 min.insync.replicas=2 就能堵住。

第二种，消费端先提交位点再处理数据。自动提交加上异步处理是最危险的组合：位点往前走了，业务逻辑还在队列里排队，进程一挂，这批数据就永远丢了。改成处理完再提交，宁可重复不要丢。

第三种，auto.offset.reset=latest加上新消费组接入。新组第一次启动时如果没有历史位点，会直接从最新位置开始读，这之前的消息全部跳过。很多人以为这是“丢失”，其实是配置如此。要读历史就把这个值改成 earliest，而且这个参数只在“无位点”时生效，已有位点的情况下改它没用。

第四种，主题的保留时间太短。保留 1 小时，消费者停了两小时，位点对应的数据已经被删了，再启动时要么报错要么按 auto.offset.reset 走。这种丢失最隐蔽，因为应用层看起来一切正常。

注意：Kafka 本身在 acks=all + 副本数 3 + min.insync.replicas=2 的组合下，单机故障不会丢数据。如果你还是丢了，先怀疑应用层的提交时机，再怀疑磁盘和文件系统，最后才怀疑 Kafka。

5.2 消息积压的应急与根治

积压的根本原因是生产速度大于消费速度，但触发原因五花八门。应急处理有一套固定动作：先看是不是消费者挂了或者卡住了（看线程栈和 GC 日志），再看是不是某个下游依赖变慢导致单条处理时间暴涨，最后看是不是流量本身涨了。

如果确认是消费能力不足，最快的办法是加消费者，但上限是分区数。分区数不够的时候，临时方案是新建一个分区数更多的主题，写一个转发程序把积压主题的数据快速搬过去，再用更多消费者并行消费新主题。这个方案我实际用过一次，一个小时内把积压的几千万条消息消化掉了，但要注意这个转发程序本身不能做复杂逻辑，只做搬运，否则它自己就是瓶颈。

根治的思路是把消费逻辑拆开：把重的、慢的处理挪到异步。比如消费到消息后，只做最轻的校验和落库，把耗时的外部调用扔到另一个线程池或者另一个主题去处理。这样单条处理时间从几百毫秒降到几毫秒，消费能力直接上一个数量级。

还有一个容易忽略的点：max.poll.records设得太大。一次拉 500 条，处理一条要 100 毫秒，那就是 50 秒，一旦超过max.poll.interval.ms，消费者被踢出组，触发再平衡，位点回退，然后重新拉 500 条，再超时，再被踢——形成一个死循环，表现为“消费一直不动”。这种情况把max.poll.records调小，或者把max.poll.interval.ms调大就行。

5.3 再平衡风暴与消费卡顿

有一段时间，某个消费组每隔几分钟就重平衡一次，日志里全是“成员加入”“成员离开”。排查下来是 GC 停顿导致的：消费者实例堆内存给得太大，用的是老式垃圾回收器，一次 Full GC 停了十几秒，超过了session.timeout.ms，协调者认为这个成员挂了，就把它踢出去了。改小堆、换低延迟的回收器、适当调大超时时间，问题消失。

还有一种情况是滚动发布引起的。每次发布，实例一个个重启，每重启一个就触发一次全量再平衡，整个发布过程消费基本停摆。解决办法是配静态成员 ID，让重启的实例在超时窗口内重新加入时保留原有分配；再配合增量再平衡协议，只迁移受影响的分区。这套组合下来，发布期间的消费抖动基本感知不到。

第三个坑是心跳线程和消费线程分离带来的误判。心跳是后台线程发的，只要心跳正常，协调者就认为成员活着。但如果消费线程卡在某个死循环里，一直不 poll，心跳照发，协调者不知道，直到超过max.poll.interval.ms才把它踢掉。表现就是“消费者看起来活着，但就是不消费”。所以监控不能只看“消费者是否在线”，一定要看 lag 有没有在下降。

5.4 常见问题速查表

有个技巧值得单独说：排查消费问题时，先用命令行工具把位点情况打出来，比看应用日志快得多。

# 查看消费组的位点、lag、所属消费者 kafka-consumer-groups.sh --bootstrap-server 10.0.0.11:9092 \ --describe --group order-sync-group # 需要重放时，把位点重置到最早（会触发再平衡，谨慎操作） kafka-consumer-groups.sh --bootstrap-server 10.0.0.11:9092 \ --group order-sync-group --topic order-events \ --reset-offsets --to-earliest --execute

注意：位点重置必须在消费组没有活跃成员的时候执行，否则会报错。操作前先停掉所有消费者，重置完再启动。这个操作不可逆，生产环境执行前一定要确认主题名和组名，别手抖。

我个人在实际操作中的体会是，Kafka 本身很少出问题，绝大多数故障都来自三处：配置没对齐（acks 和 min.insync.replicas 不匹配）、代码没兜住（提交时机、异常处理、幂等）、容量没算够（磁盘、分区数、消费者数量）。把这三点在项目启动时就定清楚，后面能省掉一大半的半夜电话。还有个小习惯我一直保持着：任何主题上线前，先在测试环境用命令行工具手动生产个几万条，再手动消费一遍，确认位点、副本、lag 都符合预期。这个动作花不了十分钟，但能挡掉很多低级错误。