Controller 与元数据管理

从一次故障复盘开始

第 09 篇的实验:停掉 kafka-0,几秒后 Partition 0 的 Leader 从 0 自动换成 1.把这"几秒"拆开,背后是一连串动作:

kafka-0 宕机
    │
    ▼
1. 故障检测:谁发现 kafka-0 不再心跳?
    │
    ▼
2. 决策:盘点 kafka-0 上所有 Leader 分区,从各自 ISR 选新 Leader
    │      (选举规则是第 09 篇讲的:只从 ISR 选)
    │
    ▼
3. 通知:新 Leader 接到上岗通知,开始接收写入
    │
    ▼
4. 广播:所有 Broker 和客户端更新"谁是 Leader"的地图

这四步必须由同一个角色来做.如果各 Broker 自行其是,可能两个 Broker 同时认为自己是 P0 的 Leader——脑裂:两边都收写入,数据分叉,这是分布式系统最怕的结局.

集群需要一个单一决策者:Controller.

Controller 是什么

一句话定义:Controller 是集群中某个 Broker 兼任的特殊角色,同一时刻集群里只有一个 active controller.它不存业务数据,只做两件事:决策与通知.

职责全景:

注意角色叠加:一台 Broker 可能同时是全局 Controller、P0 的 Leader、P1 的 Follower.三个维度互不冲突,只是同一进程承担了多份职责.

元数据:Controller 的依据和产物

Controller 决策的依据、决策后的产物,都是元数据——集群状态的全局地图:

元数据 = {
  brokers: [0, 1, 2],
  topics: {
    "order-events": [
      partition 0 → leader=1, isr=[1,2],
      partition 1 → leader=2, isr=[2,0],
      ...
    ]
  }
}

它有两个消费方:

客户端的行为在第 02 篇见过:Producer 发消息前先通过 metadata 知道目标 Partition 的 Leader 在哪.这套机制的细节:

• 定期刷新:metadata.max.age.ms,默认 5 分钟
• 错误触发:请求打到旧 Leader 收到 NotLeader 错误,立即刷新 metadata 并重试,这是主力路径
• 不依赖 Controller 存活:客户端连的是任意 Broker,不是 Controller

老架构:ZooKeeper 模式

ZooKeeper(下文简称 ZK)是独立的分布式协调服务,提供树形数据存储、临时节点(会话断开自动消失)、watch(变更通知).Kafka 用了几十年,直到被 KRaft 取代.

ZK 里存了什么

/brokers/ids/0                    ← Broker 0 注册的临时节点,会话断开即消失
/brokers/ids/1                    ← Broker 1 的节点
/brokers/topics/order-events/partitions/0/state
                                  ← P0 的 leader / isr 信息
/controller                       ← 谁是 Controller(临时节点,抢建)

Controller 选举:抢临时节点

所有 Broker 抢着创建 /controller 临时节点,谁先创建成功谁当 Controller.临时节点绑定创建者的会话:Controller 宕机,会话结束,节点自动消失,其余 Broker 通过 watch 察觉到,再次开抢.

为什么被淘汰

新架构:KRaft 模式

KRaft(Kafka Raft)把元数据搬回 Kafka 自己手里.时间线:

新集群一律 KRaft,没有例外.

核心变化

元数据不再放 ZK,而是存进 Kafka 自己的内部日志 __cluster_metadata,用 Raft 共识协议复制到专门的 controller 节点上:

KRaft 集群两类角色(可合一):

controller 节点: 只存元数据日志,3-5 个组成 quorum
broker 节点:     存业务数据(Partition)

combined 模式:一台机器同时兼两角 ← 第 07 篇的 docker-compose 就是这个

Controller 选举:Raft 协议

quorum 内部走 Raft 选举,选出 metadata leader,它同时就是 active controller.因为元数据日志已经复制到 quorum 所有成员,新 Leader 无需从外部加载任何状态,秒级接任——这正是 ZK 模式"切换慢"的解药.

两代架构对比

回看第 07 篇 compose 的参数,现在都能对上号:

KAFKA_CFG_PROCESS_ROLES=broker,controller        # combined 模式
KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@kafka-0:9093,1@kafka-1:9093,2@kafka-2:9093
                                                 # quorum 三成员
KAFKA_CFG_LISTENERS=...,CONTROLLER://:9093       # quorum 间通信端口

合起来:Leader 换人的完整流程

第 09 篇讲了选举规则(只从 ISR 选、截断到 HW),本篇补上"谁来执行".KRaft 模式下完整链路:

Broker 0 宕机
      │
      ▼ 心跳超时(broker 定期向 controller 报活)
Controller: 标记 Broker 0 下线
      │
      ▼
盘点 Broker 0 上的 Leader 分区,逐个处理:
      │
      ▼ P0:ISR=[0,1,2] → 移除 0 → 从 [1,2] 选新 Leader(规则见第 09 篇)
通知:向 Broker 1, 2 发 LeaderAndIsr 请求
      │
      ▼
更新元数据,广播给所有 Broker
      │
      ▼
客户端:写旧 Leader 收到 NotLeader 错误 → 立即刷新 metadata → 连新 Leader

客户端这条链路值得单独强调:5 分钟定期刷新只是兜底,真正让故障在秒级恢复的是错误触发.对幂等 Producer,这次"失败 + 重试"不会产生重复消息(第 03 篇讲过 PID + Seq 去重),所以链路里没有消息丢失也没有重复.

动手验证

环境沿用第 07 篇的 compose(3 个 combined 节点).找当前 Controller:

docker compose exec kafka-0 bash

# 查看 quorum 状态,LeaderId 就是 active controller
kafka-metadata-quorum.sh --describe --status --bootstrap-server localhost:19092

ClusterId:              local-kraft-cluster-001
LeaderId:               1
LeaderEpoch:            7
HighWatermark:          1442
MaxFollowerLag:         0
MaxFollowerLagTimeMs:   0
CurrentVoters:          [0,1,2]
CurrentObservers:       []

• CurrentVoters=[0,1,2]:quorum 的三个成员
• LeaderId=1:kafka-1 在当 active controller
• HighWatermark:元数据日志的长度,每次 Topic 增删、Leader 变更都会增长

验证切换:

# 停掉当前 controller
docker compose stop kafka-1

# 进 kafka-0 再查:LeaderId 已换成 0 或 2,LeaderEpoch 加一
docker compose exec kafka-0 bash
kafka-metadata-quorum.sh --describe --status --bootstrap-server localhost:19092

# 期间开一个消费者持续消费,验证读写不受影响
docker compose start kafka-1

生产注意事项

下一篇进入分区再平衡深入:第 04 篇只讲了 rebalance 的概念与两种协议的外在表现,下篇拆开 Eager 与 Cooperative 的实现细节、sticky assignor 的分配算法,以及频繁 rebalance 的排查思路.