Kafka 学习笔记 #0

在 Kafka 的架构中，Broker、Partition 和 Replica 是构建其高吞吐量、可扩展性和高可用性的三大核心基石。

简而言之，它们的关系可以用一句话概括：一个 Topic（主题）被划分为多个 Partition，每个 Partition 拥有多个 Replica（分为 Leader 和 Follower），而这些紧紧跟上 Leader 步伐的 Replica 共同组成了 ISR 列表，它们被分散存储在不同的 Broker 上。

为了更清晰地理解，我们可以从它们各自的定位以及它们之间的相互作用来拆解：

1. 核心概念拆解

  • Broker（节点/服务器）—— 物理载体

    • 定义： 它是 Kafka 集群中的一台独立的物理机或虚拟机。多个 Broker 组合在一起形成一个完整的 Kafka 集群。
    • 作用： 负责接收和处理客户端（Producer/Consumer）的请求，并将消息持久化到本地磁盘。

  • Partition（分区）—— 水平扩展的利器

    • 定义： Kafka 中的消息是按 Topic 分类的，而一个 Topic 在物理上会被分成一个或多个 Partition。它是一个有序的、不可变的消息序列。
    • 作用： 主要为了并发和横向扩展。如果一个 Topic 的所有数据都放在一台机器上，吞吐量必然受限。通过切分成多个 Partition 并分布到多台 Broker 上，就可以让多个客户端并发地进行读写操作。

  • Replica（副本）—— 高可用的保障

    • 定义： 为了防止数据丢失，Kafka 会对每个 Partition 生成多个备份，这些备份统称为 Replica。
    • 作用： 主要为了容灾和高可用。Replica 有明确的角色分工：
      • Leader Replica（主副本）： 唯一负责处理该 Partition 所有读写请求的副本。
      • Follower Replica（从副本）： 不处理客户端请求，只被动且默默地从 Leader 拉取数据进行同步。当 Leader 挂掉时，某个 Follower 会被选举为新的 Leader。
      • ISR (In-Sync Replicas，同步副本集合)： 这是一个动态维护的“白名单”，包含了当前所有与 Leader 保持高度同步的 Replica（Leader 自身也在此列）。如果某个 Follower 因为网络延迟或宕机掉队太久，Leader 就会将其无情剔除出 ISR 列表，直到它重新追上进度。

2. 三者的空间与逻辑关系

它们之间的分布和制约关系是 Kafka 稳定运行的关键：

  • Replica 是挂载在 Partition 下的： 副本的单位是 Partition，而不是 Topic 整体。我们在配置 Kafka 副本因子（replication-factor）时，实际上是在规定每个 Partition 有几个 Replica。
  • 同一个 Partition 的不同 Replica 必须分布在不同的 Broker 上： 这是容灾的底线。如果一个 Partition 的 Leader 和 Follower 都在同一个 Broker 上，一旦这台 Broker 宕机，该 Partition 的所有数据和副本将同时不可用，失去备份的意义。
  • 一个 Broker 上会承载大量的 Replica： 一台 Broker 通常会存储成百上千个 Replica。这些 Replica 分属于不同的 Topic 和不同的 Partition。其中一部分是 Leader 角色，另一部分是 Follower 角色，以此来实现整个集群的负载均衡。

举个例子： 假设你有一个拥有 3 台 Broker 的集群，创建了一个名为 Orders 的 Topic，设置了 3 个 Partition（P0, P1, P2），并且副本因子设定为 2（即每个 Partition 有 1 个 Leader 和 1 个 Follower）。

其分布可能如下：

  • Broker 1: P0 (Leader), P2 (Follower)
  • Broker 2: P1 (Leader), P0 (Follower)
  • Broker 3: P2 (Leader), P1 (Follower)

此时，如果 Broker 1 彻底宕机，P0 的 Follower 还在 Broker 2 上，可以立刻被从 ISR 列表中提拔为新的 Leader，系统依然能正常运转。

3. 实战串联：数据一致性的守门员 (acks=all)

理解了上述层级关系，就能明白 Kafka 生产者中最重要的参数 acks 是如何工作的。

核心原则： “要求 Leader 收到消息，且所有的 ISR（同步副本）都同步成功后，才给生产者返回成功响应。”

当生产者配置参数为 acks=all（或 acks=-1）时，其底层运转逻辑如下：

  1. 生产者将消息发送给目标 Partition 的 Leader Replica 所在的 Broker。
  2. Leader 将消息写入本地磁盘。
  3. Leader 盯住自己的 ISR 列表，等待列表中的所有 Follower Replica 从自己这里拉取并写入这条消息。
  4. 只有当 ISR 列表中的所有 Follower 都向 Leader 汇报“已同步成功”后，Leader 才会向生产者返回成功响应。

💡 笔记避坑指南：acks=1 与 acks=all 的区别

  • acks=all (或 -1)：等待 Leader 和所有 ISR 同步完成。保证最高的数据安全性。
  • acks=1：只需 Leader 自己写入本地成功，就直接向生产者返回成功，不等待任何 Follower（ISR）同步。如果此时 Leader 刚写完就宕机，而 Follower 还没来得及同步，数据就会丢失。