副本机制与 ISR

为什么需要副本

第 08 篇说过,消息一进来就落在 Broker 磁盘.单台 Broker 挂掉,它上面所有分区的数据就没了:

单 Broker 部署:
Broker A 承载 P0, P1, P2
磁盘损坏 → 三个分区的数据全部消失,不可恢复

所以 Kafka 给每个 Partition 配 N 个副本(replication.factor),分散到不同 Broker:

replication.factor = 3:
P0: Leader 在 Broker 0,副本在 Broker 1, Broker 2
P1: Leader 在 Broker 1,副本在 Broker 2, Broker 0
P2: Leader 在 Broker 2,副本在 Broker 0, Broker 1

任何一台 Broker 宕机,每个 Partition 都还有 2 个副本可用

每个 Partition 的副本分两种角色:

读写只走 Leader.这是 Kafka 一致性模型简单的根源:一个分区同一时刻只有一个写者(第 08 篇的单写者模型),不存在多副本写冲突;Consumer 读到的也永远是 Leader 的提交视角.

对比 MySQL 主从,相似但有关键差异:

Follower 怎么同步:拉,不是推

Follower 的同步动作和普通 Consumer 几乎一样:向 Leader 发 FetchRequest,按 offset 拉取:

                    ┌─ Leader 日志 ────────────────┐
                    │ ... [msg-7] [msg-8] [msg-9]  │
                    │                              │
Follower ── FetchRequest(offset=7) ───────────────►│
Follower ◄── FetchResponse(msg-7, msg-8, msg-9) ───┘

两个细节:

1. FetchRequest 携带 follower 自己的 LEO,Leader 据此记录"这个 follower 追到哪了",这是后面 HW 计算的数据来源
2. 没数据时请求挂起等待(第 04 篇 Consumer 的 long poll 是同一机制),新消息一写入立即返回,同步延迟毫秒级

为什么是拉而不是 Leader 推:

已提交的定义:LEO 与 HW

两个水位线

• LEO(Log End Offset):副本"写到哪了",即下一条消息的 offset
• HW(High Watermark):分区"提交到哪了",Consumer 能读到的最大 offset + 1

HW 由 ISR 全体副本的 LEO 决定:

Leader:     [0] [1] [2] [3] [4] [5] [6] [7] [8] [9]     LEO = 10
Follower-1: [0] [1] [2] [3] [4] [5] [6] [7] [8]          LEO = 9
Follower-2: [0] [1] [2] [3] [4] [5] [6]                  LEO = 7
                                                       ▲
                                        HW = min(10, 9, 7) = 7

offset < 7:已提交,Consumer 最多读到 msg-6
offset ≥ 7:未提交,Consumer 不可见

与 acks 参数对账

第 03 篇的 acks 表格,用 LEO/HW 重新解释:

acks=all 等的"ISR 确认",是 follower 下一次 FetchRequest 带来的 LEO 推进,不是 follower 落盘(follower 同样写 page cache,第 08 篇).

HW 的第二个作用:切换时的截断点

Leader 挂掉后,新 Leader 从 ISR 选出,所有副本把日志截断到 HW,丢弃 HW 之后的部分:

旧 Leader 日志: [0..6] [7] [8] [9]       ← 7,8,9 未提交,ISR 没同步完
新 Leader 日志: [0..6] [7]               ← 它是 ISR 成员,至少有到 HW 的数据

截断后,所有副本统一到 HW=7:
新 Leader 日志: [0..6]

为什么截断不心疼:7,8,9 从未提交,Producer 没收到 ack,会重试

这正是第 06 篇"不丢"的存储层保证:acks=all 返回过的消息一定已提交,一定在所有 ISR 副本上,一定不会被截断.

ISR:动态伸缩的同步集合

定义

ISR(In-Sync Replicas)是"与 Leader 保持同步"的副本集合,Leader 永远在 ISR 里.第 07 篇 describe 输出里的 Isr 列就是它.

进出的标准:时间,不是条数

follower 落后超过 replica.lag.time.max.ms(默认 30s)没追上,被 Leader 踢出 ISR:

t=0s:  follower LEO=100, leader LEO=100,同步中
t=30s: follower LEO=100, leader LEO=100500,follower 期间零拉取
       → 踢出 ISR(它还在继续追,追上后自动回来)

为什么用时间阈值而不是"落后 N 条":

老版本确实用过 replica.lag.max.messages(按条数),已被时间阈值取代.

缩容与扩容

ISR=[0,1,2] → follower-2 卡住 30s → ISR=[0,1] → follower-2 追上 → ISR=[0,1,2]

常见触发缩容的场景:

缩容对写入的影响

acks=all 时,Leader 等 ISR 全体确认.ISR 缩容,等待集合跟着变小:

ISR 大小 ≥ min.insync.replicas:  正常写入(甚至少等一个副本,延迟更低)
ISR 大小 < min.insync.replicas:  Leader 拒绝写入,报 NotEnoughReplicas

这是第 06 篇"宁可不可用,也不丢数据"的实现:缩到危险线以下,写入口直接关闭.

Leader 选举与 Unclean Election

正常选举:只从 ISR 里选

Leader 挂掉后,Controller(下一篇的主角)从 ISR 里选一个新 Leader.ISR 里任意副本都满足两个条件:

1. 拥有 HW 之前的所有消息(否则早被踢出)
2. 30s 内同步过,数据最新

ISR 全挂:不干净的选举

极端情况:3 副本,2 台 Broker 同时宕机,只剩一个恰好被踢出 ISR 的落后副本:

replication.factor=3, min.insync.replicas=2

Broker 0: P0 Leader                  ✗ 宕机
Broker 1: P0 follower(ISR)           ✗ 宕机
Broker 2: P0 follower(非ISR,落后 1000 条)  ✓ 活着

ISR 空了,要恢复可用只能选 ISR 外的副本 → unclean election

由 unclean.leader.election.enable 决定(默认 false):

生产建议:保持 false.宁可分区短时不可用,也不静默丢已提交数据.只有"丢数据无所谓,可用性高于一切"的场景(如日志采集)才考虑打开.

动手验证:Leader 切换与 ISR 缩容

环境用第 07 篇的 docker-compose(3 Broker,replication.factor=3,min.insync.replicas=2).

观察 Leader 分布与 ISR

docker compose exec kafka-0 bash

kafka-topics.sh --describe --topic order-events --bootstrap-server localhost:19092

Topic: order-events  PartitionCount: 6  ReplicationFactor: 3
  Partition: 0  Leader: 0  Replicas: 0,1,2  Isr: 0,1,2
  Partition: 1  Leader: 1  Replicas: 1,2,0  Isr: 1,2,0
  Partition: 2  Leader: 2  Replicas: 2,0,1  Isr: 2,0,1
  ...

6 个分区的 Leader 均匀分布在 3 个 Broker 上(第 02 篇讲过的负载均衡).

杀掉 Leader,看自动切换

# Partition 0 的 Leader 在 kafka-0 上,停掉它
docker compose stop kafka-0

# 等 controller 检测到故障(约几秒到十几秒),进 kafka-1 观察
docker compose exec kafka-1 bash
kafka-topics.sh --describe --topic order-events --bootstrap-server localhost:19092

Partition: 0  Leader: 1  Replicas: 0,1,2  Isr: 1,2

Leader 自动换成 1,死掉的 0 从 ISR 移除.此刻生产消费不受影响:

# 在 kafka-1 里继续生产
kafka-console-producer.sh --topic order-events \
  --property "parse.key=true" --property "key.separator=:" \
  --bootstrap-server localhost:19092
# 正常写入:ISR 还剩 2 个,满足 min.insync.replicas=2
# 输入几条后 Ctrl+C,然后 docker compose start kafka-0

用 Go 读 ISR

// kadm 是 franz-go 的 admin 子包
import "github.com/twmb/franz-go/pkg/kadm"

adm := kadm.NewClient(client) // client 是已建好的 *kgo.Client

md, err := adm.Metadata(ctx, "order-events")
if err != nil {
    log.Fatal(err)
}
for _, p := range md.Topics["order-events"].Partitions {
    fmt.Printf("partition=%d leader=%d replicas=%v isr=%v\n",
        p.Partition, p.Leader, p.Replicas, p.ISR)
}

输出与 CLI 的 describe 一致.停 Broker 后再跑这段,能看到 ISR 收缩.

生产注意事项

下一篇进入 Controller 与元数据管理:ZooKeeper 模式与 KRaft 模式的差别,Controller 怎么选举,谁来决定 Leader 换人.