高可用与可靠性

消息系统的可靠性是核心指标。本文深入讲解 Kafka 的副本机制、ISR、消息可靠性保证等关键特性。

副本机制

副本架构

Topic: orders, Partition: 0, Replication Factor: 3

┌─────────────────────────────────────────────────────┐
│                                                     │
│   Broker 0         Broker 1         Broker 2       │
│  ┌─────────┐      ┌─────────┐      ┌─────────┐    │
│  │ Leader  │      │Follower │      │Follower │    │
│  │         │─────▶│         │      │         │    │
│  │  P0     │      │  P0     │◀─────│  P0     │    │
│  └────▲────┘      └─────────┘      └─────────┘    │
│       │                                            │
│       │ 所有读写请求                               │
│       │                                            │
└───────┼────────────────────────────────────────────┘
        │
   Producer / Consumer

Leader 与 Follower

职责划分：

Leader:
- 处理所有读写请求
- 维护 ISR 列表
- 向 Follower 发送数据

Follower:
- 从 Leader 拉取数据（Fetch 请求）
- 不处理客户端请求
- 作为 Leader 的热备份

副本同步流程

Producer 发送消息的同步流程：

┌──────────┐                              ┌──────────┐
│ Producer │                              │  Leader  │
└────┬─────┘                              └────┬─────┘
     │                                         │
     │  1. 发送消息                            │
     │────────────────────────────────────────▶│
     │                                         │
     │                                         │ 2. 写入本地 Log
     │                                         │
     │         ┌──────────┐    ┌──────────┐  │
     │         │Follower 1│    │Follower 2│  │
     │         └────┬─────┘    └────┬─────┘  │
     │              │               │         │
     │              │ 3. Fetch      │ 3. Fetch│
     │              │◀──────────────┼─────────│
     │              │               │         │
     │              │ 4. 写入本地   │ 4. 写入 │
     │              │               │         │
     │                                         │
     │  5. ACK（根据 acks 配置）               │
     │◀────────────────────────────────────────│
     │                                         │

ISR 机制

ISR 概念

ISR（In-Sync Replicas）是与 Leader 保持同步的副本集合：

ISR = { Leader, Follower1, Follower2, ... }

同步条件：
1. 副本与 Leader 的滞后时间 < replica.lag.time.max.ms
2. 副本正常连接到 ZooKeeper/Controller

ISR 变化：
- Follower 落后过多 → 移出 ISR
- Follower 追上 Leader → 加入 ISR

HW 与 LEO

HW (High Watermark) 和 LEO (Log End Offset)：

Partition 0
┌─────────────────────────────────────────────────────┐
│                                                     │
│  Leader:                                           │
│  Offset: 0   1   2   3   4   5   6   7   8        │
│        ┌───┬───┬───┬───┬───┬───┬───┬───┬───┐     │
│        │ A │ B │ C │ D │ E │ F │ G │ H │   │     │
│        └───┴───┴───┴───┴───┴───┴───┴───┴───┘     │
│                            ▲           ▲          │
│                            │           │          │
│                           HW          LEO         │
│                                                     │
│  Follower 1:                                       │
│  Offset: 0   1   2   3   4   5   6                │
│        ┌───┬───┬───┬───┬───┬───┬───┐             │
│        │ A │ B │ C │ D │ E │ F │   │             │
│        └───┴───┴───┴───┴───┴───┴───┘             │
│                            ▲       ▲              │
│                            │       │              │
│                           HW      LEO             │
│                                                     │
│  Follower 2:                                       │
│  Offset: 0   1   2   3   4   5   6   7           │
│        ┌───┬───┬───┬───┬───┬───┬───┬───┐        │
│        │ A │ B │ C │ D │ E │ F │ G │   │        │
│        └───┴───┴───┴───┴───┴───┴───┴───┘        │
│                            ▲           ▲         │
│                            │           │         │
│                           HW          LEO        │
│                                                     │
└─────────────────────────────────────────────────────┘

LEO：日志末端偏移，下一条消息要写入的位置
HW：高水位，Consumer 可见的最大 Offset
HW = min(所有 ISR 副本的 LEO)

ISR 相关配置

# 副本最大延迟时间（默认 30s）
# 超过此时间未同步，移出 ISR
replica.lag.time.max.ms=30000

# 最小 ISR 数量
# acks=all 时，ISR 数量 < 此值，拒绝写入
min.insync.replicas=2

# 不干净的 Leader 选举
# true：允许非 ISR 副本成为 Leader（可能丢数据）
# false：等待 ISR 副本恢复（可能不可用）
unclean.leader.election.enable=false

Leader 选举

选举触发条件

1. Controller 选举
   - Broker 启动时
   - Controller 所在 Broker 宕机

2. Partition Leader 选举
   - Leader 所在 Broker 宕机
   - 手动触发 Preferred Leader 选举

Controller 选举

Controller 是集群的管理者：

职责：
1. 管理分区和副本状态
2. 执行分区 Leader 选举
3. 监控 Broker 上下线
4. 处理 Topic 创建/删除

选举过程：
1. 所有 Broker 尝试在 ZK 创建 /controller 临时节点
2. 第一个创建成功的成为 Controller
3. 其他 Broker 监听该节点
4. Controller 宕机后，重新选举

Partition Leader 选举

选举策略：

1. ISR 优先
   - 优先从 ISR 中选择第一个副本
   - 保证数据不丢失

2. 不干净选举（unclean.leader.election.enable=true）
   - ISR 为空时，从非 ISR 副本中选择
   - 可能丢失数据

选举流程：
┌────────────────────────────────────────────────┐
│                 Controller                      │
│                     │                          │
│  Leader 宕机        ▼                          │
│  ┌─────────────────────────────────────┐      │
│  │ 从 ISR 列表中选择第一个存活的副本    │      │
│  │ 作为新 Leader                        │      │
│  └─────────────────────────────────────┘      │
│                     │                          │
│                     ▼                          │
│  ┌─────────────────────────────────────┐      │
│  │ 更新 ZK 中的 Leader 信息             │      │
│  │ 通知所有 Broker                      │      │
│  └─────────────────────────────────────┘      │
│                                                │
└────────────────────────────────────────────────┘

消息可靠性

ACK 机制

// acks=0：不等待确认
// Producer 发送后立即返回，可能丢消息
props.put("acks", "0");

// acks=1：等待 Leader 确认
// Leader 写入成功即返回，Leader 宕机可能丢消息
props.put("acks", "1");

// acks=all（或 -1）：等待所有 ISR 确认
// 最可靠，但延迟最高
props.put("acks", "all");

三端可靠性保证

完整的消息可靠性需要 Producer、Broker、Consumer 三端配合：

┌─────────────────────────────────────────────────────────┐
│                     Producer 端                          │
│                                                         │
│  acks=all                    # 等待所有 ISR 确认         │
│  retries=3                   # 失败重试                  │
│  enable.idempotence=true     # 幂等性                    │
│                                                         │
└─────────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────┐
│                     Broker 端                            │
│                                                         │
│  replication.factor=3        # 3 副本                    │
│  min.insync.replicas=2       # 最少 2 个 ISR             │
│  unclean.leader.election=false # 禁止不干净选举         │
│                                                         │
└─────────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────┐
│                     Consumer 端                          │
│                                                         │
│  enable.auto.commit=false    # 手动提交 Offset          │
│  处理完消息后再提交           # 避免消息丢失             │
│  业务幂等设计                 # 处理重复消费             │
│                                                         │
└─────────────────────────────────────────────────────────┘

消息丢失场景分析

场景 1：acks=0
┌──────────┐    发送    ┌──────────┐
│ Producer │───────────▶│  Broker  │ ✗ Broker 未收到
└──────────┘            └──────────┘
             消息丢失

场景 2：acks=1，Leader 宕机
┌──────────┐    发送    ┌──────────┐    同步中    ┌──────────┐
│ Producer │───────────▶│  Leader  │─────────────▶│ Follower │
└──────────┘            └──────────┘              └──────────┘
                             ✗ Leader 宕机
                             Follower 未同步完成
                             消息丢失

场景 3：Consumer 自动提交
┌──────────┐    消费    ┌──────────┐    自动提交   ┌──────────┐
│ Consumer │◀───────────│  Broker  │◀─────────────│  Offset  │
└──────────┘            └──────────┘              └──────────┘
       ✗ 处理失败
       但 Offset 已提交
       消息丢失（对业务而言）

消息顺序性

单分区顺序

Kafka 只保证单分区内消息有序：

Partition 0:
┌───┬───┬───┬───┬───┐
│ 1 │ 2 │ 3 │ 4 │ 5 │  ✓ 有序
└───┴───┴───┴───┴───┘

跨分区无序：
Partition 0: │ 1 │ 3 │ 5 │
Partition 1: │ 2 │ 4 │ 6 │

Consumer 可能消费顺序: 1, 2, 3, 4, 5, 6
                    或: 2, 1, 4, 3, 6, 5  ✗ 无序

保证顺序的方法

// 方法 1：使用相同 Key
// 相同 Key 的消息发送到同一分区
producer.send(new ProducerRecord<>("orders", orderId, orderData));

// 方法 2：单分区 Topic
// 所有消息在同一分区，但牺牲并行性

// 方法 3：限制在途请求数
props.put("max.in.flight.requests.per.connection", 1);
// 配合幂等性可以设为 5

高可用部署

推荐配置

# Broker 配置
# 副本数（推荐 3）
default.replication.factor=3

# 最小 ISR（推荐 2）
min.insync.replicas=2

# 禁止不干净选举
unclean.leader.election.enable=false

# Producer 配置
acks=all
retries=3
enable.idempotence=true

# Consumer 配置
enable.auto.commit=false

集群部署建议

1. 节点数量
   - 最少 3 个 Broker
   - 推荐跨机架/可用区部署

2. 副本配置
   - replication.factor >= 3
   - min.insync.replicas >= 2

3. 磁盘配置
   - 使用多块磁盘
   - JBOD 或 RAID10

4. 网络配置
   - 高带宽网络
   - 单独的复制网络

面试高频问题

1. Kafka 如何保证消息不丢失？

Producer 端：
1. acks=all：等待所有 ISR 副本确认
2. retries > 0：失败重试
3. enable.idempotence=true：幂等性

Broker 端：
1. replication.factor >= 3：多副本
2. min.insync.replicas >= 2：最小 ISR
3. unclean.leader.election.enable=false：禁止不干净选举

Consumer 端：
1. enable.auto.commit=false：手动提交
2. 处理完成后再提交 Offset
3. 业务幂等设计

2. ISR 是什么？有什么作用？

ISR（In-Sync Replicas）是与 Leader 保持同步的副本集合。

作用：
1. 保证数据一致性
2. acks=all 时，只需 ISR 副本确认
3. Leader 选举时，优先从 ISR 选择

维护规则：
1. 副本滞后超过 replica.lag.time.max.ms 移出
2. 副本追上 Leader 后加入
3. min.insync.replicas 控制最小 ISR 数量

3. HW 和 LEO 的区别？

LEO（Log End Offset）：
- 日志末端偏移
- 下一条消息要写入的位置
- 每个副本各自维护

HW（High Watermark）：
- 高水位，所有 ISR 副本都已同步的位置
- Consumer 可见的最大 Offset
- HW = min(所有 ISR 副本的 LEO)

关系：
- HW <= LEO
- HW 之前的消息对 Consumer 可见
- HW 到 LEO 之间的消息还在同步中

4. acks=all 一定不丢消息吗？

不一定，还需要其他配置配合：

可能丢消息的情况：
1. min.insync.replicas=1
   - ISR 只有 Leader，acks=all 等同于 acks=1
   - Leader 宕机可能丢数据

2. unclean.leader.election.enable=true
   - 允许非 ISR 副本成为 Leader
   - 可能丢失未同步的数据

正确配置：
acks=all
min.insync.replicas=2
unclean.leader.election.enable=false
replication.factor=3

5. Controller 的作用是什么？

Controller 是 Kafka 集群的管理者，职责包括：

1. 分区管理
   - 分区状态变更
   - 副本状态变更

2. Leader 选举
   - Broker 宕机时选举新 Leader
   - Preferred Leader 选举

3. 集群成员管理
   - 监控 Broker 上下线
   - 维护集群元数据

4. Topic 管理
   - Topic 创建/删除
   - 分区扩容

选举方式：
- ZK 模式：抢占 /controller 节点
- KRaft 模式：Raft 协议选举

总结

Kafka 高可用与可靠性要点：
1. 副本机制：Leader 处理读写，Follower 同步数据
2. ISR 机制：维护同步副本集合，保证数据一致性
3. HW/LEO：控制消息可见性，协调副本同步
4. Leader 选举：优先从 ISR 选择，保证数据不丢
5. ACK 机制：acks=all 配合 min.insync.replicas
6. 三端配合：Producer + Broker + Consumer 共同保证