每天认识一个组件：Apache Kafka

一、引言

Apache Kafka 经常被称为"消息队列"，但这只能解释它的一部分能力。更准确地说，Kafka 是一个以 分区、复制、持久化日志 为核心的分布式事件流平台：生产者持续追加事件，消费者使用 offset 记录读取位置，多个消费组可以按照各自节奏独立读取、回溯和重新处理历史数据。

Kafka不把消息看成消费后立即消失的临时对象，而是把它看成追加到分布式日志中的事件。消费者读取一条事件，并不会导致这条事件被删除。事件是否保留，由 Topic 的保留策略决定；消费者读取到什么位置，则由自身的 offset 决定。因此，同一批数据可以被实时风控、数据仓库、监控平台和推荐系统分别消费。

二、架构与核心概念

其中，Kafka 4.x 已移除 ZooKeeper 模式，只支持 KRaft，使用 controller quorum 管理集群元数据。

理解 Kafka，首先要理解一条主线：

Producer
   |
   | 发送事件
   v
Topic
   |
   | 拆分
   v
多个 Partition
   |
   | 复制
   v
多个 Broker 上的 Replica
   |
   | 按 Consumer Group 分配
   v
Consumer

1.Broker

Broker 是运行 Kafka 服务的节点，负责：

• 保存 Partition 日志；
• 接收 Producer 的写入请求；
• 响应 Consumer 的拉取请求；
• 在 Broker 之间复制数据；
• 承担消费组协调、事务协调等职责。

生产者和消费者通常只需要配置部分 Broker 地址作为bootstrap.servers 。客户端连接任意可用的引导节点后，会获取完整集群元数据，不需要手工列出所有 Broker。

2.Topic

Topic 是事件流的逻辑名称，例如：

orders
payments
user-behavior
database-changelog

Topic 是配置和管理边界。不同 Topic 可以设置不同的：

• Partition 数量；
• 副本因子；
• 数据保留时间；
• 日志压缩策略；
• 最小同步副本数；
• 单条消息大小限制。

Topic 不是一份单独的大文件，它由一个或多个 Partition 组成。

3.Partition

Partition 是 Kafka 的存储、局部顺序和并行处理单位，其本质是一个只追加的有序日志。

Topic: orders

Partition 0: [0][1][2][3][4][5]...
Partition 1: [0][1][2][3]...
Partition 2: [0][1][2][3][4]...
                ^
                offset

每条记录进入某个 Partition 后，会获得一个递增的 offset。需要特别注意：Kafka 只保证同一个 Partition 内的记录顺序，不保证整个 Topic 的全局顺序。

如果订单事件使用order_id 作为 key，并且分区数量与分区算法不变，那么同一订单的事件通常会进入同一 Partition，从而获得局部顺序。

不过，这个结论有两个边界：

• 增加 Partition 后，key 到 Partition 的映射可能改变；
• 更换分区器或分区算法后，映射也可能改变。

因此，"使用相同 key 就永远有序"并不严谨。更准确的说法是： 在分区数量、分区算法和业务 key 规则稳定时，同 key 事件通常能够保持 Partition 内顺序。

4.Replica

为避免单个 Broker 故障导致数据不可用，一个 Partition 可以拥有多个 Replica。

假设副本因子为 3：

                       Broker 1
                    +-------------+
写入请求 ----------> | P0 Leader   |
                    +------+------+
                           |
               +-----------+-----------+
               |                       |
               v                       v
          Broker 2                Broker 3
       +-------------+         +-------------+
       | P0 Follower |         | P0 Follower |
       +-------------+         +-------------+

正常情况下：

• Leader 处理该 Partition 的生产和消费请求；
• Follower 从 Leader 拉取数据；
• Leader 故障后，Kafka 从满足条件的副本中选出新 Leader。

Kafka 新版本也支持 follower fetching，但默认的数据读取路径仍应按照 Leader 读取模型理解；具体是否从本地副本读取，受客户端和机架感知配置影响。

5.ISR

ISR 是 In-Sync Replicas 的缩写，表示当前处于同步状态的副本集合，Leader 本身也属于 ISR。

例如：

Assigned Replicas: [1, 2, 3]
ISR:               [1, 2]

这表示 Partition 配置了 3 份副本，但 Broker 3 上的副本已经落后到不再被认为同步。

因此：

所有 Replica != ISR

如果配置：

min.insync.replicas=2

同时生产者使用：

acks=all

那么 ISR 少于 2 时，Broker 会拒绝写入，而不是继续以单副本接收数据。系统以暂时降低可用性为代价，避免在副本不足时继续累积数据风险。

6.Consumer Group

Consumer Group 用于让多个消费者共同处理一个 Topic。

在传统 Consumer Group 中，同一个 Partition 在同一时刻最多分配给组内一个 Consumer。因此，消费并行度受 Partition 数限制。

假设一个 Topic 有 3 个 Partition：

|-------|---------|-----------------------|
| 消费者数量 | 实际并行消费者 | 结果 |
| 1 | 1 | 一个消费者处理全部 Partition |
| 2 | 2 | 两个消费者分担 3 个 Partition |
| 3 | 3 | 每个消费者处理一个 Partition |
| 5 | 3 | 两个消费者处于空闲状态 |

这意味着增加消费者并不一定提高吞吐。只有当 Partition 数足够、Broker 和下游系统仍有余量时，横向扩容消费者才可能有效。

不同 Consumer Group 之间互不影响：

7.Offset

Kafka 中有几种容易混淆的位置概念。

|--------------------|------------------------------|
| 概念 | 含义 |
| Record Offset | 一条记录在 Partition 中的位置 |
| Consumer Position | Consumer 下一次准备读取的位置 |
| Committed Offset | 消费组持久保存的恢复位置 |
| High Watermark | 已复制到足够副本、可安全暴露的日志边界 |
| Last Stable Offset | read_committed 模式下可读取的事务稳定边界 |

假设 Consumer 已处理 offset 为 100 的消息，提交值通常是 101，含义是"下次从 101 开始读取"。

Partition:
... [98] [99] [100] [101] [102] ...

已经处理到：       100
提交的下一位置：         101

提交 offset 只是在 Kafka 中保存恢复位置，并不代表业务一定处理成功。例如，应用先提交 offset，再写数据库，随后数据库写入失败，这条消息在重启后可能不会再次被读取。

三、生产和消费流程

一次典型写入和消费过程如下：

Producer 通常不会把所有数据先发送给一个中央路由节点，而是先获取 Topic 元数据，然后直接向目标 Partition 的 Leader 发送数据。这减少了中心转发瓶颈。

Consumer 采用拉取模式。它根据自己的处理能力向 Broker 请求数据，并维护读取位置。慢消费者不会要求 Producer 降速，但会形成不断增长的消费积压。

四、Kafka 为什么吞吐高

1.顺序追加

Kafka 将记录持续追加到 Partition 日志尾部，主要使用顺序 I/O，而不是围绕每条消息维护复杂的随机更新结构。

随机写：
磁盘位置 A -> 位置 Z -> 位置 C -> 位置 M

顺序追加：
[旧数据][旧数据][新数据][新数据][新数据] ->

顺序访问通常比频繁随机寻址更适合磁盘和现代存储设备。不过，Kafka 性能仍然受磁盘、网络、page cache 命中率、日志段数量、副本恢复和消息尺寸等因素影响。

2.批处理

Producer 会把多条记录组合成 Record Batch，再统一发送：

逐条发送：
[M1] -> [M2] -> [M3] -> [M4]

批量发送：
[M1 M2 M3 M4] ->

批量处理可以减少：

• 网络请求次数；
• 系统调用次数；
• 请求头开销；
• 磁盘写入次数；
• 压缩元数据开销。

batch.size 和linger.ms 会影响批量程度。Kafka 4.x版本 起，Producer 的linger.ms 默认值由早期版本的 0 调整为 5 毫秒，旧版经验不能直接套用到当前版本。

3.Page Cache

Kafka 倾向于使用操作系统 page cache 管理热点数据，而不是在 JVM 堆中维护一份大规模重复缓存。

这样做的好处包括：

• 减少 JVM 大堆带来的垃圾回收压力；
• 操作系统可以统一管理磁盘缓存；
• Broker 重启后，操作系统缓存不一定立即消失；
• 刚写入的数据往往仍在 page cache 中，消费者可以快速读取。

但 page cache 不是无限资源。Kafka Broker 与其他高 I/O 程序混部，可能产生严重的缓存竞争。

4.少拷贝路径

在适用的非 SSL 传输路径中，Kafka 可以利用sendfile 等机制减少数据在内核空间和用户空间之间的复制。

概念上的传统路径：

磁盘 -> 内核缓存 -> 应用缓冲区 -> Socket 缓冲区 -> 网卡

减少复制后的路径更接近：

磁盘 -> 内核缓存 -----------------------> 网卡

需要注意：使用 SSL 时不能利用同样的sendfile 零拷贝路径。

5.压缩

Kafka 支持 gzip、snappy、lz4 和 zstd 等压缩算法。压缩以 Record Batch 为单位进行，通常可以减少网络流量和磁盘占用。

是否选择 zstd、lz4 或其他算法，需要根据以下指标压测：

• 消息内容的可压缩性；
• CPU 预算；
• 网络带宽；
• 端到端延迟；
• Broker 解压和重压缩行为；
• 客户端兼容性。

五、数据保留与回放

Kafka 的数据生命周期与消费者读取行为解耦。消息被消费后，不会因此立即删除。

常见保留配置包括：

retention.ms=604800000
retention.bytes=107374182400

retention.ms 控制保留时间，retention.bytes 控制空间上限。需要注意，retention.bytes 是按 Partition 生效的，不是整个 Topic 共享一个总容量。

Kafka 按日志段进行清理，而不是在每条记录刚到期时立即逐条删除。因此，即使记录已经超过保留时间，实际释放空间也可能存在延迟。

这种设计让 Kafka 支持数据回放：

实时消费：
offset 1000 -> 1001 -> 1002 -> ...

问题修复后重新计算：
offset 0 -> 1 -> 2 -> ... -> 1002

回放能力适用于：

• 修复计算逻辑后重算；
• 恢复下游数据库；
• 新系统接入后补历史数据；
• 审计和问题复盘；
• 重新构建搜索索引或状态存储。

六、可靠性机制

一组常见的高可靠配置如下：

# Topic
replication.factor=3
min.insync.replicas=2

# Producer
acks=all
enable.idempotence=true

# Broker
unclean.leader.election.enable=false

acks=all 并不表示所有已配置 Replica 都确认，而是等待当前同步副本集合满足确认条件。因此，它需要与min.insync.replicas 配合。

|----------|-----------------|------------------------|
| 配置 | Producer 何时认为成功 | 主要风险 |
| acks=0 | 不等待 Broker 响应 | 可能静默丢失 |
| acks=1 | Leader 本地写入成功 | Leader 故障时，尚未复制的数据可能丢失 |
| acks=all | 当前 ISR 满足确认要求 | 延迟相对更高，ISR 不足时可能拒绝写入 |

如果所有同步副本都不可用，是否允许一个落后的副本成为 Leader，由unclean.leader.election.enable 控制。开启不干净选主可以提高极端故障下的可用性，但可能造成数据截断或丢失；关闭后则可能让 Partition 暂时不可用。这是典型的完整性与可用性取舍，不存在适合所有系统的统一答案。

七、消息语义

• At-most-once：先提交 offset，再处理业务。如果提交后处理失败，消息可能不会再次读取，因此可能丢处理，但通常不会重复处理。
• At-least-once：先处理业务，再提交 offset。如果业务已成功，但提交 offset 前应用崩溃，重启后可能再次处理该消息。这是很多业务系统更常用的模式，但下游必须考虑幂等。
• Exactly-once：Kafka 可以通过以下机制提供事务能力：幂等 Producer 避免生产重试导致重复追加、Transaction 将多个 Partition 的写入原子化、将消费 offset 与输出记录放在同一事务中提交、Consumer 使用isolation.level=read_committed 跳过中止事务等。

Kafka 在其事务边界内可以提供 Exactly-once 处理能力，但跨出 Kafka 后，需要外部系统共同参与。

八、功能生态

1.Kafka Connect

Kafka Connect 用于 Kafka 与外部系统之间的数据集成。

外部系统                    Kafka                    外部系统
数据库 ---- Source Connector ---> Topic ---> Sink Connector ---- 数据仓库
文件系统 -- Source Connector ---> Topic ---> Sink Connector ---- 搜索引擎

主要概念包括：

• Source Connector：将外部数据写入 Kafka；
• Sink Connector：将 Kafka 数据写到外部系统；
• Connector：负责规划数据任务；
• Task：实际执行数据传输；
• Worker：运行 Connector 和 Task。

Standalone 模式适合本地开发和简单任务；Distributed 模式支持多个 Worker、任务重新分配、故障转移和动态扩缩，更适合生产环境。

需要注意，Connector 的交付语义取决于具体实现和目标系统能力，不能仅凭"使用 Kafka Connect"就推断整个链路一定是 Exactly-once。

2.Kafka Streams

Kafka Streams 是嵌入 Java 或 Scala 应用的客户端库，不是需要单独部署的一套计算集群。

它支持：

• map 、filter ；

• 分组与聚合；

• Stream-Stream Join；

• Stream-Table Join；

• 窗口计算；

• 事件时间处理；

• 本地状态存储；

• 状态变更日志与故障恢复。

  Input Topic
  |
  v
  Kafka Streams Application
  |
  +--> Filter
  |
  +--> Group / Window / Aggregate
  |
  +--> State Store
  |
  v
  Output Topic

有状态计算的数据通常保存在本地 State Store，并通过 Kafka Changelog Topic 进行恢复。其有效并行度仍受输入 Partition 和任务划分约束。

九、优势与代价

|-----------|-------------------------------------|
| 优势 | 原因 |
| 高吞吐 | 顺序追加、批处理、压缩、page cache 和分区并行 |
| 可扩展 | Topic 可以通过多个 Partition 分布在多个 Broker |
| 高可用 | Partition 副本、ISR 和 Leader 故障转移 |
| 可回放 | 消费位置与数据生命周期分离 |
| 多订阅者 | 不同 Consumer Group 独立维护 offset |
| 生态丰富 | Connect、Streams 及大量第三方集成 |
| 流批一体的数据基础 | 同一事件日志可服务实时处理和离线同步 |

|----------|-----------------------------|
| 代价 | 表现 |
| 顺序边界 | 只保证 Partition 内顺序 |
| 运维复杂度 | 需要管理副本、磁盘、网络、分区和 Controller |
| 容量成本 | 长时间保留和多副本会放大存储需求 |
| 热点风险 | key 分布不均可能形成热 Partition |
| 消费一致性 | 业务侧仍需处理重复、失败和外部副作用 |
| 分区不可随意调整 | 扩分区可能改变 key 映射和顺序假设 |
| 低延迟并非零成本 | 批量吞吐、复制可靠性和延迟之间需要权衡 |

十、适用场景

• 事件驱动架构：订单、支付、库存、物流等系统通过事件解耦。
• 日志与指标管道：集中采集应用日志、访问日志和运行指标，再写入数据湖、搜索系统或实时监控平台。
• CDC 数据同步：数据库变更通过 CDC 工具进入 Kafka，再同步到目标端。
• 实时计算：Kafka 作为 Flink、Spark Structured Streaming 或 Kafka Streams 的输入和输出层。
• 数据回放和审计：需要长期保留事件、重新计算、恢复下游状态或复盘历史操作时，Kafka 的 offset 和保留机制具有明显优势。

Kafka 并非任何消息需求的默认答案。以下场景应谨慎选择：

• 只需少量、低频、简单异步任务，使用 Kafka 可能增加不必要的运维成本；
• 需要复杂消息优先级、单条消息任意延迟投递时，专用消息系统可能更直接；
• 需要跨所有事件的严格全局顺序，而吞吐量又较高；
• 需要同步请求响应，RPC 或 HTTP 通常更合适；
• 需要对外部数据库和 HTTP 调用自动实现全局事务；
• 数据量很小，却需要维护多 Broker 和 Controller 集群。

Kafka 擅长的是可持久、可回放、高吞吐的事件流，不是对所有通信模型进行替代。

十一、小结

Kafka 的核心并不复杂： 生产者把事件追加到分区日志，Broker 对日志进行持久化和复制，消费者按照自己的 offset 拉取数据。 但正是 Partition、Replica、ISR、Consumer Group 和数据保留之间的组合，让 Kafka 同时具备高吞吐、可扩展、可回放和多订阅者能力。

建立 Kafka 的正确认知，需要记住几个边界：

• Kafka 是事件流平台，不只是传统消息队列；
• 顺序保证以 Partition 为边界；
• 高可用来自副本和 ISR，不是单一配置；
• 消息提交位置不等于业务处理完成；
• Exactly-once 有明确的系统边界；
• 增加 Partition、Consumer 或重试次数都不是无成本优化；
• 生产稳定性依赖容量规划、监控、压测和故障演练。