2. Kafka 架构：Broker、Producer、Consumer、Topic、Partition、Offset 概念详解
聊 Kafka，绕不开这几个核心角色。我刚开始接触时，也被 Broker、Topic、Partition 这些词搞得有点晕。说白了，它们就是 Kafka 世界的「零件」，搞懂了它们，整个系统怎么跑的你心里就有数了。
一句话总结：Producer 发消息给 Topic，Topic 被切成 Partition 分散存到多个 Broker 上，Consumer 从 Partition 里按 Offset 顺序读。就这么简单。
2.1 Broker：Kafka 的「服务器节点」
Broker 就是一台运行着 Kafka 进程的服务器。你可以把它理解成一个「消息仓库的看门人」。每个 Broker 都有一个唯一的 ID（数字），集群里可以有几十上百个 Broker。
- 存储消息：消息最终是落在 Broker 的磁盘上的。
- 处理请求：Producer 发消息、Consumer 拉消息，都是跟 Broker 打交道。
- 集群协作：多个 Broker 通过 Zookeeper 或 KRaft 协调，选出一个 Controller 来管理元数据。
我的经验：我在项目中遇到过 Broker 磁盘写满导致整个集群不可用的情况。嗯，这里要注意——一定要给 Broker 的日志目录配好监控和磁盘报警，别等满了才去救。
2.2 Topic 与 Partition：逻辑与物理的分割
Topic 是消息的逻辑分类。比如你有个「订单消息」Topic，所有订单相关消息都往这个 Topic 里发。但一个 Topic 如果只有一份数据，那吞吐量就上不去。所以 Kafka 把 Topic 切成了多个 Partition。
Partition 是物理上的存储单元。每个 Partition 就是一个有序的、不可变的日志文件。消息追加到 Partition 尾部，每个消息都有一个唯一的 Offset。
| 概念 | 层级 | 作用 |
|---|---|---|
| Topic | 逻辑 | 消息的分类名称，类似数据库里的表 |
| Partition | 物理 | Topic 的分片，实现并行读写和水平扩展 |
你想想看，如果一个 Topic 有 3 个 Partition，那这 3 个 Partition 可以分布在 3 个不同的 Broker 上。Producer 发消息时可以并行发到 3 个 Partition，Consumer 也可以从 3 个 Partition 并行拉。吞吐量自然就上去了。
避坑指南：我曾经因为 Partition 数量设得太少，导致 Consumer 组里的消费者闲置。后来我养成了一个习惯——Partition 数至少是 Consumer 数的 2 倍，这样既能负载均衡，又留了扩容空间。
2.3 Offset：消息的「身份证号」
每个 Partition 里的消息都有一个递增的序号，这就是 Offset。它从 0 开始，每来一条新消息就加 1。Consumer 通过 Offset 来定位自己要读哪条消息。
Offset 有两个关键特性：
- 单调递增：在同一个 Partition 内，Offset 只增不减。
- 分区独立：不同 Partition 的 Offset 是独立的，互不影响。
Consumer 读完消息后，会提交 Offset 给 Kafka 或一个特殊的 Topic（__consumer_offsets）。这样如果 Consumer 挂了重启，它就知道从哪继续读。
核心要点：Offset 是 Kafka 实现「消息不丢不重」的基石。Consumer 通过控制 Offset 的提交时机，可以实现「至少一次」、「至多一次」或「精确一次」语义。
2.4 Producer：消息的「生产者」
Producer 负责把消息发到指定的 Topic。它有几个关键行为：
- 选择 Partition：可以指定 key，Kafka 根据 key 的哈希值决定发到哪个 Partition；不指定 key 就轮询。
- 确认机制：acks 参数控制 Producer 等待几个 Broker 确认后才算发送成功。acks=0 最快但可能丢，acks=all 最安全但慢。
- 重试与幂等：网络抖动时 Producer 会自动重试。开启幂等后，即使重试也不会产生重复消息。
我的习惯：生产环境我一般用 acks=all 配合幂等。虽然慢一点，但心里踏实。你想想看，丢一条订单消息的代价可比那点延迟大多了。
2.5 Consumer 与 Consumer Group：消息的「消费者」
Consumer 从 Partition 里拉取消息。但单个 Consumer 处理能力有限，所以 Kafka 引入了 Consumer Group 的概念。
一个 Consumer Group 里的多个 Consumer 共同消费一个 Topic。Kafka 保证每个 Partition 只会被组内的一个 Consumer 消费。这就是「分区分配」——组内成员变化时，会触发 Rebalance，重新分配 Partition。
| 场景 | Consumer 数 | Partition 数 | 结果 |
|---|---|---|---|
| 理想 | 3 | 3 | 一对一，完美并行 |
| Consumer 多 | 5 | 3 | 有 2 个 Consumer 闲置 |
| Consumer 少 | 2 | 3 | 一个 Consumer 消费 2 个 Partition |
我曾经踩过的坑：Rebalance 期间所有 Consumer 会暂停消费，如果业务对延迟敏感，这很致命。后来我改用 Cooperative Rebalance（增量式协调），每次只重分配有变化的 Partition，而不是全部停掉。
2.6 架构全景图：它们怎么配合？
下面这张图把上面讲的所有概念串在一起。你可以看到 Producer 发消息、Broker 存消息、Consumer 拉消息的完整链路。
2.7 小结：记住这五句话
- Broker 是 Kafka 集群里的服务器节点，负责存消息、处理请求。
- Topic 是消息的逻辑分类，Partition 是 Topic 的物理分片，实现并行。
- Offset 是 Partition 内消息的唯一序号，Consumer 用它来定位消费位置。
- Producer 发消息到 Topic，可以指定 Partition 或轮询分配。
- Consumer Group 里的 Consumer 协同消费，每个 Partition 只分配给一个 Consumer。
嗯，这些概念是 Kafka 的骨架。你只要把 Broker、Topic、Partition、Offset、Producer、Consumer 这六个角色之间的关系理清楚，后面学再复杂的东西都不会跑偏。