阅读目标#

学完本篇，你不应该只会复述“Kafka 是一个高吞吐消息队列”，而应该能够从以下四个核心抽象重新推导 Kafka：

• Log：事件不是等待被取走的任务，而是已经发生并被记录的事实；
• Partition：单条 Log 无法无限扩展，因此需要把日志切分成多个独立有序分片；
• Offset：消费者不是拥有消息，而是通过位置读取日志；
• Consumer Position：事件数据与消费进度分离，同一份数据可以形成多个互不干扰的消费视角。

本文以 Apache Kafka 4.3 文档为基线。Kafka 官方将其定义为一个分布式事件流平台：它能够跨多台机器发布、读取、持久保存和处理事件。Kafka 4.x 的集群管理主线已经是 KRaft，而不是 ZooKeeper。1

0. 一条订单为什么拖垮了整个系统#

先不谈 Kafka。

假设我们正在开发一个订单系统。用户提交订单后，订单服务需要完成订单落库、库存锁定、风控检查、积分计算和通知发送：

1
public void createOrder(Order order) {
2
    orderRepository.save(order);
3
    inventoryService.lock(order);
4
    riskService.check(order);
5
    pointService.calculate(order);
6
    notificationService.send(order);
7
}

在业务规模很小时，这段代码直观、简单，调用路径也容易追踪。但随着系统增长，问题会迅速出现：

• 通知服务响应 3 秒，订单接口是否也必须多等待 3 秒？
• 风控服务短暂不可用，用户是否就不能创建订单？
• 积分服务处理能力只有订单服务的五分之一，峰值流量如何消化？
• 如果以后增加推荐、数据仓库、审计和 Agent 平台，订单服务是否每次都要修改？

表面上看，这是一个“同步调用比较慢”的问题；但更深层的问题是：订单服务被迫知道订单创建之后整个世界需要做什么。

这意味着系统已经形成了多种耦合。

1.1 时间耦合：调用双方必须同时在线#

同步 RPC 的基本模式是：

1
A 发起请求 → B 处理请求 → B 返回响应 → A 继续执行

A 能够继续执行的前提是：

1. B 此刻必须在线；
2. B 此刻必须能够及时响应；
3. A 必须在调用期间持续等待 B。

因此，A 与 B 被绑定在同一个时间窗口中，这就是 Temporal Coupling，时间耦合。

以订单通知为例，“订单已经创建”和“短信已经发送”并不是同一个业务原子动作。订单已经成功落库后，即使短信平台暂时故障，订单事实本身也不应该消失。可是，在同步调用链中，订单请求却可能因为一个非核心下游服务而超时。

从业务语义看，我们真正希望表达的是：

1
订单已经创建。
2
至于谁关注这个事实、何时处理这个事实，由各自系统决定。

1.2 可用性耦合：下游故障会向上游传播#

假设调用链为：

1
Order → Inventory → Risk → Notification

只要其中一个强依赖不可用，整条链路就可能失败。即便每个服务都拥有较高可用性，串联之后的端到端可用性仍会下降。

更危险的是故障传播：

1
通知服务变慢
2
    ↓
3
订单线程长时间等待
4
    ↓
5
订单服务线程池被占满
6
    ↓
7
新请求无法进入
8
    ↓
9
故障从边缘服务扩散到核心交易链路

因此，同步依赖不仅连接了业务功能，也连接了不同服务的故障域。

1.3 扩缩容耦合：上游速度直接传递给下游#

假设订单服务突然收到 10,000 TPS：

1
10,000 次库存调用
2
10,000 次积分调用
3
10,000 次通知调用

如果通知系统每秒只能处理 2,000 个请求，它没有缓冲空间，只能通过超时、拒绝或排队把压力反向传给订单服务。

同步模型隐含了一个危险条件：

1
上游发送速度必须长期小于等于下游实时处理能力。

否则，速度较慢的一方会成为整条链路的瓶颈。

1.4 变化耦合：上游需要不断认识新的下游#

最初，订单服务只需要调用库存服务。后来业务不断增加：

1
Order Service
2
 ├── Inventory
3
 ├── Risk
4
 ├── Coupon
5
 ├── Points
6
 ├── Notification
7
 ├── Data Warehouse
8
 ├── Recommendation
9
 └── Agent Platform

每新增一个“订单创建后的关注者”，订单服务都要增加依赖、修改代码、补充异常处理和重新发布。

此时，订单服务已经不再只负责订单，它还承担了业务流程编排中心的职责。

所以，大型系统引入消息机制的根本原因，并不只是“异步更快”，而是要解开：

事件发生者与事件关注者之间的时间、可用性、速度和变化关系。

2.1 从直接命令转向事实事件#

先区分两个容易混淆的概念：Command 与 Event。

1
SendOrderCreatedSMS(orderId)
2
ReserveInventory(orderId)
3
CalculatePoints(orderId)

1
OrderCreated(orderId)
2
PaymentCompleted(orderId)
3
OrderShipped(orderId)

1
Order Service 发布 OrderCreated
2
               │
3
      ┌────────┼─────────┬─────────┐
4
      ↓        ↓         ↓         ↓
5
 Inventory   Points   Notification  Analytics

2.2 消息系统创建了一个时间缓冲区#

加入消息系统后，生产者与消费者不再要求同时工作：

1
Producer → Message Buffer → Consumer

假设生产速度短时达到 10,000 msg/s，而消费者只能处理 3,000 msg/s。消息系统可以先保存尚未处理的数据，消费者随后以自己的速度追赶。

因此，“削峰填谷”的本质并不是流量凭空消失，而是：

消息系统在两个速度不同的系统之间创建了一个时间缓冲区。

短期峰值被转化为积压；消费者获得时间处理积压；核心请求不必等待非核心动作同步完成。

不过，这里也必须保持警惕：缓冲区不能解决长期的生产消费能力倒挂。如果生产速度长期高于消费速度，积压仍会无限增长。Kafka 的消费者容量规划与 Lag 治理将在第七篇展开。

2.3 Broker 第一次出现#

最简单的消息架构是：

1
Producer → Broker → Consumer

Broker 位于生产者和消费者之间，负责接收、保存并提供消息。

但是，“Broker 中究竟保存什么”，决定了消息系统最终形成怎样的世界观。接下来，我们先看最符合直觉的 Queue。

3.1 Queue 把消息看成等待处理的任务#

最简单的队列模型是：

1
Producer: enqueue(message)
2
Consumer: dequeue()

消息从尾部进入，从头部被消费者取出。它所表达的核心语义是：

一项任务正在等待某个消费者处理。

消费流程通常被理解为：

1
Message → Deliver → Process → ACK → Completed

因此，Queue 主要关注的是 Message Delivery：

• 消息有没有投递给消费者？
• 消费者有没有确认处理？
• 处理失败后是否重新投递？
• 如何避免同一条消息同时交给多个竞争消费者？

3.2 多个消费者之后：竞争消费与发布订阅#

当多个消费者共同处理同一种任务时，可以形成竞争消费：

1
[M1][M2][M3][M4]
2
   ↓       ↓
3
Consumer A  Consumer B

每条消息由其中一个消费者处理，用于提高任务处理并行度。

但如果库存、通知、风控和数据仓库都要接收 OrderCreated，就需要发布订阅：同一个事件需要被多个逻辑订阅者独立观察。

传统消息中间件同样可以支持这些模式，Kafka 也不是唯一实现方式。真正让 Kafka 的模型发生变化的，是它对另一个问题的回答。

3.3 为什么消息一定要“被取走”#

假设系统已经处理过以下事件：

1
10:00 OrderCreated
2
10:01 PaymentCompleted
3
10:05 OrderShipped

此时出现几个需求：

• 数据仓库今天才上线，希望重新导入昨天的订单；
• 风控算法升级，希望重新计算过去七天的风险；
• 消费者代码存在 Bug，修复后需要重放过去一小时的数据；
• 新增一个 Agent 分析服务，希望从历史事件中重建 Case 状态。

如果消息一旦成功消费就被理解为“任务完成并从系统中消失”，这些需求都需要额外的历史存储、复制链路或补数机制。

于是，一个更根本的问题出现了：

消息为什么必须被理解成等待领取的任务？它能不能被理解成已经发生、应当被记录的事实？

Queue 的核心问题是：

1
这条消息应该交给谁？是否已经完成？

Log 的核心问题则是：

1
这份历史仍然存在；每个消费者读到哪里？

这就是理解 Kafka 的转折点。

4.1 Append-only Log#

最简单的 Log 是一个只能在尾部追加的有序记录序列：

1
Offset
2
  0      1      2      3      4      5
3
  │      │      │      │      │      │
4
 [E0] → [E1] → [E2] → [E3] → [E4] → [E5] → append here

每次出现新事件，系统不是寻找一个可覆盖位置，也不是把旧记录弹出，而是在日志尾部追加新的 Record。

这种结构包含三个重要性质：

1. 有序：记录按照写入顺序排列；
2. 追加：新数据主要在尾部增加；
3. 持久：消费者读取数据并不要求数据立即删除。

Kafka 官方设计中，一个 Topic 会被拆成多个有序 Partition；Consumer 在每个 Partition 上的位置可以用一个整数 Offset 表示，即下一条准备消费的记录位置。2

4.2 Queue 与 Log 的根本差异#

可以用一句话概括两者关注点：

Queue 的问题是“这条消息交给谁”，Log 的问题是“你读到哪里”。

Queue 往往围绕消息本身维护状态：等待投递、已投递、已确认、重新投递。

Log 则将数据状态与消费状态分离：日志只负责保存事件；消费者只负责记录自己在日志中的位置。

4.3 数据与消费进度分离#

假设日志包含 0～9 共十条事件：

1
0 1 2 3 4 5 6 7 8 9
2
───────────────────→

三个消费者可以拥有三个完全不同的位置：

1
Risk Consumer       position = 8
2
Warehouse Consumer  position = 5
3
Agent Consumer      position = 2

日志数据没有因为某个消费者读取而改变；一个消费者处理较慢，也不会迫使另一个消费者回退。

由此得到 Kafka 极其重要的抽象：

1
Event Data ≠ Consumer Progress

这看似只是把状态拆开，实际上改变了整个消息系统的能力边界。

4.4 Consumer 不拥有消息#

在典型 Queue 直觉中，消费者“拿走”了一条消息。

在 Log 直觉中，消费者只是发起如下读取：

1
fetch(partition=P0, offset=100)

Broker 返回从该位置开始的一批记录。消费者处理后，把自己的位置向前推进。

Kafka 官方设计强调，Consumer 可以控制自己的 Position，并能回退到旧 Offset 重新消费历史数据。2

因此，Consumer 与 Event 的关系不是所有权转移，而是：

1
消费者在一个持久有序的数据集合上移动读取位置。

4.5 Replay 不是附加功能，而是核心抽象的自然结果#

假设消费者已经读到 Offset 1000，后来发现 900～1000 的处理代码有 Bug：

1
0 ........ 900 ........ 1000
2
           ↑               ↑
3
        replay from      current

修复代码后，只要把消费位置重新调整到 900，就能再次读取这段事件。

Replay 来自两个基础条件：

1
Persistent Log
2
+
3
Movable Consumer Position

它并不是在传统 Queue 上额外添加的复杂补丁，而是 Log 模型自然产生的能力。

这体现了一个重要的架构原则：

优秀系统的高级能力，往往不是不断追加 Feature，而是由正确的核心抽象自然推导出来。

4.6 Kafka 应该如何定义#

到这里，我们可以先给 Kafka 一个底层定义：

Kafka 可以首先被理解为一个分布式、持久化、允许消费者按位置读取的事件日志系统。

这个定义用于建立 Mental Model，但它还不是 Kafka 产品能力的全部。Kafka 官方对它更完整的定义是“分布式事件流平台”，因为它不仅保存事件，还提供 Producer、Consumer、Streams、Connect、Admin 等能力。1

理解顺序应该是：先用 Log 看清底层抽象，再把 Kafka 看成构建在该抽象之上的完整 Event Streaming Platform。

5.1 假设 Topic 只有一条全局 Log#

假设所有订单事件都写入一条日志：

1
Order Events
2
0 → 1 → 2 → 3 → 4 → ... → 100000000

所有 Producer 竞争同一个写入路径，所有数据存放在同一台机器，所有 Consumer 又希望保持全局顺序。

这个模型很快遇到四个限制。

5.2 Partition 是独立有序的 Log#

Kafka 把一个 Topic 拆成多个 Partition：

1
Topic: order-events
2
 ├── Partition 0: 0 → 1 → 2 → 3
3
 ├── Partition 1: 0 → 1 → 2
4
 └── Partition 2: 0 → 1 → 2 → 3 → 4

每个 Partition 都是一条独立有序日志，并拥有自己的 Offset 空间。

这里必须牢牢记住：

1
Offset 的作用域是 Partition，而不是整个 Topic。

正确坐标不是：

1
order-events 的 offset=100

而是：

1
TopicPartition(order-events, 0), offset=100

5.3 Partition 是 Kafka 的 Scale Unit#

Partition 可以分布到不同 Broker：

1
P0 → Broker 1
2
P1 → Broker 2
3
P2 → Broker 3

于是，一个 Topic 的数据和负载可以横向分布到多台服务器。

Kafka 官方运维文档明确指出，Partition 数决定 Topic 被切分为多少条 Log，也影响数据能够分布到多少服务器以及 Consumer 的最大并行度。3

因此，Partition 同时承担多个角色：

• 存储分片单位：不同 Partition 能分布到不同 Broker；
• 写入并行单位：Producer 可以同时写多个 Partition；
• 读取并行单位：不同 Consumer 可以并行读取不同 Partition；
• 顺序边界：Kafka 保证的是 Partition 内顺序，而不是 Topic 全局顺序。

5.4 Partition 不是免费的性能优化#

假设两个 Partition 分别包含：

1
P0: A → C → E
2
P1: B → D → F

我们只能确认：

1
P0 内 A 在 C 前，C 在 E 前；
2
P1 内 B 在 D 前，D 在 F 前。

但无法仅凭 Kafka Partition 顺序推导全局序列一定是：

1
A → B → C → D → E → F

因此，Partition 做出了一个架构交换：

1
放弃 Topic 全局顺序
2
        ↓
3
获得水平扩展与并行能力

Partition 不是免费的性能优化，而是 Kafka 在“全局顺序”和“水平扩展”之间做出的架构选择。

5.5 Key 用于建立局部顺序#

实际业务往往不要求所有订单全局有序，只要求同一个订单的事件有序：

1
Order 1001 Created
2
Order 1001 Paid
3
Order 1001 Shipped

Producer 可以把 orderId 作为 Key：

1
hash(orderId) → Partition

相同 Key 通常会被映射到同一个 Partition，从而形成 Key 范围内的局部顺序：

1
Order1001 → P3
2
Order1001 → P3
3
Order1001 → P3

不过，Partition 数量变化可能改变 Key 到 Partition 的映射。Kafka 4.3 官方运维文档也提醒：如果分区逻辑依赖 hash(key) % partitionCount，增加 Partition 后，相同 Key 的后续消息可能进入不同 Partition，进而影响既有顺序假设。3

这一问题涉及 Topic 设计、Partition 扩容和容量治理，将在第七篇深入讨论。

5.6 Topic 到底是什么#

现在可以给 Topic 一个更准确的定义：

Topic 是一个逻辑事件流名称，其底层由一个或多个独立的 Partition Log 组成。

Topic 负责业务语义分类；Partition 负责物理切分、并行和局部顺序；Offset 负责定位 Partition 中的位置。

三者不能混为一谈。

6.1 Offset 首先是 Log Position#

在某个 Partition 中：

1
Offset  0    1    2    3    4    5
2
Record E0   E1   E2   E3   E4   E5

Offset 表示 Record 在该 Partition Log 中的位置。

它首先具有位置语义，而不是业务身份语义。

6.2 Offset 不等于 Message ID#

Message ID 主要用于唯一标识某条消息，例如 UUID：

1
550e8400-e29b-41d4-a716-446655440000

Offset 则表达一条记录在有序日志中的位置：

1
offset=1034

因为它是位置，所以天然支持：

1
从 1034 开始读取
2
读取 1000～1100 范围
3
回退到 900
4
计算距离日志尾部还有多少位置

因此：

Offset 首先是 Position，不应该被简单理解成业务消息 ID。

6.3 Consumer Position#

Consumer 读取 Partition 时，可以表达：

1
fetch(P0, offset=6)

Broker 从 P0 的 Offset 6 开始返回一批数据。Consumer 处理完毕后，下一次读取位置向前推进。

逻辑执行链为：

1
Current Position
2
       ↓
3
Fetch Records
4
       ↓
5
Process Records
6
       ↓
7
Advance Position

Kafka 官方设计指出，Consumer 每个 Partition 的位置只需要一个整数，因此已消费状态非常小，并且可以周期性 Checkpoint。2

6.4 一条 Log 可以拥有多个消费视角#

对于同一个 order-events Partition：

1
Risk Consumer       position=1000
2
Warehouse Consumer  position=850
3
Agent Consumer      position=200

它们可以：

• 在不同时间上线；
• 以不同速度处理；
• 使用不同业务逻辑；
• 在需要时分别回放；
• 独立故障和恢复。

这就是数据与消费状态分离带来的独立性。

6.5 Current Position 与 Committed Offset#

本篇只做第一次区分。

1
0 1 2 3 4 5 6 7 8 9
2
        ↑       ↑
3
 committed    current
4
 offset=4     position=8

1
Current Position
2
Committed Offset
3
Log End Offset
4
High Watermark
5
Last Stable Offset

6.6 Kafka 重新定义了“消费”#

传统 Queue 经常把消费建模为消息状态变化：

1
NEW → DELIVERED → ACKED

Kafka 的经典 Consumer 模型则把消费建模为位置变化：

1
position=100 → position=120 → position=150

因此，可以得到全文最重要的结论之一：

Kafka 没有把“消费”建模成消息本身的状态变化，而是把它建模成消费者在 Log 上的位置变化。

7.1 Producer：把 Event 追加到 Partition#

Producer 负责构造 Record，并将它发送到某个 Topic 的某个 Partition：

1
ProducerRecord
2
      ↓
3
Topic
4
      ↓
5
Partition Selection
6
      ↓
7
Append to Partition Log

此处先不讨论序列化、Metadata、RecordAccumulator、Batch、Sender 和 NetworkClient。这些属于第三篇“Producer 完整执行链”。

第一篇只需要记住：

Producer 的最终目标不是“把消息交给某个 Consumer”，而是把 Event 追加到某条 Partition Log。

7.2 Broker：承担数据服务职责#

Broker 是承担 Kafka 数据服务职责的服务器角色，主要负责：

• 接收 Producer 写入；
• 保存 Topic Partition；
• 响应 Consumer Fetch；
• 参与 Partition 副本复制。

单个 Broker 可以保存多个 Topic 的多个 Partition；一个 Topic 的不同 Partition 也可以分布在不同 Broker 上。

7.3 Consumer：按 TopicPartition 和 Offset 读取#

Consumer 的核心行为可以抽象为：

1
Fetch(TopicPartition, Offset)

它从指定位置读取一批 Record，完成反序列化和业务处理，然后推进消费位置。

这解释了 Kafka 为什么更接近“读取日志”，而不是等待 Broker 主动把一条任务推到消费者手中。

7.4 用一句链路串起来#

Kafka 的基础数据链路可以表述为：

1
Producer
2
   ↓ append
3
Topic / Partition Log
4
   ↓ fetch(offset)
5
Consumer

其中：

• Topic 提供业务语义；
• Partition 提供分片、并行和局部顺序；
• Offset 提供位置坐标；
• Consumer Position 表示独立消费进度。

这四个抽象是后续理解 Kafka 高性能、Producer、Consumer Group、副本和事务的共同地基。

8.1 为什么单 Broker 不够#

单 Broker 面临明显边界：

• 单机磁盘容量有限；
• 单机网络和 CPU 吞吐有限；
• Broker 故障可能导致服务不可用；
• 数据只保存一份无法容忍磁盘或节点故障。

因此，Kafka 以 Cluster 形式运行，让 Partition 分布到多个 Broker，并为 Partition 建立副本。

此处只建立概念：

1
Partition
2
 ├── Leader Replica
3
 └── Follower Replica(s)

Producer 和 Consumer 的正常数据读写围绕 Partition Leader 进行；Follower 复制 Leader 数据。Replica、ISR、High Watermark 和 Leader 故障恢复将在第五篇深入研究。

8.2 数据之外还有集群元数据#

Kafka Cluster 必须持续知道：

• 集群中有哪些 Broker；
• 存在哪些 Topic；
• Topic 包含哪些 Partition；
• Partition Replica 位于哪些 Broker；
• 当前 Leader 是谁；
• 配置和权限如何变化。

这些信息属于 Cluster Metadata。

如果没有一致的 Metadata，Producer 无法知道应向哪个 Broker 写入，Consumer 也无法找到 Partition Leader。

8.3 KRaft：现代 Kafka 的控制平面#

Kafka 4.x 的架构主线是 KRaft。服务器可以通过 process.roles 配置为：

1
broker
2
controller
3
broker,controller

Kafka 官方文档说明，Controller 节点参与 Metadata Quorum，其中一个是 Active Controller，其余作为 Hot Standby；生产环境通常将 Controller 与 Broker 职责隔离。4

可以借用 Control Plane / Data Plane 理解：

1
Producer Write
2
Consumer Fetch
3
Partition Storage
4
Replica Transfer

1
Topic / Partition Metadata
2
Leader Information
3
Broker Registration
4
Configuration Changes

8.4 为什么本专栏不再以 ZooKeeper 为主线#

Kafka 早期版本依赖 ZooKeeper 保存和协调部分集群元数据，许多旧教程仍然从 ZooKeeper 开始讲 Kafka。

但学习现代 Kafka 时，应以 KRaft 为默认架构。ZooKeeper 只在解释历史演进、旧集群迁移或阅读旧源码时作为背景出现。

这可以避免形成一种已经过时的认知：

1
Kafka = Broker + ZooKeeper

现代主线应该是：

1
Kafka Cluster
2
 ├── Broker Data Plane
3
 └── KRaft Controller Quorum

10.1 从 Log 推导#

1
Log
2
 ├── 事件有序追加
3
 ├── 历史可以保留
4
 ├── 消费不要求删除数据
5
 └── Consumer 可以 Replay

10.2 从 Partition 推导#

1
Partition
2
 ├── 分布式存储
3
 ├── 并行写入
4
 ├── 并行读取
5
 ├── Partition 内顺序
6
 └── 放弃 Topic 全局顺序

10.3 从 Offset 推导#

1
Offset
2
 ├── 定位 Partition 中的位置
3
 ├── 支持范围读取
4
 ├── 支持回退和重放
5
 └── 支持恢复消费进度

10.4 从独立 Consumer Position 推导#

1
Independent Consumer Position
2
 ├── 多个系统读取同一份数据
3
 ├── 不同消费者拥有不同速度
4
 ├── 消费者故障不改变日志
5
 └── 每个消费者可以独立 Replay

最终，Kafka 的底层模型可以收束为：

1
Persistent Log
2
      +
3
Partitioning
4
      +
5
Offset-based Reading
6
      +
7
Independent Consumer Progress
8
      ↓
9
Distributed Event Streaming Platform

Kafka 最重要的设计，并不是创建了 Producer 和 Consumer API。

它真正改变的是我们对“消息”的理解。

在传统 Queue 直觉中，一条消息是一项等待被交付和完成的任务；在 Kafka 的 Log 世界中，一条 Event 是已经发生并被记录的事实。

Consumer 不再等待 Kafka 把消息交给自己。

它只是站在一条持续增长的 Log 上，决定自己要从哪里开始阅读。