原理与设计取舍

这张图是本章的地图。后面六节各放大其中一块：§2.1 存储看 leader 那条日志在磁盘上长什么样；§2.2 分区与顺序看一条 topic 为什么要切成多个 partition；§2.3 副本与 ISR看 follower 的 fetch 如何决定"哪些数据对 consumer 可见";§2.4 消费组与再平衡看右边那个 consumer group 内部怎么分配分区；§2.5 投递语义看一条记录从写到读"恰好一次"到底意味着什么；§2.6 KRaft看底部那条元数据日志。

2.1存储原理：日志为什么快

每个 partition 是一个 append-only 文件序列，切成定长 segment、配稀疏索引，靠操作系统 page cache 和零拷贝把磁盘的顺序 I/O 跑到接近内存的速度。

运行方式

一个 partition 在磁盘上不是一个大文件，而是一串segment（日志段，由 log.segment.bytes 控制大小，默认 1GB）。任何时刻只有最后一个 active segment 在被追加写；写满就滚动出新的一个，旧的变成只读。每个 segment 旁边配两个索引文件：.index 把 offset 映射到该 segment 内的字节位置，.timeindex 把时间戳映射到 offset。两个索引都是稀疏的（不是每条记录都建索引，而是每隔几 KB 建一条），所以查一条记录是先二分索引定位到附近、再顺序扫一小段——O(log N) 定位而不是全文件扫描。

关键在于读写都是顺序 I/O：写永远是追加到文件末尾，读是从某个 offset 起连续往后。Kafka 不在 JVM 进程内缓存消息，而是直接依赖操作系统的 page cache——写入的数据先进 page cache（由 OS 异步刷盘），消费者读最近的数据时几乎总是直接命中 page cache，根本不碰磁盘。消费者读取走零拷贝（sendfile / FileChannel.transferTo()）：数据从 page cache 直接进网卡缓冲区，不经过 JVM 用户态——省掉了 "内核态→用户态→内核态" 的两次拷贝和上下文切换。

# topic "orders" 的分区 0 在 broker 数据目录下：
$ ls -lh /var/kafka-logs/orders-0/
00000000000000000000.log        # segment：实际记录（base offset = 0）
00000000000000000000.index      # 稀疏 offset→字节位置 索引
00000000000000000000.timeindex  # 稀疏 时间戳→offset 索引
00000000000000368912.log        # 下一个 segment，base offset = 368912
00000000000000368912.index
00000000000000368912.timeindex
leader-epoch-checkpoint         # leader 任期记录（截断时用，见 §2.3）

# 文件名 = 该 segment 第一条记录的 offset（base offset）。
# 查 offset 400000：文件名二分 → 落在 368912.log → .index 二分定位到附近字节 → 顺序扫到 400000。

保留策略有两种。默认是按时间/大小删整段（retention.ms / retention.bytes，到期把最旧的 segment 整个删掉）。另一种是 log compaction（日志压缩）：对每个 key 只保留最新一条 value，老版本被清理——把 topic 变成一份"可恢复的状态快照"。写一条 value 为 null 的记录叫 tombstone（墓碑），表示"这个 key 被删除"，compaction 在保留窗口后把该 key 连同墓碑一起清掉。__consumer_offsets（消费位移）和 Kafka Streams 的 changelog 就是靠 compaction 实现的——这也是第 1 章"日志可重放"能延伸成"日志可作状态存储"的机制。

备选方案对比

带来的代价 / 失效模式

2.2分区与顺序：并行和有序的同一个单位

partition 同时是顺序的单位和并行的单位——同一个 key 永远落同一个 partition（murmur2 哈希）因而有序，不同 partition 之间并行；顺序只在分区内成立。

运行方式

一条记录写到哪个 partition，由 producer 端决定。带 key 时：partition = murmur2(key) % 分区数——相同 key 永远算出同一个 partition，因此同一个 key 的记录在该分区内严格有序（同一订单的所有事件按写入顺序排好）。不带 key 时，3.0 以后默认用 sticky partitioner（KIP-480）：先把一个分区的 batch 填满再换下一个分区，而不是旧的 round-robin 逐条轮询。批越满，每批的固定开销摊得越薄，端到端延迟约减半。

这就是第 1 章里"顺序只在分区内保证"的机制根源：offset 是每个分区独立递增的序号，跨分区没有全局序。消费侧的并行度也由分区数决定——一个 consumer group 里，一个 partition 最多被一个消费者持有，所以消费者数超过分区数就有人闲置（详见 §2.4）。

带来的代价 / 失效模式

2.3副本与 ISR：持久性的真实来源

每个分区一个 leader 加若干 follower，follower 像消费者一样主动 fetch；HW（高水位）= ISR 中最小的 LEO，消费者只能读到 HW——已 ack 的记录未必立刻可见，而持久性来自 min.insync.replicas 不是 acks。

运行方式

每个分区有一个 leader 副本和若干 follower 副本。所有读写都走 leader；follower 主动向 leader fetch（和普通消费者用同一套 fetch 机制，只是 fetch 的是分区日志去复制）。两个关键水位：

• LEO（Log End Offset）：某个副本下一条要写入的 offset，也就是它当前日志的末尾。leader 的 LEO 总是最靠前，follower 的 LEO 落在后面（差着 fetch 的延迟）。
• HW（High Watermark，高水位）：ISR 集合里所有副本 LEO 的最小值，即"已经被所有同步副本完整复制到的最高 offset"。

消费者只能读到 ≤ HW 的记录。HW 之上、leader 已写但还没被所有 ISR 复制完的那段，对消费者不可见——因为那段一旦 leader 故障、由某个 follower 顶上，可能会消失。HW 这道门控保证消费者读到的都是"即使现在 leader 挂了也不会丢"的记录。

ISR（In-Sync Replicas，同步副本集）是当前跟得上 leader 的副本集合（含 leader 本身）。某个 follower 若超过 replica.lag.time.max.ms（默认 30s）没追上 leader 的末尾，就被踢出 ISR；追上后再加回来。ISR 是动态可变的——这是理解后面所有失效模式的关键。

acks 与 min.insync.replicas 的真实关系

producer 的 acks 决定"写入要等到什么程度才算成功":

• acks=0：发出去就算成功，不等任何确认——最快，leader 没写成也不知道，丢数据风险最高。
• acks=1：leader 写入本地日志就 ack——leader 写完、还没被任何 follower 复制就宕机，那些已 ack 的记录永久丢失。
• acks=all（即 acks=-1）：等到当前 ISR 里所有副本都复制完才 ack。

这里是面试最容易露馅的一点：acks=all 等的是"所有 ISR 成员"，不是"所有副本"。ISR 是会缩的——如果两个 follower 都掉队被踢出 ISR，ISR 只剩 leader 一个，此时 acks=all 实际只写到 leader 一台，悄悄退化成了 acks=1，下一次故障就丢。

真正的持久性闸门是 min.insync.replicas：它要求 ISR 至少有这么多成员在线，否则 producer 的写入直接被拒（收到 NotEnoughReplicas / NotEnoughReplicasAfterAppend）。所以持久性来自 min.insync.replicas，不是 acks——acks=all 负责"等所有 ISR"，min.insync.replicas 负责"ISR 不许缩到不安全"。两者必须配合：典型生产配置是 replication.factor=3 + min.insync.replicas=2 + acks=all，含义是"至少 2 个副本拿到才算写成功，否则宁可拒写"。这套组合留到 §4.1 数据丢失里逐条对照。

带来的代价 / 失效模式

2.4消费组与再平衡：分区如何分配，成员如何被判死

broker 端的 group coordinator 通过 JoinGroup/SyncGroup 把分区分给组内消费者；再平衡协议从 eager（全停）演进到 cooperative（只动该动的）再到 KIP-848（broker 端驱动），而成员存活由 poll() 证明、不是心跳。

运行方式

每个 consumer group 由 broker 端一个 group coordinator 管理。新成员加入或老成员离开时触发再平衡，分两步：JoinGroup（所有成员向 coordinator 报到，coordinator 选出其中一个当 group leader）→ SyncGroup（group leader 在客户端算出"谁拿哪些分区"的分配方案，回传给 coordinator 下发）。注意分配逻辑跑在客户端的 group leader 上，broker 不关心用什么策略分——这让分配策略可插拔。

消费位移（offset）提交到内部 topic __consumer_offsets（一个 compaction 的 topic，每个 (group, topic, partition) 只保留最新 offset）。提交可以自动（enable.auto.commit，按 auto.commit.interval.ms 定时）或手动（commitSync() / commitAsync()）。

成员存活判定有两条独立的线，这是最容易混淆的地方：

• 后台心跳线程按 heartbeat.interval.ms 给 coordinator 发心跳，session.timeout.ms 内没心跳就判死——这检测的是"进程/网络是否还活着"。
• 但真正证明"消费者还在干活"的是调用 poll()。两次 poll() 间隔超过 max.poll.interval.ms（默认 5 分钟），coordinator 判定这个成员卡死，把它踢出组触发再平衡——即使它的心跳线程还在后台正常跳。

三代再平衡协议

eager（急切式）：每次再平衡，所有成员先放弃全部分区（一个 stop-the-world 屏障），等新分配下来再重新认领。简单、分配干净，但再平衡期间整个组停止消费。

cooperative / incremental（协作增量式，2.4+）：遵循"没必要动的资源不要停"——只收回需要转移的那部分分区，没变动的分区继续消费；分两轮收敛。

KIP-848（4.0 GA）：把再平衡逻辑从客户端移到 broker 端，由 coordinator 增量驱动，不再有客户端侧的全局屏障，加入/退出更平滑。经典 eager 协议计划在 5.0 移除。

static membership（静态成员，KIP-345）：给消费者配一个固定的 group.instance.id。配了之后，成员短暂重启（如滚动发布）能认领回原来的分区而不触发再平衡——把"重启"和"成员变更"解耦。

带来的代价 / 失效模式

2.5投递语义：幂等、事务与 EOS 的真实边界

at-least-once 是默认；幂等 producer 用 (PID, 分区) + 序列号在 broker 端去重并强制保序；事务用 transactional.id + epoch 把"输出写 + offset 提交"做成原子——但 exactly-once 只在 Kafka 闭环内、且幂等只在同一会话同一分区成立。

三种语义的来源

• at-most-once（至多一次）：先提交 offset 再处理。处理崩了 offset 已提交，这条不会重投——但也可能丢。
• at-least-once（至少一次，默认）：先处理再提交 offset。处理完崩在提交前，重启会重投这条——不丢，但可能重复。
• exactly-once（精确一次）：靠幂等 producer + 事务达成，且只在特定边界内成立（见下）。

幂等 producer：PID + 序列号

开启 enable.idempotence=true（4.0 起默认开）后，每个 producer 会话拿到一个 PID（Producer ID）。producer 给发出的每条记录按 (PID, 分区) 维度打一个单调递增的序列号。broker 为每个 (PID, 分区) 记住"已接受的最高序列号",只接受序列号恰好 +1 的 append：

• 收到重复的序列号（重试导致的重发）→ 直接丢弃，去重。这解决"broker 写成功但 ack 在网络上丢了、producer 重发"导致的重复。
• 收到有空洞的序列号（比预期跳号）→ 抛 OutOfOrderSequenceException。

因为只接受恰好 +1，幂等 producer 顺便强制了顺序：它会拒绝乱序到达的 batch，所以同时解决了"max.in.flight.requests > 1 时重试导致消息乱序"这个老问题（幂等下 in-flight 可达 5 仍保序）。

事务：transactional.id + epoch + 两阶段提交

幂等只覆盖单个 producer 会话、且只去重不跨"多分区写 + offset 提交"。事务（配 transactional.id）补上这两块：

• 跨重启的身份与僵尸隔离：transactional.id 是稳定的（重启不变），每次初始化会把 epoch 加一。旧实例（僵尸）带着旧 epoch 再来写会被拒——避免"以为死了其实没死"的旧进程污染数据。
• 原子的"输出 + offset"：transaction coordinator 跑两阶段提交，给事务涉及的每个分区写一个 commit / abort marker。"消费-转换-生产"里，把下游输出和上游 offset 提交放进同一个事务——要么都成功，要么都回滚，不会出现"输出写了但 offset 没提交"导致的重复。
• 读侧配合：消费者设 isolation.level=read_committed 后，会跳过 aborted 和未决事务的数据，且读取不能越过 LSO（Last Stable Offset，最后稳定位移）——即最早的未决事务之前的位置。

// "消费 → 转换 → 生产" 的 EOS 闭环：输出写 + 上游 offset 提交在一个事务里
Properties p = new Properties();
p.put("transactional.id", "order-enricher-1");   // 稳定 ID，重启不变 → epoch 隔离僵尸
p.put("enable.idempotence", "true");              // 事务隐含开启幂等
KafkaProducer<String, String> producer = new KafkaProducer<>(p);
producer.initTransactions();                       // 领 PID、把 epoch +1，挤掉僵尸旧实例

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(200));
    producer.beginTransaction();
    try {
        for (ConsumerRecord<String, String> r : records) {
            producer.send(new ProducerRecord<>("orders-enriched", r.key(), enrich(r.value())));
        }
        // 关键：上游 offset 也写进同一个事务，而不是 consumer.commitSync()
        producer.sendOffsetsToTransaction(offsetsOf(records), consumer.groupMetadata());
        producer.commitTransaction();              // 写 commit marker，原子生效
    } catch (KafkaException e) {
        producer.abortTransaction();               // 写 abort marker，read_committed 端跳过
    }
}

带来的代价 / 失效模式

2.6KRaft：元数据本身也是一条日志

集群元数据被建模成一条内部日志 __cluster_metadata，由 controller quorum 用 Raft 复制；active controller 是唯一写入者，其余节点回放日志并把元数据全量驻留内存——故障切换几乎瞬时，不再需要 ZooKeeper。

运行方式

4.0（2025-03）起，Kafka 彻底移除了 ZooKeeper，KRaft 成为唯一的元数据模式（不是可选项）。它的核心思路非常 Kafka：把元数据也当成一条日志。集群的所有元数据（有哪些 topic、分区分布、ISR、配置……）记录在一个内部的、单分区的 topic __cluster_metadata 里，由一组 controller 组成的 quorum 用 Raft 协议复制。

其中一个 controller 是 active controller，是元数据日志的唯一写入者;其余 controller 作为 standby 回放这条日志、把最新元数据全量驻留在内存。这样当 active controller 故障时,某个 standby 接管几乎是瞬时的——它的内存里已经是最新状态,不需要从外部系统重新加载。这正好呼应第 1 章的本质命题:连"管理集群"这件事,Kafka 都用它自己的"日志"原语来解。

带来的代价 / 失效模式

2.7把六个机制串起来：一条记录的一生

前六节各讲一个机制。但生产里它们是协同工作的——理解协同,才算真的理解。跟一条记录走完"producer 写入 → follower 同步 → HW 推进 → consumer 读取"这条链,看每一步踩在哪个机制上。

逐步拆解,注意每一步的"如果失败会怎样":

• ① producer 写(§2.2 + §2.5):记录按 murmur2(key) % 分区数 选定分区,带着幂等序列号发给该分区的 leader,acks=all 表示要等所有 ISR 确认。若 key 选得差 → 热分区倾斜;若没开幂等 → 重试可能乱序或重复。
• ② leader 追加(§2.1):leader 把记录顺序追加到 active segment 末尾,进 page cache,LEO +1。这一步是 O(1) 顺序写。
• ③ follower fetch(§2.3):ISR 里的 follower 各自 fetch 这条记录、写入自己的日志、推进自己的 LEO。若某 follower 掉队超过 replica.lag.time.max.ms → 被踢出 ISR,不再参与 HW 计算。
• ④ HW 推进 + ack(§2.3):当 ISR 里所有副本的 LEO 都越过这条记录,HW 推进;此时若在线 ISR 数 ≥ min.insync.replicas,producer 收到成功 ack。若 ISR 缩到不足 → producer 收到 NotEnoughReplicas、写被拒(而不是悄悄降级)。
• ⑤ consumer 读(§2.4):consumer poll() 拉取,只能看到 ≤ HW 的记录;处理完按 at-least-once 提交 offset 到 __consumer_offsets。若处理超过 max.poll.interval.ms 没再 poll() → 被判死、分区转移、这批被重复处理。