使用ZooKeeper解决常见的分布式问题,包括leader选举、分布式队列、负载均衡等。
1、leader选举
基于ZooKeeper实现leader选举的基本思想是,让各个参与竞选的实例同时在ZooKeepeer上创建指定的znode,比如/current/leader,谁创建成功则谁竞选成功,并将自己的信息(host、port等)写入该znode数据域,之后其他竞选者向该znode注册watcher,以便当前leader出现故障时,第一时间再次参与竞选,具体如下图所示。
基于ZooKeeper的leader选举流程如下:
1)各实例启动后,尝试在ZooKeeper上创建ephemeral类型znode节点/current/leader,假设实例B创建成功,则将自己的信息写入该znode,并将自己的角色标注为leader,开始执行leader相关的初始化工作。
2)除B之外的实例得知创建znode失败,则向/current/ leader注册watcher,并将自己角色标注为follower,开始执行follower相关的初始化工作。
3)系统正常运行,直到实例B因故障退出,此时znode节点/current/leader被ZooKeeper删除,其他follower收到节点被删除的事情,重新转入步骤1,开始新一轮的leader选举。
在Hadoop生态系统中,HBase、YARN和HDFS等系统,采用了类似的机制解决leader选举问题。
2、分布式队列
在分布式计算系统中,常见的做法是,用户将作业提交给系统的Master,并由Master将之分解成子任务后,调度给各个Worker执行。该方法存在一个问题:Master维护了所有作业和Worker信息,一旦Master出现故障,则整个集群不可用。为了避免Master维护过多状态,一种改进方式是将所有信息保存到ZooKeeper上,进而让Master变得无状态,这使得leader选举过程更加容易,典型架构如下图所示。
该方案的关键是借助ZooKeeper实现一个分布式队列,并借助ZooKeeper自带的特性,维护作业提交顺序、作业优先级、各节点(Worker)负载情况等。借助ZooKeeper的PersistentSequentialZnode自动编号特性,可轻易实现一个简易的FIFO(First In First Out)队列,在这个队列中,编号小的作业总是先于编号大的作业提交。
Hadoop生态系统中Storm便借助ZooKeeper实现了分布式队列,以可靠地保存拓扑信息和任务调度信息。
3、负载均衡
分布式系统很容易通过ZooKeeper实现负载均衡,典型的应用场景是分布式消息队列,下图描述了Kafka是如何通过ZooKeeper解决负载均衡和服务发现问题的。在Kafka中,各个Broker和Consumer均会向ZooKeeper注册,保存自己的相关信息,组件之间可动态获取对方的信息。
Broker和Consumer主要在ZooKeeper中写入以下信息:
- Broker节点注册信息:记录在ephemeral类型的znode路径/brokers/ids/[0...N]([0… N]是指0到N之间的某个数)下,保存了该Broker所在host以及对外开放的端口号。
- Consumer注册信息:记录在ephemeral类型znode路径/consumers/[group_id]/ids/[consumer_id]下,保存了Consumer group中各个consumer当前正在读取的各个topic及对应的数据流。
- Consumer Offset追踪信息:记录在persistent类型的znode路径/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] 下,保存了特定Consumer group(ID为[group_id]))当前读到的特定主题([topic])中特定分片([broker_id-partition_id])的偏移量值。