2. Confluent Kafka核心架构与关键概念

Confluent Kafka 的架构可以理解为“一条可持久化的分布式提交日志”加上“围绕这条日志的读写、复制与协调机制”。要真正读懂它，需要把 Broker、Topic、Partition、Replica、Producer、Consumer、Consumer Group、Offset、Controller 以及 KRaft/ZooKeeper 这些概念串成一张完整的图，而不是孤立记忆名词。

Broker、Topic 与 Partition：数据放在哪里

Broker 是 Kafka 集群中的一个服务进程，负责接收生产者写入、向消费者提供读取，并把消息持久化到本地磁盘。多个 Broker 组成集群，每个 Broker 用唯一的 broker.id 标识。Topic 是逻辑上的消息分类，例如 orders、payments、user-events。但 Topic 本身不是存储单元，它被切分为若干 Partition，Partition 才是真正有序、可追加、可复制的日志文件。

每个 Partition 内部的消息按写入顺序分配一个单调递增的编号，这个编号就是 Offset。Offset 只在单个 Partition 内有意义，跨 Partition 不保证全局顺序。因此，如果业务要求同一订单的事件严格有序，就必须让相同订单号的消息进入同一个 Partition，通常通过消息 Key 的哈希值取模来实现：partition = hash(key) % partitionCount。若 Key 为 null，则默认使用粘性分区策略，在批次内尽量填满一个分区后再切换。

Partition 数量决定了 Topic 的并行度上限。一个 Partition 在同一时刻只能被同一个 Consumer Group 内的一个 Consumer 消费，所以 Consumer 数量超过 Partition 数量时，多出的 Consumer 会处于空闲状态。示例：某 Topic 设置 6 个 Partition，Consumer Group 中有 8 个 Consumer，则只有 6 个 Consumer 能分到 Partition，另外 2 个闲置。这是容量规划中必须提前计算的关系。

Replica：副本与高可用

每个 Partition 可以配置多个 Replica，副本因子 replication.factor 决定副本总数。副本分为 Leader 和 Follower：Producer 和 Consumer 只与 Leader 交互，Follower 持续从 Leader 拉取消息保持同步。当 Leader 所在 Broker 故障时，Controller 会从同步副本集合 ISR（In-Sync Replicas）中选出一个新 Leader，从而保证可用性。

ISR 是理解 Kafka 可靠性的关键。只有与 Leader 保持同步的副本才在 ISR 中。如果 Follower 落后超过 replica.lag.time.max.ms（默认 30000ms），就会被移出 ISR。生产端通过 acks 参数控制确认级别：acks=0 不等待确认，吞吐最高但可能丢消息；acks=1 只等 Leader 写入；acks=all 等待 ISR 中所有副本确认，配合 min.insync.replicas 可显著提升持久性。例如设置 replication.factor=3、min.insync.replicas=2、acks=all，则至少两个副本写入成功才返回确认，可容忍一个副本故障而不丢已确认消息。

Producer、Consumer 与 Consumer Group

Producer 负责将消息发送到指定 Topic。它先经过序列化器把对象转成字节数组，再由分区器决定目标 Partition，最后按批次发送到对应 Leader。关键参数包括 bootstrap.servers、key.serializer、value.serializer、acks、retries、linger.ms 和 batch.size。其中 linger.ms 与 batch.size 共同影响吞吐与延迟：增大 linger 可让更多消息合并成批，提高吞吐，但会增加发送延迟。

Consumer 通过 subscribe() 订阅 Topic，并以 Consumer Group 为单位协调消费。同一 Group 内，每个 Partition 只会分配给一个 Consumer；不同 Group 之间互不影响，可以各自独立消费同一 Topic。这就是 Kafka 支持“一份数据、多路消费”的基础。Consumer 需要提交 Offset 来记录消费进度，提交方式分为自动提交和手动提交。手动提交更可控，通常在业务处理成功后再调用 commitSync() 或 commitAsync()，避免“先提交后处理失败”导致消息丢失。

再均衡 Rebalance 是 Consumer Group 的重要行为：当 Consumer 加入、离开或 Partition 数量变化时，Group 会重新分配 Partition。再均衡期间消费会短暂停顿，因此生产环境应尽量使用静态成员 group.instance.id 或合作式再均衡策略来减少影响。

Controller 与 KRaft / ZooKeeper 模式对比

Controller 是集群中的特殊 Broker，负责 Partition Leader 选举、副本分配、Topic 创建删除等元数据管理。在传统 ZooKeeper 模式下，Controller 由 ZooKeeper 选举产生，元数据存放在 ZooKeeper 中；Broker 需要同时连接 ZooKeeper 和 Controller。而在 KRaft 模式下，Kafka 自身通过 Raft 协议管理元数据，Controller 节点组成 Controller Quorum，不再依赖 ZooKeeper。KRaft 的优势是架构更简单、元数据恢复更快、支持更大规模 Partition，并且是 Confluent 新版本推荐模式。

Confluent Kafka 核心架构关系图 Producer 序列化 + 分区器 Consumer Group 多 Consumer 并行消费 Kafka Cluster（Broker 集群） Broker 1（id=1） Topic: orders P0 Leader P1 Follower Topic: payments P0 Follower P1 Leader Broker 2（id=2） Topic: orders P0 Follower P1 Leader Topic: payments P0 Leader P1 Follower Controller（元数据与 Leader 选举） Partition 分配 · ISR 管理 · Topic 变更 KRaft 模式（推荐） Controller Quorum 自管理元数据 无 ZooKeeper · 恢复快 · 规模大 ZooKeeper 模式（传统） ZK 选举 Controller · 存元数据 Broker 需同时连 ZK 与 Controller 写入 拉取 管理 Offset Partition 内单调递增 消费进度提交点 跨分区不保证顺序

关键参数与判断依据

在实际部署中，以下参数关系决定了系统的可靠性与吞吐表现，建议结合业务目标逐项确认：

参数 作用 示例值 判断依据
replication.factor 副本总数 3 可容忍 2 个副本故障，生产环境通常 ≥3
min.insync.replicas 最小同步副本数 2 配合 acks=all，保证至少 2 副本写入成功
acks 生产确认级别 all 可靠性优先；若追求吞吐可降为 1
partitions 分区数量 6 决定并行度上限，需 ≥ 峰值 Consumer 数
linger.ms 发送前等待时间 20 增大可提升批量吞吐，但增加延迟
enable.auto.commit 自动提交 Offset false 手动提交更可控，避免处理失败却已提交
判断集群是否健康，可以观察三个信号：ISR 是否频繁收缩、Consumer Group 的 Lag 是否持续增长、Controller 是否频繁切换。若 ISR 反复缩小，说明副本同步跟不上，应检查 Broker 磁盘 I/O 与网络；若 Lag 持续上升，说明消费能力不足，需要增加 Consumer 或 Partition；若 Controller 频繁切换，则要排查 Broker 稳定性与元数据压力。

最后需要强调：Partition 是 Kafka 并行与顺序的基本单位，Replica 是可靠性的基本单位，Consumer Group 是消费扩展的基本单位，Offset 是进度控制的基本单位，Controller 是元数据协调的基本单位。把这五个“基本单位”与 KRaft/ZooKeeper 的元数据管理方式放在一起理解，就抓住了 Confluent Kafka 架构的主干。

← 上一章 📖 返回目录 下一章 →