ZooKeeper的典型应用场景——Master选举

Master选举是一个在分布式系统中非常常见的应用场景。分布式最核心的特性就是能够将具有独立计算能力的系统单元部署在不同的机器上,构成一个完整的分布式系统。在实际场景中,往往需要这些分布在不同机器上的独立系统单元中选出一个所谓的“老大”,称之为Master。

在分布式系统中,Master往往用来协调集群中其他系统单元,具有对分布式系统状态变更的决定权。
比如:Master负责处理一些复杂的逻辑,并将处理结果同步给集群中其他系统单元;在读写分离的场景中,客户端的写请求由Master处理。
具体使用场景:使用集群中的一台Master机器,在海量数据以及十分耗费CPU资源的计算中,计算出应该推送的广告,然后共享给其他客户端机器。

  • 方案一:使用关系型数据库

    使用关系型数据库的主键特性来实现,所有的机器都向数据库中插入一条相同的主键ID,数据库会自动进行主键冲突检查,即只有一台机器会成功并成为Master。
    缺点:Master机器一旦挂了,数据库无法通知我们

  • 方案二:使用ZooKeeper

    利用ZooKeeper的数据一致性,可以保证在分布式高并发情况下节点的创建一定有全局唯一性,即ZooKeeper将保证客户端无法重复创建一个已经存在的数据节点。
    具体做法:客户端集群每天都会定时往ZooKeeper上创建一个临时节点,例如/master_election/2018-06-01/binding。只有一个客户端可以成功创建这个节点,成为Master机器。与此同时,其他的ZooKeeper客户端都会在节点/master_election/2018-06-01/binding上注册一个子节点变更的Watcher,一旦Master挂了,其余的客户端将会重新近进行Master选举。

猜你喜欢

转载自blog.csdn.net/Pierce_Liu/article/details/80554288