2. Kafka核心架构：Kafka集群、Broker、Topic、Partition、Replica、Leader/Follower
Kafka的架构设计围绕“分布式日志”这一核心思想展开。理解其核心组件及它们之间的协作关系，是掌握Kafka领域边界的基础。本章将逐一拆解Kafka集群、Broker、Topic、Partition、Replica以及Leader/Follower机制。
2.1 核心组件概览
Kafka的架构可以抽象为三层：集群层、存储层和冗余层。下表总结了各组件在架构中的角色与职责：
| 组件 | 所属层级 | 核心职责 | 关键特征 |
|---|---|---|---|
| Kafka集群 | 集群层 | 提供统一的消息服务入口，管理多个Broker | 分布式、高可用、可水平扩展 |
| Broker | 集群层 | 消息存储与转发节点，集群中的一台服务器 | 无状态（依赖ZooKeeper/KRaft）、可独立运行 |
| Topic | 存储层 | 消息的逻辑分类，类似数据库中的表 | 一对多映射到Partition |
| Partition | 存储层 | 消息的物理存储单元，实现并行读写 | 有序、不可变、可追加 |
| Replica | 冗余层 | Partition的副本，保证数据不丢失 | Leader/Follower角色分离 |
| Leader/Follower | 冗余层 | 定义副本的读写权限与数据同步机制 | Leader处理读写，Follower同步 |
2.2 集群与Broker：分布式基石
一个Kafka集群由多个Broker实例组成。每个Broker是一个独立的进程，运行在一台物理机或容器上。集群通过ZooKeeper（或KRaft模式下的内部共识协议）进行协调，完成以下任务：
- Controller选举：集群中有一个Broker被选举为Controller，负责管理分区和副本的状态。
- 元数据管理：记录Topic、Partition、Replica的分配信息。
- 故障检测：监控Broker心跳，触发Leader重新选举。
架构要点：Broker是无状态的，这意味着它不持久化任何元数据。所有集群状态都存储在ZooKeeper或KRaft日志中。这使得Broker可以随时重启或替换，而不会丢失集群的拓扑信息。
2.3 Topic与Partition：逻辑与物理的分离
Topic是消息的逻辑分类。生产者将消息发送到特定的Topic，消费者从Topic订阅消息。但Topic本身并不存储消息，它只是一个逻辑容器。
每个Topic被切分为一个或多个Partition。Partition是Kafka并行处理的核心：
- 物理存储：每个Partition对应一个日志文件（Log），消息按顺序追加到文件末尾。
- 并行度：一个Partition只能被同一个消费者组内的一个消费者消费，因此Partition数量决定了消费的并行度。
- 有序性：消息在Partition内部是有序的，但跨Partition不保证全局有序。
下图展示了Topic与Partition在集群中的分布关系：
2.4 Replica与Leader/Follower：数据冗余与一致性
为了保障高可用，每个Partition可以配置多个Replica（副本）。副本因子（replication-factor）决定了副本数量。副本之间通过Leader/Follower机制协作：
- Leader：每个Partition有且仅有一个Leader。所有生产者和消费者的读写请求都直接发送给Leader。
- Follower：其余副本作为Follower，只负责从Leader拉取数据，保持与Leader的同步。
- ISR（In-Sync Replicas）：与Leader保持同步的Follower集合。只有ISR中的副本才有资格在Leader故障时被选举为新的Leader。
关键设计：Kafka采用“读写分离”但“读写都走Leader”的策略。所有读写请求都集中在Leader上，Follower只做数据同步。这种设计简化了一致性模型，避免了分布式系统中常见的“脑裂”问题。当Leader宕机时，Controller会从ISR中选举一个新的Leader。
下图展示了Leader/Follower之间的数据同步流程：
2.5 副本放置策略与ISR机制
Kafka在分配副本时，会尽量将副本分散到不同的Broker上，以提高容错性。副本放置遵循以下原则：
- 机架感知：如果配置了机架信息，Kafka会确保副本分布在不同的机架上，防止机架级故障。
- Leader优先：在分配Leader时，Kafka会优先选择副本所在的第一个Broker作为Leader。
ISR（In-Sync Replicas）是Kafka保证数据一致性的核心机制。只有满足以下条件的Follower才能加入ISR：
- 与Leader之间的数据滞后不超过
replica.lag.time.max.ms（默认30秒）。 - 与Leader保持活跃的TCP连接。
常见误区：不要将“副本因子”与“ISR大小”混淆。副本因子是静态配置，ISR大小是动态变化的。当Follower同步过慢或宕机时，它会被踢出ISR。此时，如果Leader宕机，只有ISR中的副本才有资格成为新Leader。如果ISR为空，Kafka会等待第一个恢复的副本成为Leader（可能丢失数据），或者根据配置
unclean.leader.election.enable 决定是否允许非ISR副本成为Leader。
2.6 核心配置参数速查
以下是与本章架构相关的关键配置参数：
| 配置项 | 作用域 | 默认值 | 说明 |
|---|---|---|---|
num.partitions |
Topic级别 | 1 | Topic的默认分区数，影响并行度 |
default.replication.factor |
Broker级别 | 1 | 自动创建Topic时的默认副本因子 |
replica.lag.time.max.ms |
Broker级别 | 30000 | Follower超过此时间未同步，将被踢出ISR |
unclean.leader.election.enable |
Broker级别 | false | 是否允许非ISR副本成为Leader（可能导致数据丢失） |
min.insync.replicas |
Topic级别 | 1 | 生产者写入时，至少需要多少个ISR副本确认 |
2.7 架构设计要点总结
- 水平扩展：通过增加Partition和Broker，Kafka可以线性提升吞吐量。
- 高可用：副本因子≥2且ISR机制保证了在Broker故障时，服务不中断。
- 一致性权衡：通过
acks和min.insync.replicas配置，可以在吞吐量和数据可靠性之间做权衡。 - 无状态Broker：Broker本身不存储元数据，简化了运维和故障恢复。