1. 先把 Kafka 的定位搞对它不是拿来替代 RabbitMQ 的我第一次系统啃 Kafka 的时候正赶上公司内部那套 RabbitMQ 在流量高峰段开始拖后腿。团队里好几个人的第一反应是“换 Kafka吞吐高肯定稳”但真等你把它部署起来、把消费者逻辑迁移过去之后才发现事情没那么简单。Kafka 确实快可它的快是有前提的它的设计哲学跟传统消息队列压根不是一回事儿。1.1 从“传统消息队列”到“分布式提交日志”一次定位上的转变传统消息队列RabbitMQ、ActiveMQ 这类的核心抽象是“消息发出去消费完就没了”队列里的消息是易失的、点对点的。Kafka 的核心抽象完全不同它把每条消息追加写进一个只能追加、不可变的提交日志commit log里消费者不主动“取走”消息而是靠一个叫 offset 的游标自己往后读。消息不会因为被消费就被删除而是按保留策略比如保留 7 天或按磁盘大小统一清理。这个差异意味着什么意味着你完全可以在 Kafka 里反复消费同一批数据可以在消息进入后隔几个小时再用批处理的方式重新读一遍也可以把同一份数据同时喂给实时计算引擎和离线数仓。这种模型天生适合做数据管道而不只是应用之间的解耦。所以如果你拿 Kafka 当一个“消息发出去就算成功”的普通队列来用你会错过它 80% 的价值反过来如果你硬要用它实现 RabbitMQ 那种精准的、消费即删除的点对点推送配置也能配出来但你会觉得很别扭。1.2 哪些场景 Kafka 是首选哪些场景别硬用这些年我见到的 Kafka 典型用法基本集中在四类日志采集与统一接入多台服务机的日志通过 Filebeat 之类的采集端打进 Kafka再由下游消费写入 Elasticsearch 或对象存储。这是 Kafka 的“传统艺能”数据量大、允许延迟、吞吐要求高它最擅长。流量削峰秒杀、大促、突发流量场景下直接把请求写进 Kafka后端按自己的消费能力慢慢处理扛住尖峰。因为 Kafka 的 Broker 写入很猛磁盘顺序写能撑住每秒几十万条的消息。事件驱动与 CDC通过 Debezium 把数据库 binlog 转成事件流放进 Kafka下游系统订阅这些变更事件。比如订单状态变化、用户资料修改各业务模块各自消费互不阻塞。流计算的数据源Flink、Spark Streaming 对接 Kafka 是标配因为 Kafka 既能当缓冲又能做回溯流任务挂了可以从上次的 offset 恢复。但也有场景我不建议硬上 Kafka。第一类是需要极低延迟毫秒级的同步 RPC 调用比如用户点了个按钮后端要马上把结果返回给前端这个通常还是走 HTTP 或 gRPC而不是走 Kafka。第二类是消息量不大但业务复杂、需要复杂路由和死信处理的小系统用 RabbitMQ 那一套灵活得多的模型运维也省心。第三类是消息必须精准一次且事务性要求极高的核心交易链路Kafka 能配合事务 API 做到但配置复杂、代价不小不是默认方案。1.3 为什么同样的业务量下RabbitMQ 会先撑不住很多人只听说“Kafka 吞吐高”不理解背后的差别。传统 MQ 的消息存储在内存或按需落盘消费者频繁确认消息会让 Broker 做大量随机删改Kafka 则是所有消息一律追加写入磁盘日志利用操作系统的页缓存做读写加速消费者读取时靠 sendfile 系统调用实现零拷贝。一个是“来一条存一条、删一条”一个是“只管往后写、批量读”设计思路完全不同。另一个关键在消费模型。RabbitMQ 的队列是单队列多消费者竞争一条消息只能被一个消费者拿到Kafka 的分区天然支持多消费者并行每个分区同一时刻只会被消费组内的一个消费者处理但不同分区可以分给不同消费者。只要你把分区数规划够水平扩展消费能力就是加机器的事这是传统 MQ 很难比的。2. 把生产到消费的完整链路拆开看分区、副本、ISR 和消费组接着说它内部是怎么协作的。很多教程会直接抛出一堆名词Producer、Broker、Consumer、Topic、Partition、Offset、ISR、Leader、Follower、Consumer Group。名词本身好记难的是理解它们之间的因果关系。我按一条消息从产生到被处理的完整旅程来讲。2.1 一条消息从 Producer 到 Consumer 到底经历了什么假设你有一个订单服务用户下单后你要把“订单创建”这个事件发出去。Producer 端的工作流程是这样的Producer 拿到你要发送的 Topic 名和消息内容先做序列化然后按分区器Partitioner决定这条消息进哪个分区。默认分区器是 key 哈希取模如果你没指定 key则用轮询或粘性分区Sticky Partition尽量打散。消息不会一条条立刻发到 Broker而是先进 Producer 端的内存缓冲区按 batch 攒批。攒到 batch.size 或等到 linger.ms 的时间到了再一批批发出。Broker 收到这批消息后写入对应分区对应的日志段文件然后根据 acks 配置决定怎么给 Producer 回执。acks0 是发完不管acks1 是写入 leader 就算成功acks-1 是等所有 ISR 里的副本都写入后才返回。消息落盘后Consumer 端通过 poll() 主动去 Broker 拉取数据而不是 Broker 推送。消费组里的某个消费者拿到一批消息、处理完再提交 offset表示“这批我消费完了下次从这之后继续读”。这条链路里最容易被人忽略的是“整个系统没有一个中心调度器”Producer 不需要知道消息在哪个 Broker 上Consumer 也不直接跟某个 Broker 绑定所有路由信息都通过元数据请求动态获取。这种去中心化的设计让 Kafka 能水平扩展但也让排查问题变得更依赖监控。2.2 分区决定吞吐量与顺序性的最小单元分区是 Kafka 并行度的唯一来源。同一个 Topic 的消息分散存储在多个分区里分区数决定了这个 Topic 最多能被多少个消费者并行消费同一个消费组内。如果你一个 Topic 只建了 1 个分区就算后面加 10 个消费者也没用因为同一时间只有 1 个消费者在干活。分区还决定了顺序性的边界Kafka 只保证同一个分区内的消息是有序的不保证跨分区有序。所以如果你想让某个用户的操作按顺序被处理最好的做法是用用户 ID 作为 key这样同一个用户的所有消息都进同一个分区天然有序。分区数怎么定我一般按下述经验估算先考虑目标吞吐量除以单个消费者的实际处理能力再结合预期消费者数量。比如你预期每秒 10 万条消息单个消费者每秒能处理 5000 条那至少需要 20 个分区但还要考虑后续扩容一般我会留 1.5 到 2 倍余量。不过分区数也不是越大越好每个分区都会占用 Broker 的文件句柄和内存分区太多会让 Broker 整体性能下降业界经验是单 Broker 分区总数建议控制在 4000 以内单 Topic 分区数尽量别超过 1000。我第一次建 Topic 时贪多一下建了 200 个分区三节点集群规模不大结果把文件句柄顶爆了这个教训印象深刻。2.3 ISR 和副本为什么 Kafka 的“主从”跟别的系统不一样Kafka 的每个分区都有多个副本它们分为 Leader 和 Follower。所有读写都走 LeaderFollower 只负责从 Leader 同步数据。这里要重点讲一下 ISRIn-Sync Replicas同步中的副本机制。ISR 是一个“跟得上 Leader 的副本集合”不包含那些同步明显滞后的副本。Kafka 判断“跟得上”有两个参数replica.lag.time.max.ms默认 30 秒和replica.lag.max.messages在新版本中已移除主要看时间。如果一个 Follower 超过 30 秒没有向 Leader 发起同步请求它就会被踢出 ISR。ISR 的意义在于Kafka 不需要“多数派”也能工作。它只要确保 ISR 里的副本都写入了这条消息就可以向 Producer 返回成功而不需要等所有副本。这和 Raft、ZAB 这类需要多数派确认的共识算法不同Kafka 选择 ISR 是希望在吞吐和数据安全之间取一个平衡代价是极端情况下可能丢消息比如 ISR 里只剩 Leader 一个副本而 Leader 这时宕机了。你调acksall时其实就是等 ISR 里所有副本都确认写入。但注意如果 ISR 只包含 Leader 自己那acksall也等于只等一个副本所以生产环境最好配合min.insync.replicas配置一个底线比如设为 2这样当可用副本少于 2 时Broker 会拒绝写入宁可不收数据也不能收下有丢失风险的数据。2.4 消费组的再均衡Kafka 最让人头疼的机制之一消费组是 Kafka 实现“每条消息只被组内一个消费者处理一次”的容器。组内消费者与分区的对应关系由 Group Coordinator 管理。消费者加入、退出、崩溃时都会触发分区再分配这个动作叫 Rebalance再均衡。再均衡的问题是它很“重”触发瞬间整个消费组会停止消费所有消费者先把自己手上的分区交出来然后由 Coordinator 统一重新分配再逐个恢复。如果消费者频繁超时或心跳不稳定就会产生反复再均衡消费持续抖动消息延迟会肉眼可见地飙升。触发再均衡主要有三种情况新消费者加入、消费者主动退出、消费者会话超时heartbeat 没及时发。调优思路也很明确把session.timeout.ms调大一些3.0 以后默认 45 秒把heartbeat.interval.ms调小让心跳更密集把max.poll.interval.ms调大到足以覆盖你单次 poll 批次的最长处理时间。我见过太多团队把这个参数设为默认的 5 分钟结果消费者处理一批数据超过 5 分钟触发离组再加入再处理再超时陷入周而复始的再均衡循环。2.5 存储与检索为什么数据都存磁盘了还能这么快Kafka 之所以敢把消息长期放磁盘是因为它精准利用了操作系统的最优路径。Broker 收到消息后写入的是磁盘日志文件但基本是顺序追加写顺序写的速度远快于随机写普通 SSD 上轻松可以跑到每秒 500MB 以上。读消息时Kafka 优先让数据落在页缓存Page Cache里消费者读取如果命中页缓存完全不需要实际 IO。跨进程传输时它通过sendfile零拷贝直接把页缓存里的数据发到网卡省掉了用户态和内核态之间的数据拷贝。所以 Kafka 的“快”不是魔法是顺序写、页缓存、零拷贝、批量传输这四个东西的组合。这也是为什么 Kafka 不太吃 CPU但特别吃内存内存越大能缓存的活跃数据越多。3. 三节点 KRaft 模式集群部署实录从下载到验证前面理论再多不如直接把集群搭起来。这部分我按最近一次在测试环境部署三节点 Kafka 集群的完整过程来讲用的是 KRaft 模式不需要 Zookeeper。这套流程你照抄基本不会出大问题。3.1 为什么现在建议直接上 KRaft 模式老版本的 Kafka 依赖 Zookeeper 来存元数据、做 Leader 选举、管理 Controller。Zookeeper 本身是个好东西但它把 Kafka 架构搞复杂了你要单独维护一套 ZK 集群版本要匹配还要处理 ZK 和 Kafka 之间的通信问题。最麻烦的是在分区数量很多时ZK 的元数据管理会变成瓶颈。KRaft 模式是 Kafka 自己用 Raft 共识算法管理元数据彻底去掉 ZK。Kafka 3.3 起 KRaft 进入生产可用3.4 之后不断迭代到 3.6、3.7 已经比较稳了。新项目我强烈建议直接选 KRaft 模式省掉一套 ZK 运维集群内节点也更均匀。注意如果你要部署的是超老版本2.x还是得用 ZK 模式但那就别部署了直接升级版本。3.2 三个节点的部署与配置细节我用的版本是 kafka_2.13-3.7.0。三台机器的规划如下节点IP角色端口示例kafka1192.168.1.101controller broker9092broker19092controllerkafka2192.168.1.102controller broker9092broker19092controllerkafka3192.168.1.103controller broker9092broker19092controller先把 Kafka 二进制包解压到统一目录比如/opt/kafka然后编辑config/kraft/server.properties。三个节点配置基本相同只有node.id、controller.quorum.voters中的自身地址不同。一份最小可用的配置如下process.rolesbroker,controller node.id1 controller.quorum.voters1192.168.1.101:19092,2192.168.1.102:19092,3192.168.1.103:19092 listenersPLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:19092 advertised.listenersPLAINTEXT://192.168.1.101:9092 controller.listener.namesCONTROLLER listener.security.protocol.mapCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT log.dirs/data/kafka/kafka-logs num.partitions3 default.replication.factor2 offsets.topic.replication.factor2 transaction.state.log.replication.factor2 transaction.state.log.min.isr1几个容易出错的地方advertised.listeners必须写客户端能访问到的地址很多部署出问题都是因为这里的地址没写对客户端连不上但本地netstat看端口明明在监听。log.dirs指向的目录要提前建好并且要保证数据目录不能在系统盘根目录下被误清理。node.id每个节点必须唯一不能重复。格式化存储目录是 KRaft 模式独有的步骤必须在首次启动前执行/opt/kafka/bin/kafka-storage.sh format -t cluster_id -c /opt/kafka/config/kraft/server.propertiescluster_id可以先通过kafka-storage.sh random-uuid生成一个然后三台机器用同一个 cluster_id 格式化。这一步我经常看到有人漏掉直接启动会报“Log directory contains no metadata”之类的错误。3.3 启动、建 Topic 和验证集群健康三个节点都格式化后依次启动/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/kraft/server.properties然后看日志确认启动成功。/opt/kafka/logs/server.log出现Kafka Server started基本就稳了。接着验证元数据仲裁/opt/kafka/bin/kafka-metadata-quorum.sh describe --bootstrap-server 192.168.1.101:9092输出里能看到当前 leader 是谁、投票者有哪些、已同步的节点有哪些。如果只有一台机器在线其他节点还没启动这里会显示一部分节点离线别慌把其他节点启动完再看。建一个用于测试的 Topic/opt/kafka/bin/kafka-topics.sh --bootstrap-server 192.168.1.101:9092 --create --topic test-topic --partitions 6 --replication-factor 2--replication-factor 2的意思是每个分区有两个副本三节点集群这样配可以容忍单节点故障。分区数 6 够测试并行消费效果。建完用--describe查看分配情况/opt/kafka/bin/kafka-topics.sh --bootstrap-server 192.168.1.101:9092 --describe --topic test-topic你会看到每个分区的 Leader 和 Replicas 分布。如果所有 Leader 都集中在同一台机器上说明负载还不均衡多生产消费一会儿或者用kafka-reassign-partitions.sh手动调整即可。3.4 我部署时遇到的问题和你可能也会踩的坑第一次部署 KRaft 模式时我踩了两个坑。第一个是格式化目录后想重新换集群 ID但log.dirs里已经有旧元数据新 ID 格式化不进去报错说目录已有 cluster.id。解决办法是先清空数据目录再格式化或者用--ignore-formatted参数但更稳妥的是数据目录里没有重要数据时直接清理干净。第二个坑是内存配置。Kafka 默认的堆内存只有 1GB对于测试集群够用但一旦你开始压测Consumer 端和 Broker 端都会因为频繁 GC 出现明显的抖动。建议直接改成 4GB 或以上修改bin/kafka-server-start.sh里的KAFKA_HEAP_OPTSexport KAFKA_HEAP_OPTS-Xms4G -Xmx4G另外还有一点三个节点的时间最好保持同步否则 Raft 心跳相关的判断会出现偏差。装个 ntp 或 chrony 做时钟同步一劳永逸。4. 消息延迟高的根因排查从 Producer 到 Consumer 的四个检查点“Kafka 消息延迟高”是我在维护过程中被问到最多的问题之一。要排查先得把“延迟”说清楚否则容易南辕北辙。4.1 排查延迟问题的正确起点先分清楚是哪一段慢端到端延迟指消息从 Producer 发出到 Consumer 处理完成之间的时间它由三段组成Producer 发送耗时、Broker 存储耗时、Consumer 拉取并处理耗时。大多数延迟问题不是全链路都慢而是某一环堵了。所以排查第一步是看监控Producer 端的请求耗时、Broker 端的请求耗时、Consumer 端的 poll 耗时和 processing 耗时分开看。我自己常用的手段是打点埋日志Producer 端发消息前记一个时间戳Consumer 端收到消息后再记一个时间戳两者相减就是粗略的端到端延迟。如果这个值高再看各段的指标。另一个快速判断法是看 Kafka 的consumer_lag如果 lag 持续上涨说明消费速度跟不上生产速度问题多半在 Consumer如果 lag 很小但端到端延迟依然高那问题多半在 Producer 或 Broker 的网络、序列化环节。4.2 Producer 端拖延迟的三件事acks、linger.ms 与重试Producer 端最常见的延迟元凶有三个第一个是acksall加慢速副本。如果某个 Follower 副本所在的机器磁盘性能差或者网络拥塞它同步慢ISR 里一直有它acksall就要等它确认延迟自然高。排查方法看kafka.server:typeFetcherStats相关指标里 follower 的 fetch 耗时如果某个节点明显偏高优先处理那个节点的磁盘和网络。第二个是linger.ms。默认是 0也就是有数据就立即发不攒批。这本身对延迟是有利的但代价是吞吐下降。如果你为了吞吐把linger.ms调到 20ms 甚至 50ms那消息凭空多了几十毫秒的等待这完全是你亲手“制造”的延迟。所以追求低延迟就别调大linger.ms追求高吞吐就接受它带来的延迟二者不可兼得。第三个是重试。retries设置太大加上retry.backoff.ms默认 100ms一旦网络抖动导致发送失败消息会卡在重试流程里。更麻烦的是如果你的分区 Leader 切换频繁比如副本不稳定Producer 端的metadata.max.age.ms更新不及时会不断向旧 Leader 发消息失败再重试延迟直接原地起飞。4.3 Broker 端拖延迟的隐藏因素磁盘、页缓存与分区膨胀Broker 端的问题常常比 Producer 端隐蔽。最典型的磁盘已经成瓶颈但你没发现Kafka 是顺序写但也架不住数据量持续暴涨。用iostat看%util和await如果磁盘长期处于接近 100% 状态那就是写不动了延迟必高。优先排查是不是某个分区的消息特别大、特别多或者日志保留时间设置太长。页缓存命中率低如果你给操作系统留的 Page Cache 不够比如 Broker 所在机器上还跑着别的吃内存服务消费者读消息时频繁落盘延迟翻倍都正常。Kafka 所在机器除了 Kafka 和操作系统尽量别放重服务。分区数量膨胀分区越多每个分区需要维护的文件句柄和内存越多Broker 线程池被分散到各分区后单个分区的处理能力下降。如果集群里一堆 Topic 都是几百个分区、副本数还很高先清理无用 Topic 再谈延迟。副本同步滞后Follower 同步不及时会导致主副本一直等 ISR 确认如果 acksall或触发 Leader 切换后新 Leader 数据不完整。查kafka.server:typeReplicaManager下与 ISR 缩减相关的指标如果 ISR 频繁缩到只剩 Leader那这个集群随时有丢数据风险延迟反而是次要问题了。4.4 Consumer 端最常见的四种“假延迟”和真实阻塞Consumer 端是我排查延迟时发现最容易出幺蛾子的环节。有四种经典情况第一种单条消息处理耗时过高。消费者在 poll 出来的循环里做同步调用比如查数据库、调外部 API每条消息耗几百毫秒一批 500 条就要处理几分钟。此时你看到的是 lag 持续上涨但代码看起来“没毛病”。解法是区分 IO 密集型和处理密集型把耗时的外部调用异步化或者增加消费者数量分摊。第二种max.poll.records 设置过大。默认 500如果每条消息处理时间不短一次 poll 要处理特别久超过max.poll.interval.ms默认 5 分钟后消费者被判定为“僵死”踢出消费组触发 Rebalance然后新消费者又从旧 offset 开始读处理完又超时陷入死循环。我自己习惯把这个参数调到 100 或 200宁可 poll 频繁一点也别让单次处理时间过长。第三种心跳与处理互相阻塞。heartbeat.interval.ms太大会导致心跳发送不及时Broker 误判消费者下线。这里有个细节max.poll.interval.ms内消费者可以完全不发心跳但如果你的业务处理时间偶尔超过这个值就会先离组再加入。调大max.poll.interval.ms可以缓解但根治还是得缩短单次处理时间。第四种消费端网络或 CPU 被占用。消费端本身机器负载高处理线程被 GC 停顿频繁打断poll 耗时和 processing 耗时都高。可以先看消费端机器的 GC 日志如果有持续的长停顿把堆调大或者调整 GC 策略。4.5 一份按延迟目标调整的参数参考下面是我在多个项目里按不同延迟目标试出来的参数参考注意这是经验值不是标准答案延迟目标ackslinger.msbatch.sizemax.poll.records备注极致低延迟10ms10默认不刻意调大100不要用 acksall副本尽量稳定均衡100msall5-1016KB 起200吞吐优先延迟可接受高吞吐100msall20-5064KB 起500批量攒够再发延迟换吞吐acks1比acksall的延迟低很多但代价是 Leader 宕机时可能丢几条数据。如果你的业务能接受极端情况下少量丢失追求低延迟就用acks1如果不能还是老老实实acksall配min.insync.replicas2。天下没有免费的午餐。5. 用热门的 Kafka 面试题反向学习吞吐、丢消息、顺序、积压的底层逻辑Kafka 面试题一直很火但我觉得背答案没什么用。这些题之所以高频是因为它们正好覆盖 Kafka 最核心的设计取舍。把每一道题背后“为什么”搞明白面试是次要的你排查线上问题会顺手得多。5.1 Kafka 为什么吞吐量高不是某一个优化而是整套设计组合“Kafka 为什么快”是一道送分题但很多人只答了“顺序写、零拷贝”这是不够的。完整答案应该包含四层生产者端是“攒批发送”通过 batch.size 和 linger.ms 把大量小消息合并成一批大消息再发减少网络往返次数和 Broker 的写入次数。Broker 端是“顺序追加写”利用磁盘顺序写速度接近内存读速度的特性配合页缓存让绝大部分读取直接命中缓存。传输层是“零拷贝”消费者拉数据时数据从页缓存直接通过网卡发送不经过用户态。消费端是“分区并行”通过增加分区数和消费者数把吞吐量线性扩展。如果某道面试题只让你答一点你把这四个点按顺序讲完面试官基本就没法在这个题上加难度了。因为这套组合能不能真正发挥取决于你的参数配置这也是我前文反复强调参数的原因光有机制没有对应配置Kafka 也跑不出性能。5.2 消息不丢失Producer、Broker、Consumer 三个层面分别怎么做“Kafka 怎么保证消息不丢”是所有 Kafka 面试题里的必问题。我在回答时习惯分三段讲Producer 端设置acksall等待 ISR 全部确认开启重试retries设置非 0如有需要开启幂等enable.idempotencetrue避免重试导致重复消息。Broker 端replication.factor 2副本至少两份min.insync.replicas 2保证 ISR 里至少有两个副本才接收写入注意如果副本数设为 3min.insync.replicas设为 2可以容忍一台机器宕机而不丢失已确认消息。Consumer 端处理完业务逻辑后再手动 commit offset不要在拉取消息后马上提交同时消费者侧要做幂等因为 Kafka 即使各种配置都正确下游网络异常、机器宕机时依然可能出现 at-least-once至少一次的重复消费业务端做好幂等才是最终兜底。整体思路就是“每个环节都做到能确认的就确认到底不能确认的靠重试最后靠幂等”。这个问题没有什么魔法全是工程取舍。5.3 消息顺序性Kafka 能做到什么程度什么情况只能自己做取舍Kafka 只保证分区内有序不保证 Topic 全局有序。这几乎是所有顺序类问题的答案核心。具体做法是把需要有序的关键字段比如订单 ID、用户 ID作为 key相同 key 的消息进同一分区分区内天然有序消费端单分区单线程处理不要在该分区上做并行消费。如果你确实需要全局消息有序Kafka 原生做不到除非你的 Topic 只有一个分区——但那样吞吐量就废了。我见过一个案例订单系统要求全局有序硬把一个 Topic 建成了 1 个分区结果高峰期每秒几万条订单全挤在一个分区消费者再怎么加也跑不动最终被迫改成按用户维度分区、仅在单用户内保证有序这才是 Kafka 推荐的做法。5.4 消息积压与消费延迟从扩容到幂等的完整处理思路线上遇到消息积压lag 飙升处理思路要分情况。如果是消费者处理能力不足先看能否增加消费者实例。注意增加消费者数量最多只能到分区数超过分区数后多余消费者会空闲因为每个分区同时只分配给一个消费者。所以如果你 Topic 只建了 6 个分区消费者加到 10 个有 4 个在空转。这种情况只能给 Topic 增加分区数但要注意增加分区数之后原本按键分布的 key 到分区的映射会重新洗牌已有消费者的分区分配也会乱搞不好顺序性就不保证了所以扩容分区要谨慎。如果是某条消息处理卡死比如反序列化异常、消息里字段格式不符合预期消费者反复在一条坏消息上报错重试后续消息全部堵住。解法是跳过坏消息或把它转发到死信队列不要让消费线程死循环。最快的止血方式是临时新增一个消费者组把 lag 分摊走或者直接改max.poll.records小批量处理让阻塞点更早暴露。另外不要忘记幂等设计。积压处理完毕后消费端有可能重复处理一些消息如果业务没有幂等会造成重复订单、重复发券等事故。我在上线前一定会要求所有消费逻辑具备天然幂等性比如通过消息主键做去重表、通过状态机限制重复流转这样积压恢复时才能放心让消费者猛跑。我个人在实际维护中的习惯是每次扩容消费者前先看分区分配是否均匀再看消费端的单条耗时不要一上来就改 Broker 参数很多时候问题出在最容易被忽略的消费者处理耗时上。另外Kafka 集群的监控一定要做消费 lag 曲线和端到端延迟曲线不用太复杂Prometheus 加 Grafana 足够哪怕没有告警只看趋势也能帮你提前发现问题。这套部署和排查的路子我自己走了很多遍希望能帮你少踩几个坑。
