谢丽鹿1. 这次宕机的最初半小时：现象、告警与现场
下午两点多，我正在处理一个需求，监控群里突然开始刷消息。先是Kafka生产端延迟告警，接着消费端lag持续拉高，最后直接收到broker节点失联的告警。我打开监控面板，发现集群里三个节点的分区副本开始大量下线，Controller已经发生了两次切换。整个过程从第一条告警到集群不可写，前后不到半小时，连给人反应的时间都不够。
复盘的时候看时间线，大致是这样：
- 14:05：某Topic的分区leader开始频繁切换，生产端出现
NotLeaderForPartitionException - 14:12：broker-2的磁盘使用率超过85%，触发了阈值告警
- 14:19：消费者组lag从几百条飙到几十万条，消费速率几乎归零
- 14:23：第一个broker被判定失联，Controller发起新一轮leader选举
- 14:27：部分分区进入
UnderReplicatedPartitions状态，生产端大量报错，集群基本瘫痪
这种故障最磨人的不是宕机本身，而是你并不知道它下一步会往哪个方向发展。
客户端日志里当时出现了这样的报错：
code复制org.apache.kafka.common.errors.NotLeaderForPartitionException:
This server is not the leader for that topic-partition
以及一些连接超时、LeaderNotAvailableException、TimeoutException。生产端的数据写不进去，消费端也卡住不动。从应用侧的视角看，Kafka集群像是一台突然熄火的老旧发动机，所有齿轮全部咬死。
我先把现场情况稳住——暂停了部分非核心消费任务的提交，避免消费进度被自动提交机制写坏。然后就开始逐层往下排查。下面把这个排查链路完整写出来，其中有很多命令、判断逻辑是我反复用过的，希望能给遇到类似情况的朋友一些参照。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从客户端报错一路挖到集群节点：我的完整排查链路
2.1 第一层判断：客户端报错，核心是元数据过期
很多人一看到NotLeaderForPartitionException就以为分区leader挂了，其实要分两种情况。一种是leader确实切换中，另一种是客户端持有的元数据长期没刷新，指向了旧leader。
那次现象里，生产端在短时间内集中报出这类错误，同时伴随大量连接重置。我先在客户端测了一下broker连通性：
bash复制kafka-broker-api-versions.sh --bootstrap-server broker-1:9092
这条命令能快速拿到broker支持的协议版本、broker当前是否可响应。如果某个broker直接卡死，命令会超时，这比看监控面板更直观。当时broker-2的响应时间明显异常，但在TCP层面还能连上，说明进程还活着，但JVM内部出了问题，或者底层资源已经阻塞。
接下来看broker端的server.log，出现大量这种日志：
code复制INFO [ReplicaFetcherManager on node 2] Truncated partition ...
WARN [ReplicaFetcherThread nodeId=2] Error for partition xxx-0
org.apache.kafka.common.errors.NotLeaderForPartitionException
这说明broker之间副本同步也出了问题。一个节点既不能正常响应客户端，又无法拉取其他节点的副本数据，整个集群的元数据状态开始变得混乱。
注意一个容易被忽略的坑：如果客户端配置了advertised.listeners和实际监听地址不一致，也会出现客户端报错、看起来像集群不可用的情况。那次我检查了server.properties，没有发现配置错误，于是把重点转移到broker节点本身。
2.2 第二层判断：分区状态异常，优先看副本分布和ISR
我登录一台客户端机器，用AdminClient脚本查看具体的分区状态：
bash复制kafka-topics.sh --bootstrap-server broker-1:9092 --describe --topic order-events
输出里能看到每个分区的leader、replicas和isr列表。当时不少分区ISR里只剩一个副本，其他副本都已经从ISR中掉出。更麻烦的是，ISR中的那个副本在broker-2上，而broker-2正是被判定失联的那台。
这里有个背景知识：Kafka的可用性其实取决于ISR（In-Sync Replicas）。只要leader所在broker还活着，且ISR数量大于min.insync.replicas，生产端还能继续写入。但那次broker-2磁盘IO异常导致它处理的请求全部变慢，Controller在zookeeper.session.timeout.ms或controller.quorum.election.timeout.ms时间内没有收到心跳，就会把它逐出集群。
2.3 第三层判断：磁盘空间和段文件异常，是压垮骆驼的最后一根稻草
我用kafka-log-dirs.sh查看broker上的磁盘目录状态：
bash复制kafka-log-dirs.sh --bootstrap-server broker-1:9092 --describe --topic-list order-events
对比各节点返回的日志目录大小，发现broker-2上的某个磁盘分区几乎被写满。这是Kafka宕机里最常见、也最容易被忽视的诱因之一。
Kafka的日志是以segment文件（日志段）组织的。每个topic分区对应一个目录，目录下包含多个.log、.index、.timeindex文件。当磁盘剩余空间不足时，Kafka的日志清理线程（LogCleaner）和日志滚动逻辑会变得很吃力：
- 清理线程要删旧段文件，但文件删除需要磁盘IO和文件系统层面的空间释放；
- 新消息要写入新段，如果空间不足，分区会直接进入
LogDirOffline状态； - 副本同步时，follower要从leader拉取数据段，leader的磁盘IO一旦拉满，拉取请求就会排队。
我进入broker-2的日志目录确认段文件数量：
bash复制ls /data/kafka/order-events-0/ | wc -l
正常情况下一个活跃分区的段文件数量维持在几十个以内，但当时光这一个分区目录下就有上千个段文件，说明日志滚动异常频繁，或者清理线程压根没跑起来。
再查清理线程是否阻塞，看log cleaner的指标：
bash复制kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.log:type=LogCleanerManager,name=TimeSinceLastRunMs
TimeSinceLastRunMs数值持续增大，说明清理线程长时间没有执行。这个指标平时很多人根本不看，但关键时刻它能直接告诉你清理工作是否正常。
2.4 操作系统层的事实：页缓存与IO阻塞
Kafka的性能极大依赖操作系统的页缓存，写入消息先落到页缓存，再由后台线程刷到磁盘。这是它高效的原因，但也让"数据其实还没真正落盘"这件事变得隐蔽。
我在出问题的broker上看了IO状态：
bash复制iostat -x 1
当时%util已经接近100%，await和svctm数值飙升，磁盘IO完全被堵死。又看了内存：
bash复制free -g
页缓存占用高是正常的，但当时Swap使用率异常增加，说明JVM进程在尝试把内存页换到磁盘，进一步加剧了IO压力。
还要提一个容易踩的坑：Kafka的log.flush.interval.messages和log.flush.interval.ms如果配置不当，会导致数据长时间停留在页缓存，一旦进程被kill或机器断电，数据丢失风险会变大。而如果频繁强制flush，又会带来大量的fsync调用，直接把磁盘IO打满。那次故障里，磁盘写放大和flush配置不当叠加，让原本就吃紧的IO雪上加霜。
综合这些现象，基本可以确定根因方向了：磁盘空间和IO能力不足以支撑集群当前的写入量，日志清理与副本同步互相抢资源，最终拖垮了整个节点。
3. 磁盘占满与IO阻塞的连锁反应：为什么一个小小的存储问题会扯动整个集群
很多运维过Kafka的人都会下意识觉得，磁盘不够用无非就是删点日志腾出空间。但Kafka的存储机制决定了它远比"空间不足"要复杂。这里我想把整条因果链完整拆开。
3.1 为什么数据会"突然"把磁盘塞满
Kafka的日志保留策略有两个维度：按时间log.retention.hours和按大小log.retention.bytes。很多人只设置了时间，没设置大小，结果就是消息积压越来越多，磁盘空间一路涨到底。
那次事故里，某个Topic的日写入量因为业务活动翻了三四倍，但保留策略只写了log.retention.hours=168。消息7天内的数据都要保留，按日写入量的峰值估算，需要的空间远超磁盘容量。旧数据还来不及清理，新数据又源源不断涌进来，磁盘很快就见底了。
还要注意log.segment.bytes这个参数。Kafka并非按消息一条条删除，而是按segment文件整体删除。如果segment文件太大，删除一个文件要等很久；如果太小，文件数量爆炸，目录管理和清理开销增大。默认值是1GB，对大多数场景是合理的。但那次集群的某个分区目录下因为异常出现了上千个小段文件，日志清理线程扫描这些文件都要花很长时间，导致清理速度跟不上写入速度。
3.2 副本同步积压，一点点耗尽IO
在Kafka副本同步机制里，follower副本会主动从leader拉取消息，期间涉及磁盘写入、网络传输、内存缓存等多个环节。当leader所在broker的磁盘IO被打满，follower拉取请求的响应就会变慢。
一开始只是个别分区同步延迟几百毫秒，紧接着变成几秒、几十秒，最后follower长时间追不上leader的日志末尾偏移量，副本被踢出ISR。ISR缩小之后，集群容错能力下降，Controller必须频繁发起leader切换，而每一次切换都需要在新的leader上执行日志截断操作，又要消耗额外的磁盘IO。这个恶性循环一旦形成，很难自己解开。
3.3 高并发下消息延迟攀升，肉眼可见地放大风险
那次业务侧的反馈是：消息发送延迟从几毫秒涨到几十秒，消费端的lag指数级飙升。高并发场景下，Kafka的消息延迟和磁盘IO是强相关的。
写入路径上，分区leader收到生产者的消息，先写入页缓存，等待刷盘。刷盘线程在IO繁忙时排队，生产者的request.timeout.ms如果设置得比较短，就会大量报超时。消费者这边，读取消息主要走页缓存，但页缓存命中率下降后，需要从磁盘读取旧数据段，磁盘IO越慢，消费速率越低，lag越大。
几个关键参数在这里很值得检查：
num.io.threads：处理磁盘IO的线程数，默认8，机器核数多时可以适当调大。num.network.threads：网络线程数，只影响网络收发，不影响磁盘。queued.max.requests：在IO处理线程忙时，请求会在队列里堆积，队列满了之后网络线程也会被阻塞。
那次故障中，恰好这类请求队列全部填满，broker已经无法处理任何请求，但TCP连接还在，客户端侧就是"连接正常但请求超时"的诡异状态。
4. 根因复盘：不是一个配置错了，而是一连串取舍出了问题
复盘的时候，我把故障根因归为三个层面，这三个层面如果单独拆开，每一个都不算致命，但同时出现就形成了完整的故障链条。
4.1 存储容量规划失误：没有按峰值估算
我重新做了容量测算。以事发Topic为例：
- 日写入峰值约500GB，压缩前保留7天，理论需要3.5TB；
- 集群当时单节点磁盘只有2TB，三节点共6TB，看起来够用；
- 但没算上其它Topic的写入、副本因子为3的放大、以及消息压缩率较低的情况。
实际需要的空间往往等于：(所有Topic日写入总和 × 保留天数 × 副本因子) ÷ 压缩率。当时没有按这个公式做压测估算，只是凭经验留了余量，结果被业务峰值直接击穿。
现在我的做法是：每个broker至少预留40%的空闲磁盘空间，并且单独给log目录和OS系统盘做物理隔离，避免log目录写满后影响系统级日志和监控组件的运行。
4.2 日志保留策略与清理参数不匹配
log.retention.hours只设置时间，不设置大小，是一个很常见的隐患。最好同时设置log.retention.bytes，给每个分区设定硬上限，一旦达到上限就触发清理，确保无论如何磁盘都不会被一个Topic拖垮。
另外log.cleanup.policy=delete时，要关注log.cleaner.backoff.ms和log.cleaner.io.max.bytes.per.second。前者控制清理线程的扫描频率，后者是清理速率上限。如果写入速率远高于清理速率，磁盘空间必然持续下滑。把清理速率上限调高一些是可以的，但也要注意不要给IO带来额外负担，这个平衡点要靠实际压测来找。
4.3 副本同步配置和Controller参数过于保守
Kafka的副本同步能力由num.replica.fetchers决定，默认是1。这个数值意味着每个broker只有一个线程在拉取所有副本的数据。当节点数多、分区数多、写入量大时，单线程拉取会成为明显的瓶颈。
那次故障里，follower副本长时间落后于leader，和这个默认值有直接关系。后来我把num.replica.fetchers调到了4，replica.fetch.max.bytes从默认的1MB调整到10MB（根据网络带宽调整），副本同步的恢复速度明显快了很多。
Controller端的参数也值得注意。如果controller.quorum.election.timeout.ms设得太短，节点稍有抖动就会被判定失联，引发不必要的leader切换。而设置太长，又会拖慢故障恢复。根据集群规模，这个值在1000到3000毫秒之间调整比较合理。
4.4 一个隐藏的雷：unclean.leader.election.enable
这个参数在很多线上集群里默认是false，这是对的。但一旦ISR为空、且开启了unclean.leader.election.enable=true，Kafka会允许一个数据落后的副本成为leader。这样做的好处是尽快恢复可用性，坏处是可能丢失已经提交的消息。
那次事故中，ISR一度缩到只剩一个副本，为了避免彻底无法写入，有人提议开启这个参数。我的判断是：在数据完整性要求高的业务里，宁可短暂不可写，也不能接受消息丢失。所以实际线上配置这个参数始终保持false，同时结合min.insync.replicas=2和生产者端的acks=all，确保写入消息至少有两个副本落盘才返回成功。
4.5 一次排查中容易忽略的ACL与认证问题
排查过程中，我还遇到过cluster authorization failed这类报错，是某个客户端访问集群时权限不足导致的。虽然这次不是根因，但它和网络类问题很容易混淆。
这类问题一般有几个方向：
- 客户端配置了错误的SASL/SSL认证信息；
- 客户端使用的账号权限不足，没有Topic的写或读权限；
- broker的
authorizer.class.name配置不一致，导致不同节点的权限判断结果不同。
排查思路是：先从报错的broker日志里找到具体的Principal和操作类型，再用kafka-acls.sh --bootstrap-server ... --list检查该Principal的权限。如果几个broker的ACL不一致，优先检查所有broker的配置文件是否统一。
5. 把这次宕机经验转化成可落地的稳定性手段
故障过去之后，我把之前想到的、以及这次实际踩过的问题全部整理成了可执行的改进项，逐步落地到集群里。这里挑几个见效最明显的写出来。
5.1 分区与容量规划的具体建议
先根据业务实际情况算清楚一个Topic的吞吐目标。比如目标吞吐需要每秒处理10万条消息，每条消息平均1KB，那这个Topic每秒钟要写入约100MB数据。这里不只是磁盘空间的估算，还要考虑分区数、副本数、磁盘IO能力。
分区数不是越多越好。分区多了，每个分区的segment数量也会变多，元数据管理开销变大，Controller的负载也随之升高。一般建议的分区数参考公式是：
code复制分区数 ≈ 目标吞吐 / 单个分区最大吞吐
单分区写入吞吐受限于单个broker的磁盘和网络能力，压测时先测出这个值，再去定分区数。分区数设定之后，尽量避免频繁调整，因为分区迁移和reassign会带来很大的集群压力。
磁盘选型上，如果吞吐要求高，优先用SSD，而且多块盘之间做RAID或者利用Kafka的多log目录（log.dirs）分散IO。log.dirs可以配置多个目录，Kafka会自动把不同分区的数据分散到不同目录，这个特性对多盘机器非常有用。
5.2 关键参数配置清单与推荐值
我整理了一份我实际在用的参数，适合中等规模集群（3-5节点、单节点几十TB）：
| 参数 | 我的推荐值 | 说明 |
|---|---|---|
log.retention.hours |
72或168 | 根据业务需要设置 |
log.retention.bytes |
每分区20GB~50GB | 硬性空间上限，防止单Topic占满磁盘 |
log.segment.bytes |
1GB | 默认值即可，不要频繁调小 |
num.io.threads |
8~16 | 按CPU核数调整 |
num.replica.fetchers |
4 | 提高副本拉取并发度 |
replica.fetch.max.bytes |
10MB | 结合带宽调整，不宜过大 |
min.insync.replicas |
2 | 3副本时设2，提高数据可靠性 |
unclean.leader.election.enable |
false | 宁可不可用，不可丢数据 |
zookeeper.session.timeout.ms |
10000 | ZooKeeper模式下常用值 |
controller.quorum.election.timeout.ms |
2000 | KRaft模式下的推荐值 |
log.cleaner.io.max.bytes.per.second |
50MB | 清理速率上限，避免IO打满 |
需要注意的是，这些参数不是固定的，具体集群要结合机器配置、业务量做压测后再微调。
5.3 高并发场景下的消息积压应对思路
这次宕机过程中，消费端lag飙升是最直观的"大事不好"信号。高并发场景下，如果遇到消息积压，我一般按这个顺序处理：
- 先确认积压原因：是生产端写入超限，还是消费端处理变慢，还是broker本身出问题。
- 如果消费端处理变慢，先看消费者线程数、批量拉取大小
max.poll.records，适当调大。 - 如果有大量堆积，临时扩容消费者实例数，注意消费者组的分区分配。
- 如果Topic本身设计不合理（比如单分区），要考虑是否做Topic拆分或增加分区。
还有一种情况：消费者端反序列化报错、业务处理逻辑抛异常，导致消费线程反复重试，lag一直降不下来。这时要看消费端的日志，把脏数据过滤掉，或者加死信队列单独处理。
高并发下，生产端也要注意批量发送。linger.ms可以适当调到5~20ms，batch.size调到16KB~64KB，能显著提升吞吐，减少网络请求次数。
5.4 多Kafka集群与多地址接入的注意点
那次事故之后，有些周边系统开始做多集群容灾。在Spring Boot里对接多个Kafka地址是常见需求，不少开发者只是简单地在配置里加了多个bootstrap-servers，结果发现消费者组错乱、分区分配异常。
正确做法是每个Kafka集群用不同的消费者工厂和生产者工厂，配置独立。比如：
yaml复制spring:
kafka:
bootstrap-servers: ${KAFKA_CLUSTER_A_BROKERS}
producer:
key-serializer: org.apache.kafka.common.serialization.StringSerializer
value-serializer: org.apache.kafka.common.serialization.StringSerializer
consumer:
group-id: group-a
key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
如果有两个集群，一个用KafkaTemplateA，一个用KafkaTemplateB，同时配置两套ConsumerFactory和KafkaListenerContainerFactory，然后用@KafkaListener(containerFactory = "kafkaListenerContainerFactoryB")来区分监听器归属。
很多线上问题的根源就是使用了同一个containerFactory监听不同集群的Topic，导致消费者组、offset提交完全错乱。
5.5 监控与演练，是最后一道防线
技术复盘做得再多，如果监控不到位，下次故障可能还是要在业务告警之后才发现。这次之后我重点补上了以下几个监控项：
- 每个broker的磁盘使用率，阈值设为75%预警、85%告警；
LogCleaner的运行间隔和清理线程是否堆积；- ISR缩减事件，一旦有分区ISR从完整变残缺，马上告警；
RequestQueue的队列长度，这个指标能提前反映broker处理能力是否饱和；- 每个消费者组的lag，虽然默认有
kafka-consumer-groups.sh --describe可以看，但最好接上指标采集做持续监控。
另外，定期做故障演练是非常值得投入的。比如人为对一个broker停掉，观察集群的恢复速度以及客户端是否发生长时间不可用。这种演练不需要很频繁，三个月一次就行，但能提前发现很多配置和依赖的问题。
我在实际做演练时会顺便检查一下JVM参数。Kafka默认的堆内存是1GB，线上环境根本不够，一般建议设置为系统内存的一半左右，但不要超过32GB。同时启用G1垃圾回收器，因为Kafka里有大量小对象创建和销毁，G1的表现通常比CMS更稳定。
6. 复盘之后我想说的话
那次宕机给我最大的教训是：Kafka的高可用并不是"集群里有多个副本"就自动成立的。副本只是提供了冗余的候选，真正决定可用性的是每个节点自身是否稳定可靠、IO是否跟得上、监控是否到位、配置是否合理。
磁盘空间没规划好、副本同步配置偏保守、清理线程跟不上写入速率，这些单看都不是什么惊天动地的问题，但它们会在某个业务峰值来临时同时爆发，让一个服务瞬间从正常跌入瘫痪。而你在排查时看到的报错，往往是链条最末端的结果，真正的根由埋在最容易被忽略的存储和IO层。
那些NotLeaderForPartitionException、cluster authorization failed、消费lag飙升，都是表象，不是根因。遇到问题先别急着重启节点、删数据，把每一条告警的因果链理清楚，再动手。
我现在每次看到Kafka相关的事故复盘都特别有共鸣，因为自己真的经历过那种"明明所有指标都看似正常，但就是写不进去"的绝望感。希望这篇复盘能帮你少走一些弯路，至少在磁盘规划、副本配置、监控告警这几块，不要再踩同样的坑。