2. Kafka 核心架构：集群、Broker、Topic、Partition、Replica 与 Zookeeper 角色
Kafka 的架构设计围绕“分布式日志”这一核心思想展开。理解其六大核心组件——集群、Broker、Topic、Partition、Replica 与 Zookeeper——是掌握消息契约版本管理与校验的基础。下面通过一张架构总览图与逐层拆解，帮你建立完整的认知模型。
2.1 核心组件定义与职责
下表从“是什么”和“做什么”两个维度，快速对齐六个核心概念。
| 组件 | 定义 | 核心职责 |
|---|---|---|
| Kafka 集群 | 由多个 Broker 实例组成的分布式系统 | 统一对外提供消息读写服务；通过选举实现高可用 |
| Broker | Kafka 服务进程，每个节点一个 Broker | 存储 Partition 数据；处理生产/消费请求；参与选举 |
| Topic | 消息的逻辑分类名称 | 定义数据流边界；契约版本绑定在 Topic 级别 |
| Partition | Topic 的物理分片，每个 Partition 是一个有序日志 | 提供并行读写能力；消息顺序只在 Partition 内保证 |
| Replica | Partition 的副本，分为 Leader 和 Follower | Leader 处理读写；Follower 同步备份；故障时自动切换 |
| Zookeeper | 分布式协调服务 | 存储集群元数据；选举 Controller；管理 Broker 上下线 |
契约视角：Topic 是契约版本管理的锚点。每个 Topic 可以绑定一个 Schema Registry 或契约文件，Partition 只是物理承载，不感知契约内容。
2.2 Broker 与集群工作机制
一个 Kafka 集群通常包含 3 个或更多 Broker。每个 Broker 拥有唯一 ID，启动时向 Zookeeper 注册临时节点。集群通过 Controller（由 Zookeeper 选举产生）负责 Partition 的 Leader 分配与重平衡。
- Leader 与 Follower：每个 Partition 有 1 个 Leader 和 N 个 Follower。Leader 负责所有读写请求，Follower 从 Leader 拉取数据保持同步。
- ISR（In-Sync Replica）：与 Leader 保持同步的副本集合。只有 ISR 中的副本才有资格被选举为新的 Leader。
- 故障恢复：当 Leader 宕机时，Controller 从 ISR 中选举一个新 Leader，集群继续提供服务。
生产建议：副本因子（replication.factor）通常设为 3，最小 ISR 设为 2，在可用性与一致性之间取得平衡。
2.3 Topic 与 Partition 的映射关系
Topic 是逻辑概念，Partition 是物理存储单元。创建 Topic 时需指定 Partition 数量，该数量决定了 Topic 的最大并行度。
注意：Partition 数量一旦创建，只能增加不能减少。过多 Partition 会增加 Zookeeper 元数据压力与 Leader 选举开销，建议根据预期吞吐量合理规划。
2.4 Replica 与数据一致性保障
Replica 机制是 Kafka 高可用的基石。每个 Partition 的副本分布在不同的 Broker 上，确保单点故障时数据不丢失。
| 副本角色 | 位置 | 读写权限 | 故障行为 |
|---|---|---|---|
| Leader | 每个 Partition 唯一 | 读写 | 宕机后由 Controller 从 ISR 选举新 Leader |
| Follower | 分布在其他 Broker | 只读（仅同步） | 落后太多时被踢出 ISR；恢复后重新加入 |
| ISR | Leader + 同步及时的 Follower | — | ISR 大小影响可用性；min.insync.replicas 控制写入容忍度 |
2.5 Zookeeper 在 Kafka 中的角色
Zookeeper 是 Kafka 集群的“大脑”，负责以下关键任务：
- 元数据存储：记录 Broker 列表、Topic 配置、Partition 分配信息。
- Controller 选举：第一个启动的 Broker 成为 Controller，负责 Partition 的 Leader 分配与重平衡。
- Broker 上下线感知：通过临时节点监听 Broker 心跳，故障时触发重平衡。
- 消费者组协调：记录消费者组偏移量（旧版本）与组成员信息。
版本演进：Kafka 2.8+ 开始支持基于 Raft 的 KRaft 模式，逐步摆脱对 Zookeeper 的依赖。但在生产环境中，Zookeeper 模式仍占主流，理解其角色对排查集群问题至关重要。
2.6 架构总结与契约校验的关联
Kafka 的架构设计直接决定了契约校验的实施方式：
- Topic 是契约锚点：每个 Topic 绑定一个契约版本，生产者与消费者通过 Topic 名称隐式约定消息格式。
- Partition 提供并行校验：不同 Partition 可以独立进行契约校验，不影响其他分片的吞吐。
- Replica 保证校验元数据不丢失：契约版本信息可以存储在 Zookeeper 或外部 Registry 中，利用副本机制保障高可用。
- Broker 作为校验执行点：可以在 Broker 侧或客户端侧嵌入契约校验逻辑，拦截不兼容消息。