2. Kafka 核心概念：Topic、Partition、Producer、Consumer、Broker、Zookeeper 角色与原理
Kafka 是一个分布式、分区、多副本的发布-订阅消息系统。理解其核心概念是掌握流式处理与构建 SHAP 评分接口的基础。本章将逐一拆解这些角色的定义、职责与协作原理。
2.1 核心角色总览
Kafka 体系由以下六大核心组件构成，它们各司其职，共同保障消息的高吞吐、持久化与容错性。
| 组件 | 角色定义 | 核心职责 |
|---|---|---|
| Broker | Kafka 集群中的服务器节点 | 存储消息、处理客户端请求、管理分区副本 |
| Topic | 消息的逻辑分类/主题 | 定义数据流类别，生产者向 Topic 写，消费者从 Topic 读 |
| Partition | Topic 的物理分片单元 | 实现并行读写、水平扩展、消息有序性（分区内） |
| Producer | 消息生产者（发布者） | 将消息发送到指定 Topic 的 Partition |
| Consumer | 消息消费者（订阅者） | 从 Topic 拉取消息，处理业务逻辑 |
| Zookeeper | 分布式协调服务 | 管理集群元数据、Broker 注册、Leader 选举 |
2.2 Topic 与 Partition：逻辑分类与物理分片
Topic 是 Kafka 中消息的逻辑分类。例如，在 SHAP 评分场景中，可以创建 shap-requests 和 shap-responses 两个 Topic，分别存放请求特征与评分结果。
Partition 是 Topic 的物理分片。每个 Topic 可以包含多个 Partition，每个 Partition 是一个有序的、不可变的日志文件（append-only log）。
关键原理：
- 分区内有序：消息在同一个 Partition 内按 offset 严格有序。
- 全局无序：不同 Partition 之间不保证顺序。
- 并行度：Partition 数量决定了 Consumer 的最大并行消费数。
- 副本机制：每个 Partition 有多个副本（Replica），分布在不同的 Broker 上，保障高可用。
2.3 Producer：消息发布者
Producer 负责将消息发送到指定的 Topic。在 SHAP 评分接口中，Producer 通常由特征采集服务或 API 网关扮演。
核心工作流程：
- 序列化：将业务对象（如特征向量）转换为字节数组。
- 分区选择：根据 key 的哈希值或自定义分区器，决定消息写入哪个 Partition。
- 批量发送：Producer 将消息暂存到缓冲区，按批次发送到 Broker，提升吞吐量。
- 确认机制（acks）：配置
acks=all确保所有副本写入成功后才返回确认。
生产实践：在 SHAP 评分场景中，建议将
acks 设置为 all，并开启 enable.idempotence=true，确保评分请求不丢失、不重复。
2.4 Consumer 与 Consumer Group：消息订阅者
Consumer 从 Topic 拉取消息。多个 Consumer 可以组成一个 Consumer Group，实现负载均衡与容错。
分区分配策略：
| 策略 | 描述 | 适用场景 |
|---|---|---|
| Range | 按 Topic 分区范围顺序分配 | 分区数较少，均匀分配 |
| RoundRobin | 轮询分配所有分区 | 多 Topic 订阅，负载均衡 |
| Sticky | 尽量保持已有分配，减少重平衡 | 频繁重平衡场景，减少抖动 |
| Cooperative | 增量式重平衡，非停止全部 | 大规模 Consumer 组，降低中断时间 |
注意：一个 Partition 只能被同一个 Consumer Group 内的一个 Consumer 消费。如果 Consumer 数量超过 Partition 数量，多余的 Consumer 将处于空闲状态。
2.5 Broker：集群节点
Broker 是 Kafka 集群中的服务器节点，负责消息的存储、转发与管理。每个 Broker 都有一个唯一的 ID。
Broker 的核心职责：
- 消息存储：将消息持久化到磁盘，支持日志分段（Segment）与索引。
- 副本管理：维护 Partition 的 Leader 与 Follower 副本。
- 客户端请求处理：响应 Producer 的写入请求和 Consumer 的拉取请求。
- 控制器角色：集群中有一个 Broker 充当 Controller，负责 Partition 的 Leader 选举与元数据管理。
2.6 Zookeeper：分布式协调者
Zookeeper 是 Kafka 集群的“大脑”，负责维护集群的元数据与协调状态。在 Kafka 2.8+ 版本中，Kafka 开始引入 KRaft 模式逐步替代 Zookeeper，但 Zookeeper 模式仍是生产环境的主流。
Zookeeper 在 Kafka 中的角色：
| 功能 | 说明 |
|---|---|
| Broker 注册 | Broker 启动时在 Zookeeper 中创建临时节点，记录 Broker ID 与地址 |
| Topic 元数据 | 存储 Topic 列表、Partition 数量、副本分配信息 |
| Leader 选举 | 当 Partition 的 Leader 宕机时，Zookeeper 协调选举新的 Leader |
| Consumer 组协调 | 记录 Consumer Group 的成员信息与 offset 提交（旧版本） |
| 集群健康检查 | 通过心跳检测 Broker 存活状态 |
2.7 消息流转全流程
结合 SHAP 评分接口案例，一条消息从产生到消费的完整路径如下：
- 特征采集服务（Producer）将用户特征序列化为 Avro/JSON 格式。
- Producer 根据
user_id的哈希值，将消息发送到shap-requestsTopic 的 Partition 2。 - Broker 2（该 Partition 的 Leader）接收消息，写入日志，并同步给 Follower 副本。
- 评分计算服务（Consumer Group:
shap-scorer）从 Partition 2 拉取消息。 - Consumer 调用 SHAP 模型计算评分，将结果写入
shap-responsesTopic。 - 结果推送服务（另一个 Consumer）消费
shap-responses，将评分返回给前端。
性能指标参考：
- 单 Partition 吞吐量：约 10 MB/s（机械硬盘）~ 100 MB/s（SSD）
- Producer 批量大小：建议 16 KB ~ 64 KB
- Consumer 拉取频率：建议 100 ms ~ 500 ms
- 副本数：生产环境建议 3 副本