2. Kafka 核心概念：Topic、Partition、Producer、Consumer、Broker、Zookeeper 的作用与关系
Kafka 的架构由一组职责清晰的核心组件构成。理解这些组件及其协作关系，是进行消息驱动领域建模的基础。本节将逐一剖析每个核心概念，并通过结构图和对比表格阐明它们之间的静态关系与动态交互。
2.1 核心组件全景图
下图展示了 Kafka 集群中 Broker、Topic、Partition、Producer、Consumer 以及 Zookeeper 之间的逻辑关系。Producer 将消息写入 Topic 的特定 Partition，Consumer 从 Partition 拉取消息，Broker 负责存储和副本管理，Zookeeper 则维护集群元数据与领导者选举。
2.2 核心概念逐项解析
2.2.1 Broker
Broker 是 Kafka 集群中的单个服务器节点，负责接收来自 Producer 的消息、为消息分配存储空间、处理 Consumer 的拉取请求。一个集群通常由多个 Broker 组成，以实现负载均衡和高可用。每个 Broker 都有一个唯一 ID（broker.id）。
2.2.2 Topic 与 Partition
- Topic：消息的逻辑分类名称，类似于数据库中的表。Producer 将消息发布到特定 Topic，Consumer 订阅该 Topic 以获取消息。
- Partition：Topic 物理上的分片。每个 Partition 是一个有序、不可变的消息序列（日志），新消息追加到尾部。Partition 是 Kafka 并行处理的基本单位。
领域建模启示： 在领域驱动设计中，Topic 通常对应一个领域事件或命令的通道。例如
order-created、payment-received。Partition 的数量决定了该事件流的最大并行消费能力，应基于预期吞吐量和领域边界进行设计。
2.2.3 Producer
Producer 是消息的发布者，负责将消息发送到指定的 Topic。Producer 可以指定消息的 Key，Kafka 根据 Key 的哈希值决定消息写入哪个 Partition（保证相同 Key 的消息进入同一 Partition，从而保持顺序）。
2.2.4 Consumer 与 Consumer Group
- Consumer：从 Partition 拉取消息的客户端。每个 Consumer 维护已消费的偏移量（Offset）。
- Consumer Group：一组 Consumer 的集合，共同消费一个或多个 Topic。Group 内的每个 Consumer 负责处理不同的 Partition，实现水平扩展和故障转移。如果某个 Consumer 宕机，其负责的 Partition 会被重新分配给组内其他成员。
2.2.5 Zookeeper
Zookeeper 是 Kafka 集群的协调服务，负责以下关键任务：
- 元数据管理：存储 Topic 列表、Partition 数量、副本分配等配置信息。
- 控制器选举：在集群中选举一个 Broker 作为控制器（Controller），负责管理 Partition 的 Leader 选举和重新分配。
- 集群成员管理：监控 Broker 的存活状态，当 Broker 加入或离开时通知控制器。
注意： 从 Kafka 2.8 开始，社区正在逐步移除对 Zookeeper 的强依赖（KIP-500），未来版本将使用基于 Raft 协议的 KRaft 模式。但在当前主流生产环境中，Zookeeper 仍然是不可或缺的组件。
2.3 组件职责与关系对比表
| 组件 | 核心职责 | 与 Topic 的关系 | 与 Partition 的关系 | 关键特性 |
|---|---|---|---|---|
| Broker | 消息存储、副本管理、请求处理 | 存储 Topic 的所有 Partition | 每个 Broker 持有部分 Partition 的 Leader 或 Follower 副本 | 无状态（数据在磁盘），可水平扩展 |
| Topic | 消息的逻辑分类 | — | 由多个 Partition 组成 | 可配置副本数、保留策略 |
| Partition | 消息的物理分片与顺序保证 | 属于一个 Topic | — | 有序、不可变、可并行消费 |
| Producer | 发布消息到指定 Topic | 写入 Topic 的某个 Partition | 通过 Key 哈希或轮询选择 Partition | 支持异步/同步发送、幂等性、事务 |
| Consumer | 从 Partition 拉取并处理消息 | 订阅一个或多个 Topic | 一个 Consumer 可消费多个 Partition | 维护 Offset，支持自动/手动提交 |
| Zookeeper | 集群协调与元数据存储 | 存储 Topic 配置 | 存储 Partition 的 Leader 信息 | 强一致性、高可用 |
2.4 消息写入与消费流程
下图聚焦于一条消息从 Producer 到 Consumer 的完整路径，突出 Partition 在其中的核心地位。
2.5 领域建模视角下的概念映射
在领域驱动设计中，Kafka 的核心概念可以与战术建模元素建立清晰的映射关系：
| Kafka 概念 | DDD 战术元素 | 映射说明 |
|---|---|---|
| Topic | 领域事件通道 / 命令通道 | 每个 Topic 对应一个领域事件类型（如 OrderPlaced）或命令（如 ValidatePayment） |
| Partition | 事件流分片 / 聚合实例分组 | 相同聚合 ID（如订单 ID）的消息路由到同一 Partition，保证该聚合的事件顺序 |
| Producer | 领域服务 / 应用服务 | 负责发布领域事件到对应的 Topic，通常位于聚合的命令方法或领域服务中 |
| Consumer | 领域事件处理器 / 订阅者 | 处理特定领域事件，触发新的业务逻辑或更新读模型 |
| Consumer Group | 限界上下文 / 处理单元 | 一个限界上下文通常对应一个 Consumer Group，独立处理其关注的事件 |
实践建议： 在设计 Topic 时，优先使用领域事件名称作为 Topic 名称（如
order.order-placed），并采用 {限界上下文}.{事件名} 的命名规范。Partition 数量应结合该事件的预期吞吐量和下游 Consumer 的并行度进行估算，通常建议设置为 3~6 的倍数，便于后续扩展。