自测题库与面试检验

概念层（§6.1）

1. offset 由消费者维护，不是 broker。broker 只负责顺序追加日志、按时间/大小保留；"读到哪"是消费者自己提交到 __consumer_offsets 的一个数字。这个归属是后面一切的总开关——正因为进度在消费者侧、消息不因被读而消失，才有了可重放和多消费组各读各的。
2. 因为 Kafka 是日志不是队列：消费是移动游标（seek），不是出队（dequeue），游标前移不影响日志本身。记录何时消失只取决于保留策略（retention.ms / retention.bytes 到期删整段，或 compaction 对每 key 只留最新），与"是否被读过"完全解耦。所以消费滞后超过保留期会丢数据。
3. 顺序只在单个 partition 内保证，不保证 topic 全局有序。原因是物理的：全局总序需要一个单一写入点把所有记录串成一条序列，那就退回单分区、放弃了水平扩展。一条记录的完整坐标是 (topic, partition, offset) 三元组，跨分区的 offset 之间没有可比性。
4. 并行度上限 = partition 数。一个 partition 同一时刻只能被同组内一个 consumer 持有，所以消费者数超过分区数，多出来的就空闲拿不到分区；少于分区数则有消费者要扛多个分区。
5. 带 key 时 partition = murmur2(key) % 分区数——相同 key 永远算出同一分区，因此同 key 记录在该分区内有序。key 传 null 时用 sticky partitioner（先填满一个分区的 batch 再换），记录在分区间均摊，失去按 key 的顺序保证。
6. 不会漏。offset 是每个组各自维护的游标，互不影响。组 A 读到 100 不会"消耗"掉记录，11–100 号全都还在日志里（只要没超过保留期），组 B 会照常从 11 一路读下去。这正是"日志而非队列"最有用的一条性质：多消费组天然隔离。

原理层（§6.2）

1. LEO（Log End Offset） = 某个副本下一条要写的 offset（即该副本已有记录数）。HW（高水位） = ISR 中所有副本里最小的 LEO，也就是"已被所有同步副本复制到的最高 offset"。消费者只能读到 ≤ HW 的记录，是因为 HW 以上的记录还没被全部副本复制，一旦 leader 故障可能消失——HW 门控防止消费者读到"将来可能不存在"的记录。代价：HW 在下一轮 fetch 才推进，所以已 ack 给 producer 的记录要等约一个 RTT 才对消费者可见。
2. 不等于"所有副本"，等于"所有 ISR 成员"。当 follower 落后被踢出 ISR、ISR 收缩到只剩 leader 一台时，acks=all 就等价于 acks=1——写到一台就算"全部 ISR 确认"。所以持久性的真正来源是 min.insync.replicas（要求至少这么多 ISR 成员在线，否则写入被 NotEnoughReplicas 拒绝），不是 acks 本身。
3. follower 落后 leader 超过 replica.lag.time.max.ms（默认 30s）没追上，就被踢出 ISR。收缩后 ISR 成员变少，会影响 HW 的计算和 acks=all 的实际强度。follower 重新追上后会被加回 ISR。
4. eager：每轮再平衡所有成员放弃全部分区（stop-the-world 屏障），重新分配，期间整组暂停消费。cooperative/incremental（2.4+）：只放弃需要移动的分区，分两轮收敛，未变动的分区继续消费。后者解决了 eager 的全局暂停——大规模消费组扩缩容时，启动时间能从十几分钟降到约一分钟。KIP-848（4.0 GA）进一步把再平衡逻辑移到 broker 端、增量、无客户端 stop-the-world。
5. broker 为每个 (PID, partition) 维护一个最高序列号，只接受序列号恰好 +1 的 append；重试导致的重复（序列号已见过）被丢弃，出现空洞则抛 OutOfOrderSequenceException。它顺带解决乱序，是因为这套"必须连续 +1"的校验拒绝乱序 batch——所以 max.in.flight 可以 >1（≤5）而不会因重试打乱顺序。
6. 事务靠 transactional.id + epoch 隔离僵尸实例：transaction coordinator 跑两阶段提交，给每个涉及的分区写 commit/abort marker，并把输出写 + 消费 offset 提交放进同一个原子事务。read_committed 消费者跳过 aborted 和未决的记录、且不能越过 LSO（Last Stable Offset），从而只读到已提交事务的结果——这是 EOS 在读侧的兑现。代价：marker + LSO 带来额外延迟和队头阻塞（一个长事务未决会卡住 read_committed 读者）。
7. 因为存活由 poll() 证明，不是由心跳证明。心跳在后台线程，但它只说明"进程还活着、网络还通";真正的判活看你有没有在 max.poll.interval.ms 内再次调用 poll()。如果在 poll 循环里做了过重的处理（DB/HTTP）迟迟不回来 poll，协调者就判定这个成员处理不过来 = 死了，把它驱逐并触发再平衡，在途批次会在新 owner 上重复处理。
8. 因为 KRaft 把元数据本身做成一条日志（内部 topic __cluster_metadata，由 controller quorum 用 Raft 复制），standby controller 持续回放并把全部元数据常驻内存。所以 active controller 故障时，新 controller 的状态已经在内存里、几乎瞬时接管。ZooKeeper 模式下 controller 是独立系统，故障切换要全量重载元数据，分区一多就慢——这就是 KRaft 能支撑百万级分区、恢复更快的原因。代价：quorum 多数派挂掉就失去可用性。

应用判别层（§6.3）

1. 100 万/秒 + 可重放选 Kafka：它的顺序日志 + page cache + 零拷贝就是为高吞吐顺序流设计的，可重放是免费附赠（多消费组各读各的）。低吞吐 + 复杂逐条路由 + 重试/DLQ 选 RabbitMQ：Kafka 没有原生的逐条路由（exchange/binding）、没有内置的逐消息重试与死信队列、按分区粗粒度而非按消息精细 ack（share group 在弥补，但语义和成熟度不同）。判别的核心："高吞吐可重放的日志" vs "灵活路由 + 逐条投递控制的 broker"，是两种不同的工具，不是快慢之分。
2. 把 topic 设成单分区，所有消息走同一条日志即得全局总序。代价巨大：并行度被钉死为 1（一个组只能有一个消费者在干活），吞吐被单分区的单机磁盘和单消费者卡死，还失去了 Kafka 的核心扩展能力。所以面试时要主动说："能做，但等于放弃 Kafka 的全部并行优势——先反问业务是否真需要全局序，通常按 key 的分区内有序就够了。"
3. 至少三类：① 低吞吐 + 需要复杂路由（用 RabbitMQ 这类传统 broker）；② 需要内置逐条重试 / DLQ / 优先级队列（Kafka 都得自己造）；③ 请求-响应 / RPC 语义（Kafka 是单向日志，不是 RPC）。补充：小团队、量也不大却要扛 Kafka 的运维成本（分区规划、再平衡、监控）时，收益盖不过复杂度。判别要点：Kafka 的强项是高吞吐可重放日志，凡是和这条不沾边的需求都该重新考虑选型。
4. 因为每加一个消费者就触发一次再平衡；如果组本来就不稳定、或处理慢导致成员频繁被驱逐，就会陷入再平衡风暴——每次 stop-the-world（或部分暂停）期间消费停顿，lag 在停顿里堆积。更糟的情形是消费者数已经逼近或超过分区数，再加只是空转还白白触发再平衡。修：别在不稳定的组上扩容；上协作式再平衡 + static membership、调小 max.poll.records 把单批处理时间压在 max.poll.interval.ms 内；先确认分区数是否够，不够要先扩分区。
5. 相互拉扯的约束：① 目标吞吐（分区越多并行写/读越高）、② 消费并行度（消费者数 ≤ 分区数，要留够余量）、③ 顺序范围（同 key 必落同分区，分区数影响 key 分布）、④ 再平衡与故障切换成本（分区越多 controller/元数据负担、故障切换越慢、文件句柄越多）。定多了：抬高端到端延迟、故障切换时间、文件句柄耗尽（每 segment 2 个文件，默认 ulimit 1024）。定少了：消费并行度被卡死。之后难改：分区数只能增不能减，且给有 key 的 topic 加分区会永久打乱 key→分区映射、破坏所有下游的按 key 顺序——所以要么保守预估，要么新建 topic 迁移。
6. 这是热分区 / key 倾斜问题：userId 基数虽高，但单个大客户的流量全哈希到同一分区，压垮持有该分区的消费者。换 orderId 做 key 能缓解——orderId 基数更高、同一客户的订单会散到多个分区，负载更均匀；代价是失去"同一 user 的事件有序"（只剩同一 order 内有序），要确认业务能接受。Kafka 不会自动均衡倾斜——分配是按分区粒度，不看每分区的实际数据量。所以治本是选高基数、分布均匀的 key，而不是指望加消费者。