核心概念
Kafka 基本术语（Topic/Partition/Offset/Broker/副本/重平衡）、核心特性、消息模型、四大核心 API，以及 Kafka 高性能的原理。
基本术语
| 术语 | 说明 |
|---|---|
| 消息（Message） | 数据单元，也称为记录（Record） |
| 批次（Batch） | 消息会分批次写入 Kafka，代指一组消息。批处理能提高吞吐量 |
| 主题（Topic） | 消息的分类。一个 Topic 代表一类消息，可以理解为数据库中的"表" |
| 分区（Partition） | Topic 可被分为多个 Partition，分布在不同 Broker 上，实现水平扩展。单个 Partition 内消息有序，但无法保证跨 Partition 的有序性。例如三个分区：p0: 1 2 3 4 5, p1: 1 2 3, p2: 1 2 3 4 5 6 |
| 生产者（Producer） | 向 Topic 发布消息的客户端 |
| 消费者（Consumer） | 订阅 Topic 并处理消息的客户端 |
| 消费者群组（Consumer Group） | 一个或多个消费者组成的群体。组内消费者共同消费一个 Topic，每条消息只被组内一个消费者处理 |
| 偏移量（Offset） | 消息在 Partition 中的唯一标识，是一个不断递增的整数。用于记录消费进度，在发生重平衡时恢复消费位置 |
| Broker | 一个独立的 Kafka 服务器实例。接收生产者消息、为消息设置 Offset、将消息持久化到磁盘 |
| Broker 集群 | 由多个 Broker 组成。每个集群有一个 Broker 同时充当集群控制器（Controller，通过选举产生） |
| 副本（Replica） | 消息的备份。分为 Leader 和 Follower——Leader 对外提供服务，Follower 被动同步。每个分区有 AR（全部副本集）、ISR（跟得上 Leader 的副本子集）两个名单（机制详解见 12 章） |
| 高水位（HW, High Watermark） | ISR 内所有副本都已落盘的最新位置。消费者只能读到 HW 之前的消息——“acks=all 不丢"的保障线（12 章） |
| 重平衡（Rebalance） | 消费者组内某个实例挂掉后，其他实例自动重新分配订阅分区的过程。是实现高可用的重要手段 |
| KRaft / Controller | Kafka 自管理的元数据层（Raft 协议，4.0 起替代并移除 ZooKeeper）。集群选出一个 Active Controller 负责 Leader 选举与元数据变更 |
Kafka 核心特性
- 高吞吐、低延迟：Kafka 最大的特点就是收发消息极快，每秒可处理几十万条消息，最低延迟仅几毫秒。
- 高伸缩性：每个 Topic 包含多个 Partition，Partition 可分布在不同的 Broker 上，实现水平扩展。
- 持久性与可靠性：消息被持久化到磁盘（不是存储在 Zookeeper 中！），并支持多副本备份防止数据丢失。Kafka 的元数据（如 Broker 信息、Topic 配置等）存储在 Zookeeper 或 KRaft 中，而消息数据本身存储在本地磁盘上。
- 容错性：允许集群中部分节点失败（只要 ISR 中有足够的副本），集群仍能正常工作。
- 高并发：支持数千个客户端同时读写。
使用场景
| 场景 | 说明 |
|---|---|
| 活动跟踪 | 追踪用户行为：登录、浏览、搜索、购物偏好等，用于生成报表、智能推荐 |
| 消息传递 | 应用程序间的异步通信，如发送通知、状态同步 |
| 度量指标 | 收集分布式应用的运营监控数据，用于报警和报表 |
| 日志记录 | 将数据库更新、应用日志等以统一接口发送到 Kafka，再分发给 Hadoop、HBase、Solr 等下游 |
| 流式处理 | 作为流处理平台（如 Flink、Spark Streaming）的数据源 |
| 限流削峰 | 应对突发流量，将请求写入 Kafka 缓冲，避免直接压垮后端服务 |
Kafka 的消息模型
Kafka 同时支持两种消息模型：
- 点对点模式（P2P）：一条消息只被一个消费者消费。同一消费者组内的多个消费者竞争消费。
- 发布-订阅模式（Pub-Sub）：一条消息被多个消费者组同时消费（每个组独立维护 Offset）。不同消费者组之间互不影响。
系统架构概览
KRaft 时代（4.x）的集群全景，一条消息的完整旅程：
Producer ──①写──▶ 分区 Leader 副本 ──②Follower 拉取复制──▶ ISR 副本
│
③消费者拉取（只读到 HW 为止）
▼
Consumer Group（组间独立、组内分分区）
元数据层：Controller Quorum（3~5 台，Raft 选举出 Active Controller）
├─ 维护 Topic/分区/副本/组成员变更
├─ 触发 Leader 选举
└─ 与 Broker 数据面分离：quorum 全挂只停"管理操作"，已有分区照常读写读图要点：
- 数据面是 Broker 间的异步复制日志流（Follower 主动拉，类 Pull），控制面是 Controller 的 Raft 元数据日志——两条链路互不阻塞，这是 KRaft 干掉 ZooKeeper 后架构上最大的红利；
- 生产者写 Leader，消费者读 Leader（
fetch也优先同机架副本，12 章）；Follower 只参与复制不对客户端提供读写（副本读取语义已废弃）； - “分区"是并行与顺序的唯一粒度单位：Topic 只是逻辑分组，真正的存储、复制、消费分配全都发生在分区上。
集群搭建与故障转移细节见 12-集群与高可用。
Kafka 4.x 演进速览
2025-2026 年值得知道的变化（详细运维视角见 12 章）：
- 4.0（2025-03）：移除 ZooKeeper（只跑 KRaft）、服务端要求 Java 17、MM1 下线；清理 2.x 以前的旧协议。
- 4.1：生产者限流、Controller 切换更平滑。
- 4.2（2026-02）：Kafka Queues（Share Groups）GA——逐条 ACK + RENEW 续期的队列语义，Kafka 开始蚕食传统 MQ 的场景边界（与 RabbitMQ 的选型对照更新见 07 章）。
- 4.3（2026-05）：Broker 维护引流、分区容量指标、Streams Header 保持。
- 动态 Controller Quorum（增删控制器不停机）、分层存储（对象存储降本）在 4.x 持续完善。
核心 API
Kafka 提供四大核心 API：
| API | 说明 |
|---|---|
| Producer API | 向一个或多个 Topic 发送消息 |
| Consumer API | 订阅一个或多个 Topic 并处理消息流 |
| Streams API | 将程序作为流处理器，消费输入流并生成输出流（数据转换） |
| Connector API | 构建可复用的生产者和消费者，将 Kafka 连接到现有应用或数据系统（如数据库、搜索引擎） |
Kafka 为什么这么快？
Kafka 的核心性能秘诀可以总结为四个要点：
-
顺序读写磁盘：Kafka 将消息以追加（append-only）方式写入日志文件，避免了随机磁盘寻址的巨大开销。顺序磁盘 I/O 的速度甚至可以媲美内存随机读写。
-
零拷贝（Zero Copy）：Kafka 利用操作系统的
sendfile()系统调用，数据从磁盘到网络传输过程中无需经过用户态内存拷贝，避免了内核态 ↔ 用户态的上下文切换开销。 -
消息压缩：支持 GZIP、Snappy、LZ4、Zstd 等压缩算法，减少网络传输和磁盘占用。
-
批量发送：从生产者 → 文件系统 → 消费者，数据以批次为单位端到端传输，有效减少 I/O 延迟和网络往返次数。