Kafka

Kafka 高可用架构完整详解

·7 分钟阅读·2612 字
kafkamessage-queue

Kafka 组件/原理详解

📋 目录

Kafka 高可用架构完整详解（面试标准完整版，可直接录入知识库）

一、高可用核心依赖：分区 + 多副本 + ISR机制 + Leader选举 + HW高水位

Kafka高可用不靠单Broker，Topic拆分Partition，每个Partition多副本分散在不同Broker，单节点宕机不丢数据、服务不中断。

1.副本基础概念 AR集合

  • AR（Assigned Replicas）：分区全部副本列表，包含1个Leader + N个Follower。
  • 副本分散规则：同一个Partition所有副本不能落在同一台Broker，机架部署时跨机架存放，规避整机/机架断电故障。
  • Leader：负责所有生产写入、消费读取；Follower：不处理业务流量，只被动拉取Leader日志做数据同步。

二、ISR 核心机制（Kafka高可用灵魂）

1. ISR全称：In-Sync Replicas（同步副本集合）

ISR = Leader + 跟得上同步进度的Follower副本，滞后太多的Follower会被踢出ISR。
参数：replica.lag.time.max.ms（默认30s）

判断踢出规则：Follower连续30s无法拉取到新消息，判定同步滞后，移出ISR变为OSR；后续追上日志进度后，自动重新加入ISR。

  • OSR(Out-of-Sync Replicas)：滞后掉队副本，不参与Leader竞选。

2. acks参数与ISR联动（写入可靠性）

  1. acks=1（默认）：Leader写入本地磁盘即返回成功，不等待Follower同步；Leader瞬间宕机存在丢数风险。
  2. acks=all / -1：消息必须写入Leader，且全部ISR内副本同步完成，生产者才收到成功响应；最高可靠，ISR过少会阻塞生产。

极端：ISR只剩Leader 1个副本时，acks=all等价于acks=1。

三、LEO、HW、LeaderEpoch（保证副本数据一致性、防止宕机日志错乱）

1. LEO（Log End Offset）

每个副本自身日志最后一条消息的下一个偏移量，代表当前副本日志末尾位置；Leader/所有Follower各自维护独立LEO。

2. HW（High Watermark 高水位）

ISR集合中最小的LEO，就是分区HW。

  • HW之前的消息：已同步到全部ISR副本，对外可见、可以被消费者消费；
  • HW~Leader.LEO之间的数据：仅存在Leader，Follower未同步，消费者无法读取。

作用：Leader宕机，新Leader只能从HW位置对外提供服务，截断HW之后未同步数据，保证多副本数据一致。

3. Leader Epoch（Leader纪元，0.11版本后修复日志截断BUG）

每条日志携带当前Leader纪元编号，新Leader上任生成新Epoch；解决老版本Follower错误截断有效日志、数据丢失问题。

四、分区Leader故障自动切换（Controller负责）

1. Controller角色（KRaft/ZK两种架构）

  1. ZK架构：集群通过ZK抢锁选出唯一Controller Broker，监听所有Broker上下线事件；
  2. KRaft架构（新版本弃ZK）：集群拆分Controller集群（元数据节点），元数据分区化，不再单点依赖ZK。

2. 宕机切换流程

  1. Broker宕机，ZK/RAFT感知节点下线，通知Controller；
  2. Controller检索故障分区的ISR列表，从ISR中挑选新Leader（优先选ISR内日志最新副本）；
  3. 更新元数据，通知全集群元数据变更，生产者/消费者重连新Leader。

硬性规则：永远不从OSR掉队副本选举Leader，避免丢失大量数据。
极端场景：ISR全部副本宕机、无可用ISR → 分区不可读写，生产阻塞。

五、Broker集群容灾分层

  1. 单机宕机：分区副本分散其他节点，自动选新Leader，业务无感知；
  2. 机架故障：副本跨机架部署，同机架全挂，其余机架副本正常服务；
  3. 机房容灾：跨机房部署副本，配合MirrorMaker2做集群双活/异地灾备。

六、元数据高可用演进：ZK → KRaft

1. ZK架构短板

ZK只存储集群元数据、Controller注册、Broker注册；

  • Controller单点，故障影响全集群元数据更新；
  • ZK不存储消息数据，消息全在Broker磁盘。

2. KRaft架构（Kafka Raft）

  • 拆分独立Controller节点，元数据以Raft协议多副本持久化在Controller集群；
  • 去掉ZK依赖，元数据高可用，解决Controller单点故障瓶颈，新版本生产主流。

七、生产落地高可用配套方案

  1. 副本数配置：生产推荐分区副本数replication-factor=3（1Leader+2Follower），兼顾可用性与磁盘成本；
  2. 机架感知配置：开启broker.rack，副本自动跨机架均匀分布；
  3. acks规范：核心金融业务acks=all，高吞吐日志业务acks=1；
  4. 消费侧高可用：消费者组多实例部署，单个消费实例宕机触发Rebalance，剩余实例继续消费。

八、高频故障场景（面试题，入库格式）

tags: #Kafka #高可用 #面试
题目：ISR频繁收缩、生产者acks=all发送报错NotEnoughReplicas？
精简答案：Follower同步滞后被踢出ISR，ISR数量不足配置副本数；排查磁盘IO打满、网络延迟、Broker负载过高。

一句话背诵总结

Kafka依靠分区多副本分散部署+ISR同步机制+HW数据保护+Controller自动选主实现Broker层面高可用；KRaft通过Raft保证元数据高可用，副本数3是生产高可用标配。

需要继续讲 Rebalance故障、消息丢失/重复生产消费？

关联文档

返回首页订阅更新