3. Kafka集群架构：多Broker部署、Controller选举机制、ZooKeeper/KRaft的角色与演进
3.1 多Broker部署模型
Kafka集群由多个Broker（服务器节点）组成，每个Broker负责存储部分分区的数据副本。多Broker部署是Kafka高可用的基础，通过冗余副本和故障转移机制，确保在部分节点失效时服务不中断。
核心设计原则： 集群中Broker数量至少为3，且副本因子（replication-factor）通常设置为3，以保证多数副本可用。
3.1.1 多Broker架构图
3.1.2 分区副本与Leader/Follower机制
| 角色 | 职责 | 高可用作用 |
|---|---|---|
| Leader | 处理分区的所有读写请求 | 单点故障时由Controller重新选举 |
| Follower | 从Leader同步数据，不对外提供服务 | Leader宕机后成为新Leader候选 |
| ISR (In-Sync Replicas) | 与Leader保持同步的副本集合 | 只有ISR中的副本才能被选举为Leader |
生产建议： 设置
min.insync.replicas=2，配合 acks=all，确保写入至少2个副本成功才返回确认，避免数据丢失。
3.2 Controller选举机制
Controller是Kafka集群的“大脑”，负责管理分区Leader选举、Broker上下线处理、元数据变更等核心任务。集群中只有一个Controller，由所有Broker通过ZooKeeper或KRaft协议选举产生。
3.2.1 Controller选举流程
3.2.2 Controller职责清单
- 分区Leader选举： 当Broker宕机或分区Leader失效时，Controller从ISR中选举新的Leader
- Broker上下线管理： 监听ZooKeeper的Broker节点变化，触发重分配
- 元数据广播： 将集群元数据变更（分区分配、Leader变更等）推送给所有Broker
- 分区重分配： 执行管理员触发的分区迁移或扩缩容操作
注意： Controller本身是单点，但通过ZooKeeper的临时节点机制实现快速故障转移。Controller宕机后，其他Broker会在几秒内完成重新选举。
3.3 ZooKeeper与KRaft的角色与演进
Kafka早期版本依赖ZooKeeper管理集群元数据和Controller选举。从Kafka 2.8开始引入KRaft（Kafka Raft）模式，逐步摆脱对ZooKeeper的依赖，实现完全自管理的元数据架构。
3.3.1 ZooKeeper模式 vs KRaft模式对比
| 对比维度 | ZooKeeper模式 | KRaft模式 |
|---|---|---|
| 元数据存储 | 存储在ZooKeeper中 | 存储在Kafka内部Topic（__cluster_metadata） |
| Controller选举 | 通过ZooKeeper临时节点竞争 | 通过Raft协议选举 |
| 组件数量 | Kafka + ZooKeeper集群（至少3个ZK节点） | 仅Kafka集群 |
| 运维复杂度 | 高，需同时管理Kafka和ZooKeeper | 低，单一集群管理 |
| 性能 | 元数据操作受ZK性能限制 | 元数据操作更快，支持更多分区 |
| 成熟度 | 生产级，广泛使用 | 从Kafka 3.3起生产可用，持续演进 |
3.3.2 KRaft架构图
3.3.3 演进路线与迁移建议
演进路线： ZooKeeper模式（0.8~2.7）→ 双模式支持（2.8~3.2）→ KRaft生产可用（3.3+）→ 未来完全移除ZooKeeper
3.3.4 迁移到KRaft的步骤
- 版本升级： 先将Kafka集群升级到3.3或更高版本
- 启用KRaft： 配置
process.roles=broker,controller或分离角色部署 - 元数据迁移： 使用
kafka-storage.sh工具将ZooKeeper中的元数据迁移到KRaft - 验证与切换： 逐步将流量切换到KRaft集群，监控元数据一致性
生产建议： 对于新集群，直接使用KRaft模式；对于现有ZooKeeper集群，建议在充分测试后再迁移，优先在非核心业务环境验证。
3.4 微服务链路中的集群高可用设计要点
在微服务架构中，Kafka集群的高可用设计直接影响整个链路的稳定性。以下是关键设计原则：
- Broker冗余： 至少3个Broker，分布在不同的物理机或可用区
- 副本因子： 关键Topic设置 replication-factor=3，min.insync.replicas=2
- Controller高可用： 确保Controller快速选举，避免长时间无主
- 元数据一致性： 使用KRaft模式减少外部依赖，降低故障点
- 监控与告警： 监控UnderReplicatedPartitions、ActiveControllerCount等关键指标
常见陷阱： 微服务中多个服务共享同一个Topic时，需注意分区数设计，避免单分区成为瓶颈。建议根据服务数量合理设置分区数（通常为Broker数量的2~3倍）。