2. Kafka 核心架构回顾：Broker、Topic、Partition、Producer、Consumer、ZooKeeper/KRaft 角色与交互流程
在深入版本回滚与故障定位之前，必须重新梳理 Kafka 的核心架构。Kafka 是一个分布式、分区化、多副本的发布-订阅消息系统。其核心角色包括 Broker、Topic、Partition、Producer、Consumer 以及元数据协调服务（传统 ZooKeeper 或新版 KRaft）。理解这些角色的职责与交互流程，是进行契约测试和故障诊断的基础。
2.1 核心角色与职责
| 角色 | 职责描述 | 关键特性 |
|---|---|---|
| Broker | Kafka 集群中的单个服务器节点，负责存储消息、处理客户端请求、管理分区副本。 | 无状态（依赖外部元数据）、通过分区 Leader/Follower 实现高可用。 |
| Topic | 消息的逻辑分类，类似于数据库中的表。一个 Topic 可被多个 Consumer 订阅。 | 支持多订阅者、持久化、可配置保留策略。 |
| Partition | Topic 的物理分片，每个 Partition 是一个有序、不可变的消息日志（Log）。 | 并行处理的基本单位；每个 Partition 有唯一的 Leader 和多个 Follower。 |
| Producer | 消息生产者，负责将消息发布到指定的 Topic 和 Partition。 | 可指定分区策略（轮询、哈希、自定义）；支持同步/异步发送。 |
| Consumer | 消息消费者，从 Broker 拉取消息进行处理。通常以 Consumer Group 形式运行。 | 每个 Partition 只能被同一个 Group 内的一个 Consumer 消费；支持 offset 提交。 |
| ZooKeeper / KRaft | 元数据管理服务。ZooKeeper 管理 Broker 注册、Topic 配置、Controller 选举；KRaft 是 Kafka 自研的替代方案，去除了外部依赖。 | ZooKeeper 是强一致性协调器；KRaft 基于 Raft 协议，简化运维。 |
契约测试视角： 在版本回滚场景中，Broker 与 ZooKeeper/KRaft 之间的元数据交互协议（如 RegisterBroker、UpdateMetadata）是契约测试的重点。不同版本的 Kafka 可能修改了这些 RPC 的字段或语义，导致回滚后元数据不一致。
2.2 核心交互流程
Kafka 的读写流程围绕 Partition Leader 展开。Producer 和 Consumer 只与 Partition 的 Leader 副本交互，Follower 副本负责从 Leader 同步数据以提供容错。
2.2.1 消息写入流程（Producer → Broker）
- 元数据请求： Producer 向任意 Broker 发送 MetadataRequest，获取目标 Topic 的 Partition 元数据（Leader 所在的 Broker ID、ISR 列表等）。
- 分区选择： Producer 根据分区策略（如 key 哈希）确定目标 Partition。
- 发送 ProduceRequest： Producer 向 Partition Leader 所在的 Broker 发送 ProduceRequest，包含消息集。
- 写入与复制： Leader 将消息追加到本地 Log，并等待所有 ISR（In-Sync Replicas）中的 Follower 确认（acks 配置决定等待数量）。
- 响应： Leader 向 Producer 返回响应，包含消息的 offset 和写入状态。
2.2.2 消息消费流程（Consumer → Broker）
- 加入组与分区分配： Consumer 向 Group Coordinator（某个 Broker）发送 JoinGroup 请求，Coordinator 执行分区分配策略（如 RangeAssignor、RoundRobinAssignor）。
- 获取分区 Leader： Consumer 向任意 Broker 发送 MetadataRequest，获取其负责分区的 Leader 信息。
- 发送 FetchRequest： Consumer 向 Partition Leader 发送 FetchRequest，携带要拉取的 offset 和最大字节数。
- 拉取消息： Leader 从本地 Log 中读取消息并返回给 Consumer。
- 提交 Offset： Consumer 处理完消息后，向 __consumer_offsets 主题发送 OffsetCommitRequest，记录消费进度。
2.3 ZooKeeper 与 KRaft 的角色对比
| 维度 | ZooKeeper 模式 | KRaft 模式（Kafka Raft） |
|---|---|---|
| 元数据存储 | 存储在 ZooKeeper 中（如 /brokers/ids、/topics） | 存储在 Kafka 内部的 __cluster_metadata 主题中 |
| Controller 选举 | 依赖 ZooKeeper 的临时节点与 Watcher 机制 | 基于 Raft 协议，在 Controller Quorum 中选举 |
| 外部依赖 | 强依赖 ZooKeeper 集群 | 无外部依赖，Kafka 自身管理元数据 |
| 版本回滚影响 | ZooKeeper 数据结构可能不兼容（如 znodes 路径变更） | 元数据主题的日志格式可能不兼容，回滚风险更高 |
| 运维复杂度 | 需要额外维护 ZooKeeper 集群 | 运维简化，但元数据迁移路径复杂 |
版本回滚风险提示： 从 KRaft 模式回滚到 ZooKeeper 模式通常不被官方支持，因为元数据存储格式完全不同。在规划回滚策略时，必须确认目标版本与当前版本的元数据管理方式是否兼容。
2.4 架构交互总览
下图展示了 Kafka 集群中 Producer、Consumer、Broker、Partition 以及元数据服务之间的核心交互关系。注意，在 KRaft 模式下，Controller 角色由 Kafka Broker 承担，不再需要独立的 ZooKeeper 集群。
2.5 分区副本与 ISR 机制
每个 Partition 可以有多个副本（Replica），其中一个是 Leader，其余是 Follower。Follower 会持续从 Leader 拉取消息以保持同步。只有与 Leader 保持同步的副本才属于 ISR（In-Sync Replicas） 集合。当 Leader 宕机时，Controller 会从 ISR 中选举一个新的 Leader。
契约测试关注点： ISR 的变更（如 Follower 同步滞后被踢出 ISR）会触发 LeaderAndIsr 请求。不同版本的 Kafka 对 ISR 的判定阈值（replica.lag.time.max.ms）和请求格式可能不同，回滚后可能导致 Leader 选举异常或数据丢失。
2.6 关键交互协议清单
以下协议是 Kafka 内部通信的核心，也是版本回滚时最容易出现兼容性问题的部分：
| 协议名称 | 方向 | 用途 | 版本回滚风险 |
|---|---|---|---|
| MetadataRequest / Response | Client ↔ Broker | 获取 Topic 分区元数据 | 高：字段增减可能导致解析失败 |
| ProduceRequest / Response | Producer → Broker | 写入消息 | 中：消息格式或压缩类型变更 |
| FetchRequest / Response | Consumer → Broker | 拉取消息 | 中：offset 或分区状态字段变更 |
| OffsetCommitRequest / Response | Consumer → Broker | 提交消费进度 | 高：__consumer_offsets 主题格式变更 |
| LeaderAndIsrRequest / Response | Controller → Broker | 通知分区 Leader 和 ISR 变更 | 高：副本状态机逻辑不兼容 |
| UpdateMetadataRequest / Response | Controller → Broker | 广播元数据变更 | 高：元数据缓存结构差异 |