在分布式系统中,高可用(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机制和故障检测转移等多种机制来保证数据的可靠性和高可用性,确保数据能够安全可靠地传输和存储。
版权归原作者 码上一元 所有, 如有侵权,请联系我们删除。