核心概念：把 Kafka 当成一条日志

1.1为什么需要 Kafka：队列删一次，日志读多次

传统 MQ 把消息当"消费一次就丢"的任务；Kafka 把消息当"写进日志、谁都能重读"的事实。

底层机制（比文档深一层）

这两类系统的分水岭不在"快慢"，而在谁持有消费进度、消息何时消失。传统 MQ 把"已读到哪"作为 broker 的内部状态，消息的生命周期绑定在"是否被 ack"上——ack 即删除，进度无法回退。Kafka 反过来：broker 只负责把记录顺序追加进日志、按时间或大小（而非"是否被消费"）做保留，消费进度 offset 是消费者自己提交的一个数字。把"进度"从 broker 搬到消费者这一侧，是后面一切特性的总开关：消息不再因被读而消失，于是可重放；多个消费者各存各的 offset，于是同一份数据能被独立消费多次。

场景走查

一个订单系统每秒产生几千条"订单已创建"事件。用删除式队列：风控消费完一条就被删，数仓再想读同一条已经没了，只能各开一个队列、生产者发三遍。用 Kafka：事件写进 orders 这一条日志一次，风控、数仓、推荐三个独立消费组各自维护 offset、各读各的；某天推荐算法改版要重算上周数据，把它的 offset 重置到 7 天前再跑一遍即可——日志还在，重放不需要生产者配合。

与下一个概念的关系：把"进度归消费者、读完不删"这件事讲到底，就必须看清这条"日志"在物理上长什么样——它就是下一节的提交日志模型。

1.2提交日志模型：append-only + offset

记录只能追加到日志末尾、永不修改，每条带一个单调递增的 offset；消费就是按 offset 顺序移动一个读游标。

底层机制（比文档深一层）

offset 不是"消息 ID"，而是记录在这条日志里的位置序号——从 0 开始，每追加一条 +1，分区内永不重复、永不回退。这个设计带来三个直接后果：

• 写入是 O(1) 顺序追加：永远只往 active 日志段的尾部写，不需要像 B 树那样随机寻址、加锁、再平衡。顺序磁盘 I/O 接近内存速度，这是 Kafka 高吞吐的物理根源（机制细节见 §2.1 存储）。
• 读取是"从 offset N 开始往后给记录"：消费者发来一个 offset，broker 从那个位置往后顺序吐数据。读不破坏写、也不互相干扰，因为各消费者只是停在日志不同位置的游标。
• 读完不删：游标前移不影响日志本身。记录何时消失只取决于保留策略，与"是否被读过"完全解耦。

这正是起点页那句"门槛"心智模型的落点：消费不是出队（dequeue），是移动游标（seek）。一旦接受这一点，"为什么消息读完还在""为什么能从头重放""为什么 offset 在消费者手里"就不再是需要单独记忆的知识点，而是同一个结构的必然推论。

场景走查

消费者 poll 一批记录、处理完、把 offset 5 提交到 broker；进程崩溃重启后，它向 broker 要"从 offset 5 之后的记录"，于是从 6 继续，不重不漏。如果它在崩溃前没来得及提交 offset，重启会从上次提交的位置（比如 3）重新拉，4、5 被重复处理——这把"提交时机"变成正确性问题，留到 04 章展开。

与下一个概念的关系：到这里"日志"还是一条。但单条日志只有一个写入点、无法水平扩展。下一节看 Kafka 怎么把一条逻辑日志切成多条物理日志——这就是 topic / partition / offset。

1.3Topic / Partition / Offset：顺序只在分区内

topic 是逻辑分类，物理上切成 N 个 partition，每个 partition 是一条独立有序的日志，offset 是分区内的位置。

底层机制（比文档深一层）

关键的、面试最爱考的一点：Kafka 只保证单个 partition 内有序，不保证 topic 全局有序。原因是物理的——全局有序需要一个单一写入点把所有记录串成一条序列，那就等于退回单分区、放弃了扩展性。所以 offset 是分区内的位置序号：partition 0 有它自己的 0,1,2…，partition 1 也有自己的 0,1,2…，两个分区的"offset 5"毫无关系。一条记录的完整坐标是 (topic, partition, offset) 三元组，而不是单个 offset。

这意味着：需要保证先后顺序的记录（比如同一个订单的"创建→支付→发货"）必须落进同一个 partition，否则它们分散在不同分区、消费端无法保证读到的先后。怎么让它们落同一分区？靠 key——这是 §1.4 的事。

场景走查

orders topic 切成 4 个 partition。生产者用 orderId 作 key，于是 order-42 的所有事件（创建、支付、发货）都哈希到同一个 partition，消费端读这个分区时它们必然按写入顺序到达。而 order-42 和 order-99 可能落在不同分区——它们之间没有顺序保证，这通常也无所谓，因为两笔订单本就互不相关。"只在需要顺序的范围内保证顺序"是 Kafka 的核心权衡。

与下一个概念的关系：分区解决了"日志怎么切"，但还没说"谁来写、谁来读、怎么把 N 个分区分给多个消费者并行处理"。这是 producer / consumer / consumer group。

1.4Producer / Consumer / Consumer Group：并行单位 = 分区数

producer 按 key 选分区写入；一个 consumer group 内每个 partition 只分给一个 consumer；不同 group 各自独立消费同一份数据。

底层机制（比文档深一层）

分配的铁律：一个 partition 在同一时刻只能被同一个 consumer group 里的一个 consumer 消费。由此推出 Kafka 并行度的硬上限——一个组的有效并行度 = partition 数。组里消费者比分区多，多出来的就空闲拿不到分区；比分区少，则有消费者要扛多个分区。这是规划分区数时第一个要算的约束。

"谁拿哪个分区"由一个叫再平衡（rebalance）的过程决定：成员加入/退出时重新分配分区。再平衡的代价、协议演进（eager 急切式 vs cooperative 协作增量式）是 §2.4 的重头戏，这里只需知道它存在、它在成员变动时触发。另一条正交的线：不同的 consumer group 读同一个 topic 完全独立——各存各的 offset、各按各的进度，互不影响（图 1.1 已画过两个组停在不同 offset）。

一个 ProducerRecord 长什么样

生产者发出去的不是一个裸字符串，而是一个带 key 的 ProducerRecord。key 决定它落进哪个分区——这是把"需要顺序的记录"钉在同一分区的方式：

// 第 1 个参数 = topic，第 2 个 = key，第 3 个 = value
// key = orderId：同一订单的所有事件哈希到同一 partition，于是有序
var record = new ProducerRecord<>("orders", order.getId(), order.toJson());
producer.send(record);   // 异步追加到该 key 对应 partition 的日志尾部

消费侧的 poll 循环长什么样

消费者不是被 broker"推"消息，而是自己循环 poll（拉）。这把消费节奏的控制权交给消费者，是它能管自己 offset 的前提：

consumer.subscribe(List.of("orders"));   // 加入消费组，由再平衡分到若干 partition
while (running) {
    var records = consumer.poll(Duration.ofMillis(500));  // 主动拉一批
    for (var r : records) {
        handle(r.value());                // 处理记录
    }
    consumer.commitSync();                // 处理完再提交 offset（先处理后提交 = 至少一次）
}

与下一个概念的关系：producer 和 consumer 都在跟"partition"打交道，但 partition 的副本到底存在哪台机器上、读写打到哪个副本？这是 broker / cluster / replica。

1.5Broker / Cluster / Replica：日志被复制到多台机器

broker 是 Kafka 服务进程，一个 partition 有 1 个 leader + 若干 follower 副本，分布在不同 broker 上。

底层机制（比文档深一层）

同一个 partition 的多个副本里，有且只有一个是 leader，其余是 follower。机制的关键点：

• 所有读写都只打 leader，follower 不直接对外服务——它们像消费者一样主动从 leader拉取（fetch）新记录，把 leader 的日志复制到自己这里。这保证了所有副本回放的是同一条日志、顺序一致。
• 副本分布在不同 broker 上，所以一台 broker 宕机时，它上面那些 partition 的 leader 角色会切换到别的 broker 上的 follower，服务继续。
• follower 并非总能跟上 leader。Kafka 用一个叫 ISR（同步副本集）的集合追踪"哪些副本目前跟得够紧"，并用 HW（高水位）控制消费者能读到哪一条——这两个机制决定了"持久性"和"消费者可见性"的边界，是 §2.3 的核心，详见 02 章，本章不展开。

场景走查

orders 的 partition 0 配了 3 个副本（replication.factor=3），分别在 broker-1、broker-2、broker-3，leader 在 broker-1。生产者发往 partition 0 的记录都写到 broker-1，broker-2/3 上的 follower 持续 fetch 跟上。broker-1 突然宕机：集群从 broker-2/3 的 follower 里选一个当新 leader，生产和消费切到新 leader 继续——读者侧几乎无感。这就是副本机制：它复制的不是别的，正是那条 partition 日志。

与下一个概念的关系：从宏观（集群、副本）回到微观——日志里那一条"记录"本身到底由什么组成？key 除了路由还管什么？这是最后一个概念 Record。

1.6Record：key / value / headers / timestamp

日志里的一条记录由 key、value、headers、timestamp 组成；key 同时决定分区路由与 compaction 行为。

底层机制（比文档深一层）

一条 record 的四个部分：

• value：消息体本身（订单 JSON、事件 payload）。
• key：路由依据。有 key → murmur2 哈希到固定分区，相同 key 永远同分区（顺序保证的来源）；key 为 null → 由 sticky partitioner 在分区间均摊（机制见 §2.2）。
• headers：键值对元数据（如 trace-id、schema 版本、来源系统），不影响路由，供消费端按需读取。
• timestamp：记录的时间戳（生产时间或日志追加时间），是按时间检索、按时间保留的依据。

key 的第二重身份在日志压缩（log compaction）里：开启压缩的 topic 会对每个 key 只保留最新那条 value，旧值被回收；发一条 value 为 null 的记录（称为 tombstone 墓碑）则表示"这个 key 删除了"。于是一个压缩 topic 就成了"每个 key 的最新状态"的快照——这是 Kafka 能给一张表当 changelog、能存消费组 offset 的底层原理。压缩的具体机制（何时触发、tombstone 何时清）留给 §2.1。

场景走查

用户资料 topic 以 userId 为 key、开启 compaction。用户改了三次昵称，日志里一度有三条记录；压缩后只剩最新那条。新启动的服务从头读这个 topic，就能重建"每个用户的当前资料"全量快照，不必读完整个历史。注销用户时发一条 userId + null 的 tombstone，压缩后这个 key 彻底消失。同一个 key 既决定路由、又定义"同一实体"——这就是 key 的双重身份。