Kafka高可用性原理深度解析

在分布式系统中，高可用（High Availability, HA）是指系统在面对硬件故障、网络分区、软件崩溃等异常情况时，仍能继续提供服务的能力。对于消息队列系统而言，高可用性尤为重要，因为它通常作为数据流通的中枢，任何中断都可能导致数据丢失或服务不可用。

Apache Kafka，作为一个分布式流处理平台，其高可用机制是其核心特性之一，确保了即使在部分节点失效的情况下，消息的产生和消费仍然可以持续进行。

在这里插入图片描述

Kafka的高可用机制主要依赖于以下几个关键组件和原理：

副本机制

Kafka的每个分区（Partition）都有多个副本，这些副本分布在不同的服务器（Broker）上。其中一个副本被选举为领导者（Leader），处理所有的读写操作。其余的副本称为追随者（Follower），它们从 Leader 那里同步数据。

如果 Leader 发生故障，Kafka会从 Follower 中选举出新的 Leader ，继续提供服务。

ISR机制

Leader 维护了一个动态的 ISR，含义是和 Leader 保持同步的副本集合（Leader + Follower），如果Follower长时间没有向Leader发送通信请求或同步数据，该Follower就会被踢出 ISR，该时间由 replica.lag.time.max.ms 配置，默认是 30s。

只有ISR中的副本才有资格成为新的领导者。

ACK机制

生产者发送的消息中包含acks字段，该字段代表Leader应答生产者前Leader收到的应答数。

【acks = 0】：生产者发送过来的数据，不需要等待数据落盘应答。
【数据可靠性】：丢数。

【acks = 1】：生产者发送过来的数据，Leader 收到后就应答。
【数据可靠性】：丢数。

【acks = -1】：生产者发送过来的数据，Leader 和 ISR队列里面所有的节点收到后再应答。
【数据可靠性】：丢数。

这里为啥丢数呢？

如果分区副本设置为 1 个，或者 ISR 里应答的最小副本数量（min.insync.replicas）设置为 1，就和 acks = 1 的效果是一样的，仍有丢数风险。

数据完全可靠条件：ACK 级别设置为-1 + 分区副本大于等于2 + ISR 应答的最小副本数量大于等于2

故障恢复机制

首先需要在集群所有Broker中选出一个Controller，负责各Partition的Leader选举以及Replica的重新分配;

当出现Leader故障后，Controller会将Leader/Follower的变动通知到需为此作出响应的Broker;

Kafka使用ZooKeeper存储Broker、Topic等状态数据，Kafka集群中的Controller和Broker会在ZooKeeper指定节点上注册Watcher(事件监听器)，以便在特定事件触发时，由ZooKeeper将事件通知到对应Broker。

broker

当Broker发生故障后，由Controller负责选举受影响Partition的新Leader并通知到相关Broker

当Broker出现故障与ZooKeeper断开连接后，该Broker在ZooKeeper对应的znode会自动被删除，ZooKeeper会触发Controller注册在该节点的Watcher；
Controller从ZooKeeper的/brokers/ids节点上获取宕机Broker上的所有Partition；
Controller再从ZooKeeper的/brokers/topics获取所有Partition当前的ISR；
对于宕机Broker是Leader的Partition，Controller从ISR中选择幸存的Broker作为新Leader；

controller

集群中的Controller也会出现故障，因此Kafka让所有Broker都在ZooKeeper的Controller节点/kafka/controller上注册一个Watcher;
Controller发生故障时对应的Controller临时节点会自动删除，此时注册在其上的Watcher会被触发，所有活着的Broker都会去竞选成为新的Controller(即创建新的Controller节点，由ZooKeeper保证只会有一个创建成功)
竞选成功者即为新的Controller