企业官网建设流程全解析

我第一次认认真真研究 Kafka 消息队列，不是赶时髦，而是因为凌晨两点的线上故障：订单接口超时被打爆，库存扣减、积分发放、物流通知全挤在一次请求里同步调用，任何一个下游服务抖动，用户就要陪着一起等。折腾到天亮，我意识到问题不是出在代码写得不够快，而是架构里缺了一个组件——它能让系统在高峰时"先接单、后处理"，把突发的流量削平，把服务之间的强耦合拆开。这个组件就是 Kafka。

这篇文章不是把官方文档翻译一遍，而是站在我实际用 Kafka 做生产项目的角度，从零开始讲清楚消息队列是什么、Kafka 怎么装、生产者和消费者怎么写、线上重复消费和延迟高怎么排查，最后再把面试里最容易翻车的几个原理题串一遍。适合完全没接触过 Kafka 的后端开发，也适合已经会发消息但被各种"坑"折磨过的同学。

1. 消息队列到底在解决什么问题？

1.1 同步调用的痛，我从一个订单接口说起

先想象一个非常常见的下单流程：用户点支付，订单系统需要同步调用库存系统扣库存、调用优惠券系统核销、调用积分系统加积分，可能还要推一条短信。这个接口的总耗时等于所有下游耗时之和。

有一天库存系统发版慢了两百毫秒，整个下单接口集体变慢；再有一天积分系统数据库连接池被打满，下单接口直接超时。用户不会管是不是积分系统的锅，他只看到下单失败。这就是同步架构的问题——任何一环不稳定，整个链路都会被拖下水，而且系统越滚越大，谁也不敢轻易加新的下游服务，因为每加一个同步调用，请求就要多等一次网络往返。

1.2 解耦、异步、削峰，消息队列被发明出来的理由

消息队列的解法很直接：把同步调用变成异步消息。订单服务把"订单已创建"这个事件写进 Kafka，库存、积分、短信各自从 Kafka 里订阅这个事件，拿到之后自己处理。

这样一来有三大好处：

• 异步化：下单接口不用等库存和积分处理完，只要消息写进 Kafka 就算成功，响应时间从几百毫秒降到几十毫秒。
• 解耦：订单服务完全不需要知道下游有哪些系统。以后新增一个数据分析服务，直接订阅同一条消息就行，订单服务一行代码都不用改。
• 削峰填谷：秒杀场景下流量瞬间暴涨，数据库一瞬间接不住。Kafka 先把海量请求按自己的节奏接进来，下游消费服务再按自己的处理能力批量跑，高峰期不崩，高峰期过后慢慢追平。

我经常拿餐厅打比方：没有传菜窗口时，厨师炒好一盘菜，得满大厅找对应的服务员，炒一个催一个，最后锅铲都要抡出火星。有了传菜窗口，厨师只管把菜放进窗口、按铃，服务员忙完手头的活再过来取。窗口能积压多少菜，决定系统能扛多大流量——这就是消息队列的缓冲价值。

1.3 Kafka 和其他消息队列怎么选

消息队列不是一个新概念，RabbitMQ、RocketMQ、ActiveMQ、甚至 Windows 上的 MSMQ 都在各种遗留系统里服役。但 Kafka 的定位和它们不太一样：

Kafka 最初是 LinkedIn 为了处理海量日志和用户行为数据开发的，所以底层设计天生向"吞吐量"和"堆积能力"倾斜。它把每条消息当作日志里的一个记录，不断追加写入磁盘，所以非常抗压。如果在选型时遇到"哪种场景适合 Kafka"，我的判断标准就一句话：当你需要高吞吐、可回放、能堆大量消息的时候，Kafka 合适；如果你只是业务量不大、希望路由规则灵活，RabbitMQ 学起来更快，运维成本也更低。

1.4 什么场景不该上 Kafka

我见过不少团队把 Kafka 当万能药，什么业务都往里塞，最后反而被复杂化。如果你的调用链路本来只有两三个服务，同步调用的响应时间也能接受，那就别引入 Kafka——一个消息队列会带来消息重复、乱序、积压、消费失败重试等一堆新问题。另外，强事务要求的场景也要谨慎：Kafka 虽然有事务 API，但它的定位是最终一致，不是像数据库那样提供强一致的事务保证。比如扣款和加积分，绝对不能"发了个消息就算成功"，必须设计对账和补偿机制。

2. 从零搭一个能跑的 Kafka：Windows、Linux 都别慌

2.1 运行前准备：JDK、版本与 KRaft 模式

Kafka 是 JVM 系的消息队列，所以装之前先确认机器上有 JDK。Kafka 3.x 之后对 Java 版本要求是 11 及以上，部分新版本已经需要 Java 17。如果你手头正好有多个 JDK 版本，建议给 Kafka 单独指定JAVA_HOME，避免项目里的 Java 8 环境把它带崩。

还有一个让新手绕圈子的坑是 ZooKeeper。旧版 Kafka 必须依赖 ZooKeeper 存元数据、做选举，搭个集群等于同时部署两套系统，非常费劲。Kafka 3.3 开始引入 KRaft 模式，把元数据管理收回到 Kafka 自身，单节点或三节点集群都可以不用 ZooKeeper。我建议 3.x 的新项目直接用 KRaft 模式，少一个组件就少一半故障点。如果你看老文章还在教 ZK 那一套，可以先确认一下版本，不是文章错了，是时代变了。

2.2 单机版 20 分钟跑通

先去 Kafka 官网下载二进制包，文件名类似kafka_2.13-3.7.0.tgz，其中2.13是编译用的 Scala 版本，3.7.0是 Kafka 版本，初学者不用太纠结。下载后解压：

tar -xzf kafka_2.13-3.7.0.tgz cd kafka_2.13-3.7.0

KRaft 模式第一次启动需要先格式化存储目录。这步很多新手会漏，漏了就报Storage directory ... not formatted。正确姿势是这样：

# 生成一个集群 ID KAFKA_CLUSTER_ID=$(bin/kafka-storage.sh random-uuid) # 格式化日志目录 bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties # 启动服务 bin/kafka-server-start.sh config/kraft/server.properties

看到started (kafka.server.KafkaRaftServer)之类的日志，说明服务起来了。然后开另一个终端验证：

bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-topic --partitions 3 --replication-factor 1 bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic my-topic bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-topic --from-beginning

在 producer 窗口敲几行字，consumer 窗口能看到，说明通路已经打通。

2.3 Windows 上的安装要点

Windows 上跑 Kafka 也是可行的，我甚至见过不少同学的项目是 Windows 开发机连远程测试集群，本地只装一个单机版做实验。流程基本一样，只是把命令行换成.bat：

:: 设置 JAVA_HOME 后执行 bin\windows\kafka-server-start.bat config\kraft\server.properties bin\windows\kafka-topics.bat --bootstrap-server localhost:9092 --create --topic my-topic --partitions 3 bin\windows\kafka-console-producer.bat --bootstrap-server localhost:9092 --topic my-topic

这里要特别提醒三个 Windows 环境下的坑：

• 解压路径不要带中文、空格和特殊符号，Kafka 对路径的处理在 Windows 上很娇气，放在C:\Program Files下可能直接起不来。
• 如果日志抛出OutOfMemoryError，检查KAFKA_HEAP_OPTS或KAFKA_JVM_PERFORMANCE_OPTS，默认堆内存设置可能不适用于小机器，可以显式设成-Xmx512m -Xms256m起步。
• Windows 自带杀毒软件有时会扫描日志目录，导致 Kafka 写入卡顿，可以在测试环境把 Kafka 目录加入白名单。

2.4 server.properties 里最影响实战的几个配置

不管用 KRaft 还是 ZooKeeper 模式，最终都要面对config/kraft/server.properties（旧版是config/server.properties）。这几个配置我建集群时几乎必改：

这里有个很容易踩的误区：很多人以为分区数越多吞吐越高，于是建主题直接设 64 个分区。分区数确实能提升并发度，但每个分区在消费者、副本、索引层面都有额外开销，分区太多而机器太弱，反而把性能拉垮。分区数应该围绕目标吞吐估算：单个分区每秒处理量 × 分区数 ≥ 峰值消息量，再留 30% 冗余。比如单分区实测能扛 500 条/秒，业务峰值每秒 1000 条，分区数给 4 个就够。

我的建议是：学习阶段老老实实用默认 3 分区，先把整条链路跑熟，再去纠结分区数的微调。

3. 生产者：把消息发得又快又稳

3.1 主题、分区、副本，三个名词一次搞清楚

Kafka 里最基础的概念是主题、分区和副本。

主题是消息的逻辑分类，好比一本《订单流水账》。分区是主题在物理上的拆分，好比这本账被拆成好几册，每册存一部分订单。消息并不是一股脑写进主题，而是先被路由到某个分区，再往这个分区的文件末尾追加。

副本则是分区的备份。每个分区默认可以配置多个副本，其中一个叫 leader，其他人叫 follower。生产者和消费者只跟 leader 交互，follower 默默同步 leader 的数据，一旦 leader 挂了，再从中选一个接管。

这三个概念理解了，后面所有操作都有抓手。

3.2 路由规则：为什么 key 如此重要

生产者把一个消息发出去，核心代码只有一行：

props.put("bootstrap.servers", "localhost:9092"); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); KafkaProducer<String, String> producer = new KafkaProducer<>(props); // 带 key 的消息 producer.send(new ProducerRecord<>("order-events", "order-123456", "ORDER_CREATED"));

第二个参数key非常关键。Kafka 默认分区器处理 key 的逻辑是：对 key 做哈希，再用分区数取模，决定消息去哪个分区。于是同一个 key（比如同一个订单号）的所有消息，都会被送到同一个分区，也就天然保证了分区内的顺序性。

如果 key 传了 null，Kafka 会用粘性分区策略，在多个分区之间轮询分发，这样并发写性能更好，但没有顺序保证。所以业务上如果需要"同一用户的操作必须按顺序处理"，就必须带上用户 ID 作为 key，而不是图省事传 null。

3.3 生产者参数调优：克制比堆参数重要

生产者的性能瓶颈通常不在 Kafka 端，而在生产者自己怎么攒批、怎么确认、怎么压缩。几个核心参数表格列出来：

初学者最容易犯的错是acks=0图快。在本地 demo 里感觉不到差别，生产环境一旦 broker 抖动，消息就悄悄丢了，而且无迹可查。我一般建议：默认值 all 不要动，除非你明确知道自己要牺牲多少可靠性换取多少性能。

还有一个容易被忽略的是单条消息大小。Kafka 默认单条消息上限约 1MB，如果业务要传大 JSON 或文件流，需要联动修改三个地方：broker 端message.max.bytes、生产者max.request.size、消费者fetch.max.bytes。只改一处是没用的，这是"接收 1M 消息失败"类问题最常见的病因。

3.4 生产端写消息的习惯，比 API 重要

调参只是锦上添花，真正影响稳定性的写消息习惯往往被忽略。我总结了三条：

• 不要在 for 循环里同步等发送结果。一次send()是异步的，如果你紧接着用producer.flush()或直接拿get()等结果，等于把异步又改回同步，高吞吐场景立刻打回原形。正确做法是发送回调里记录失败日志，定时flush()。
• 失败重试要有界限。retries默认已经不小，但网络长时间抖动时，无限重试会拖死生产者。配合delivery.timeout.ms设定整体上限，超过上限就进死信流程，别跟一条消息死磕。
• 幂等生产者默认就开。Kafka 3.0 之后enable.idempotence默认是 true，配合acks=all，可以避免重试带来的重复消息。如果在老版本环境，记得显式开启。

4. 消费者：重复消费、消费组和顺序性问题一次说清

4.1 消费组和分区分配：谁消费哪个分区，谁说了算

消费者不是孤零零自己跑的，它一定要归属于某个消费组，也就是配置里的group.id。同一个消费组内的多个消费者，会平分主题里的所有分区。比如一个主题有 6 个分区，消费组里有 3 个消费者，那么每个人消费 2 个分区；如果组里只有 1 个消费者，它一个人消费全部 6 个分区。

这里经常有人误解：以为启动两个消费者，同一个消息就能被两个服务都收到。不对，只有不同group.id的两个消费者组，才会各自收到一份完整的消息。这就像订单事件既发给了"库存组"，又发给了"风控组"，两个组各收一份；而同一个组内的多个消费者，只是同一份消息在不同分区上的分工。

分区分配不是固定的。当消费者加入、离开或崩溃时，消费组会触发重平衡，把所有分区重新分一次。重平衡期间该组的消费会停顿，这也是很多线上卡顿的元凶。

4.2 offset 提交机制：自动提交的甜蜜陷阱

消费者读消息的进度，靠 offset 标记。offset 表示"这个分区我已经读到哪一条了"，它会被提交到 Kafka 内部的__consumer_offsets主题里。新消费者加入时，根据 offset 决定从哪里继续读。

Kafka 消费者默认是自动提交offset 的，也就是enable.auto.commit=true。看着很方便，但有个致命问题：自动提交是周期性触发的，不是"处理完一条提交一条"。假如你poll()拉到 500 条消息，刚处理到 100 条时，进程崩溃了，而自动提交还没来得及执行，那下次重启时，这 500 条消息会全部重新消费一遍。如果处理逻辑没有幂等，就会产生大量重复数据。

所以可靠消费的关键是手动提交：

Duration timeout = Duration.ofMillis(1000); while (true) { ConsumerRecords<String, String> records = consumer.poll(timeout); for (ConsumerRecord<String, String> record : records) { process(record); // 业务处理 } consumer.commitSync(); // 处理完一批，再提交 offset }

手动提交还有两种姿势：commitSync同步提交，处理完一批后阻塞等待提交成功，最稳但吞吐最低；commitAsync异步提交，不阻塞，但失败时不会自动重试，需要自己监听回调。我习惯的做法是业务量小时用commitSync，业务量大时用commitAsync加回调重试，总之把"提交"和"拉取"之间的边界掰清楚。

4.3 重复消费的根因与幂等方案

重复消费不是 bug，而是至少一次语义下的正常现象。Kafka 无法保证每条消息绝对只被消费一次，它只能做到不丢消息，但在网络抖动、消费者崩溃、提交失败时，允许重复。所以后端设计必须遵循一条铁律：下游处理要幂等。

幂等的方法按场景选：

• 利用业务唯一键：比如每条消息里带 orderId，处理时先查数据库，存在就跳过，否则插入。数据库唯一索引是终极防线。
• 利用 Redis setnx：用消息 ID 作为 key，SETNX成功才处理，并设置过期时间，防止并发重复进来。
• 本地去重：短时间窗口内维护已处理 ID 集合，适合对内存敏感度不高的场景。

我曾经接手过一个账务系统，消费方一开始没做幂等，对账那天突然冒出大量重复单据，排查下来就是消费者在 offset 提交前崩溃，重启后把上批消息重放了一遍。从那以后，我对所有 Kafka 消费代码的要求都是：可以重复，但重复的结果必须和一次执行完全一致。

4.4 多线程消费下如何保住消息顺序

Kafka 的机制决定了一个分区内的消息是有顺序的，但前提是只有一个线程在处理这个分区。如果你把消费到的消息丢给线程池并行处理，顺序立刻被打乱。热词里那个"消费端多线程如何保证消息顺序性"，答案就藏在这里。

核心思路不是不加多线程，而是让同一 key 的消息永远只交给同一个线程。做法是：消费者拉完一批消息后，按 key 哈希取模，把消息路由到固定编号的 worker 线程：

int workerCount = 8; ExecutorService[] workers = new ExecutorService[workerCount]; for (int i = 0; i < workerCount; i++) { workers[i] = Executors.newSingleThreadExecutor(); } for (ConsumerRecord<String, String> record : records) { int index = record.key().hashCode() % workerCount; workers[index].submit(() -> process(record)); }

同一个 key 哈希结果相同，永远路由到同一个单线程 worker，这样既利用多线程提升了吞吐，又保住了同一个用户的顺序。这里要注意，hashCode()的结果可能为负数，取模前先Math.abs或加掩码；另外至少要保证 worker 数是固定的，否则改了线程数，同一个 key 就被分到不同线程，顺序就乱了。

4.5 poll 循环里最常见的错误

消费者 API 看似只有poll()一个动作，但它不是"随叫随到"的接口，而是一个持续的心跳循环。Kafka 要求消费者在max.poll.interval.ms时间内至少完成一次poll()，否则会被判定为挂掉，强制踢出消费组。

于是很多新手会遇到这种诡异现象：处理业务花了一分钟，代码还在跑，消息消费却是戛然而止，日志里出现 rebalance。根因是默认的max.poll.interval.ms只有 5 分钟，如果你的单条消息处理逻辑跑得比这还慢，或者一次poll()拉了太多消息，处理不完就超时了。

解法有两个方向：一是调大max.poll.interval.ms，二是在业务侧缩短单次 poll 处理时间——比如把max.poll.records调小到 100，处理完立刻commitSync再去下一轮poll()。我通常两者结合，毕竟拉取和处理本来就不该在同一个循环里纠结到底。

5. 从"能跑"到"跑稳"：上线后的排查笔记与工具链

5.1 实战排查：消费组怎么一直在重复消费

现象：数据库里出现大量重复的订单消息，消费组日志显示一直在消费，但消息位点不前进。

我的排查顺序是这样：

• 先看kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --describe，观察LAG这个指标。如果 LAG 一直在涨，说明消费赶不上生产；如果 LAG 为 0 但还在重放，八成是提交问题。
• 检查消费者的enable.auto.commit，如果是 true，再把提交间隔拉长看是否出现重复窗口；把日志里每批消息的处理耗时和commit调用时间对齐，能清晰看到"处理完到提交前"这段窗口。
• 最后检查业务处理有没有幂等保护。没有的话，先补幂等救命，再思考怎么把提交窗口缩短。

这个案例给我的教训是：排查重复消费，先别怀疑 Kafka 丢消息，先怀疑自己提交姿势不对。

5.2 实战排查：消息延迟高，到底卡在哪一段

消息延迟高是使用 Kafka 最常遇到的投诉。延迟不等于 Kafka 慢，而是从生产端产生消息到消费端真正处理完这段链路上，某一个环节拖了后腿。

我一般从三段入手：

• 生产端：看生产者发送耗时和record-queue-time，如果本地linger.ms调得太大，或者发送失败重试次数多，延迟会被强行拉高。
• Broker 端：看 broker 机器 CPU、磁盘 IO，Kafka 虽然是顺序写，但磁盘满了或者页缓存被其他服务挤占，吞吐照样崩。
• 消费端：看消费者单条处理耗时，这是延迟高最常见的位置。处理逻辑里查数据库、调远程接口都可能是瓶颈。再核对一下分区数和消费者数——如果主题 20 个分区，消费组只有 2 个消费者，那每个消费者平均要扛 10 个分区，处理不过来，LAG 自然越拉越高，延迟当然大。

这里有个顺手的排查技巧：用kafka-consumer-groups.sh看 LAG 之后，再在业务日志里给每条消息加"生产时间戳"和"消费时间戳"，两边一减，哪个阶段耗时最长立刻就暴露了。没有埋点，延迟问题就只能靠猜。

5.3 实战排查：rebalance 风暴如何收场

有一类故障特别迷惑人：消费者没报错，但整个消费组每隔几分钟就暂停一次，日志里反复出现 rebalance。原因通常是某个消费者处理太慢，心跳超时被踢出，组里其他人接手它的分区后，它又重新加入组，来回拉扯，这就是 rebalance 风暴。

处理方案分四步：

• 调大session.timeout.ms和max.poll.interval.ms，给慢消费者更多喘息空间。
• 调小max.poll.records，减小单次 poll 处理量，减少超时概率。
• 把同步的耗时业务挪出 poll 主线程，改成异步处理或批量处理。
• 给消费组接入指标监控，把 rebalance 次数和 LAG 一起盯起来。

但也要注意，一味调大超时参数只能缓解，不能根治。真正的问题是业务处理能力不够，该扩容的扩容，该拆分的拆分，该上线程池的上线程池。

5.4 集群化部署的参数底线

单机版和集群之间，不只是多起几台机器的问题。集群部署时至少要守住这几条底线：

Broker 数设 3 主要是为了在挂一台节点时，剩下的节点还能凑够多数派完成选举和副本同步。副本因子 3 和min.insync.replicas=2配合acks=all，意味着一条消息必须写入 2 个以上副本才算成功，这样单点故障时消息不会丢。注意副本因子不能比 Broker 数还大，比如 3 台机器配副本因子 5，分区永远无法同步，日志里全是Not enough replicas报错。

集群安装本身不复杂：每台机器下载相同版本的 Kafka，server.properties里配置broker.id必选唯一，KRaft 模式下用同一个cluster id格式化存储目录，再逐个启动就行。难的是启动顺序和配置一致性，建议用配置管理工具统一维护，别手敲。

5.5 可视化工具和命令行三板斧

很多初学者拿到 Kafka 不知道从哪看消息，这里分享我常用的三件套：

• 命令行工具：Kafka 自带kafka-topics.sh、kafka-console-consumer.sh、kafka-consumer-groups.sh。我每天用得最多的是kafka-consumer-groups.sh --describe，一眼看尽每个消费组的 LAG。
• Offset Explorer（原 Kafka Tool）：桌面客户端，适合快速浏览主题、查看分区和消息内容。注意它只适合开发环境，别在压测环境乱连。
• Kafka UI（开源项目）：Web 面板，比桌面工具好在团队共享，可以直接在浏览器里查主题、看消息、查看消费者组 LAG。后端把 Kafka 节点暴露到内网，团队成员就都可以自助排查。

至于消息内容是否可视化，我有个提醒：生产环境的消息里常有敏感数据（用户 ID、手机号），给开发环境开可视化没问题，生产环境最好只给运维和核心开发开，并且做好权限控制。

5.6 顺带一提：C++/Qt 项目中怎么接 Kafka

如果你是在 C++ 或 Qt 项目里对接 Kafka，绕不开的是 librdkafka。它是 C/C++ 生态的事实标准客户端，Confluent 官方也在维护。核心配置和 Java 端一致：

RdKafka::Conf *conf = RdKafka::Conf::create(RdKafka::Conf::CONF_GLOBAL); conf->set("bootstrap.servers", "localhost:9092", errstr); conf->set("group.id", "my-group", errstr); RdKafka::KafkaConsumer *consumer = RdKafka::KafkaConsumer::create(conf, errstr);

Windows 上如果要用 MinGW 编译 librdkafka，最容易踩的坑是：动态库版本必须和你编译器位数一致，x64 的 Qt 程序不能链 x86 的 librdkafka；另外 librdkafka 依赖 openssl 和 zlib，要提前装好并让 CMake 能找到它们。Qt 本身不提供 Kafka 组件，所以整体思路就是"Qt 写界面和业务，librdkafka 负责和 Kafka 通信"，两边用信号槽接起来。代码上尽量把 librdkafka 的消费回调放到独立线程，避免卡住 Qt 的事件循环。

6. 面试必问：这五个 Kafka 原理题最好别答错

6.1 为什么 Kafka 快得像不像传统消息队列

Kafka 的高吞吐不是靠复杂的缓存算法，而是靠几个非常朴素的底层设计：

• 顺序写磁盘：传统消息队列表面上是"存内存"，最终落地时其实是随机写盘。Kafka 直接以追加形式顺序写文件，磁盘顺序写比随机写快几个量级。
• 页缓存：Kafka 不自己做缓存，而是依赖操作系统的页缓存。刚刚写入的数据，消费者往往马上能读到，命中的是内存，不是磁盘。
• 零拷贝：消费端读数据时，Kafka 通过sendfile把磁盘数据直接传给网卡，省掉拷到用户态的环节。
• 批量与压缩：生产者攒一批再发，消费者一批一批拉，网络传输成本被均摊。

我把这套设计理解为"快递集散中心"：散户一件一件发货，物流成本高、效率低；Kafka 把大量包裹先按目的地打包，再用大车统一运输，时间没有少太多，但吞吐量完全不是一个量级。

6.2 ISR、副本和 acks，可靠性的三个齿轮

副本不是越多越好，关键是 Kafka 怎么判断一个 follower 是不是"跟得上"。Kafka 用 ISR（In-Sync Replica）集合来管理：ISR 里的副本，必须持续从 leader 同步数据，差距超过阈值就会被踢出去。

这里有三层配置联动：

• producer 的acks决定要等几个副本确认；
• broker 的min.insync.replicas决定 ISR 里至少要有几个副本；
• 副本因子replication.factor决定每个分区有几个副本。

打个比方，一个分区有 leader 和 2 个 follower，ISR=3，min.insync.replicas=2。假设一个 follower 扛不住被踢出 ISR，ISR 变成 2 个，此时写请求依然成功，因为 2 个节点满足最小同步副本要求；如果另一个节点也挂了，ISR 只剩 1 个，再写就会报NotEnoughReplicasException，宁可拒绝写入也不丢消息。

6.3 Leader 选举到底怎么选

一个分区的多个副本分为 leader 和 follower，读写全走 leader。那 leader 挂了选谁？答案是在 ISR 里选。

为什么强调 ISR？因为 ISR 里的副本已经和 leader 保持了同步，数据最全，选它不会丢消息。如果 ISR 里的副本都挂了，Kafka 会从"虽然不在 ISR 但还在线的副本"中挑一个，这时可能出现数据丢失，是无奈之下的恢复手段。节点间的协调由 Controller 负责，集群中会选出一个 Controller Broker，专门处理分区分配、副本变动这些元数据操作。

6.4 消费组重平衡的完整过程

重平衡的本质是"消费组成员变了，分区重新分配"。完整过程大致是：

• 消费者启动或退出时，向组协调者发送加入组请求；
• 协调者从组里挑一个消费者当 leader，把成员列表和订阅信息给它；
• leader 负责制定分配方案，把分区分给每个成员；
• 协调者把方案下发给所有成员，各自开始领取对应分区。

重平衡期间所有成员都会停止消费，所以它越频繁，系统吞吐就越差。面试时如果能补充"重平衡可能由消费者处理超时触发的吗？"并给出解决方案，会比单纯背流程加分。

6.5 从生产者到消费者，消息不丢失的完整链路

"如何保证 Kafka 消息不丢失"是面试高频题，答的时候必须覆盖整条链路：

• 生产者到 Broker：acks=all，让消息必须写进多个副本才算成功；同时开启重试和幂等，发送失败自动重发且不产生重复。
• Broker 内部：副本因子设 3，min.insync.replicas=2，容忍单机故障；刷盘策略保持默认，Kafka 靠副本同步保证持久性，而不是靠 fsync。
• Broker 到消费者：消费者关掉自动提交，处理完再手动提交 offset；处理动作要做幂等，防止重复消息带来脏数据。

三兄弟缺一不可：生产者不丢是源头，副本不丢是存储层，消费者不丢是末端兜底。少一个环节，"不丢失"就是一句空话。

我自己带新人时，最后总会说一句：Kafka 的 API 其实两小时就能学会，难的是把"消息丢失、重复消费、顺序错乱、延迟升高"这些概念内化成系统设计时的直觉。先搭一个单机版，写一段生产者、一段消费者，故意杀掉消费者进程看重复消费怎么发生，再用命令行工具盯一次 LAG 的变化，把这些场景亲手跑过一遍，比背十篇面试题都管用。