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
总结
Kafka通过复制机制、ISR机制、Controller机制和故障检测转移等多种机制来保证数据的可靠性和高可用性，确保数据能够安全可靠地传输和存储。