Zookeeper的使用场景 （分布式协调+分布式锁+元数据/配置信息+HA高可用）_分布式锁 主备

经典使用场景：

分布式协调

这个其实是zk很经典的一个用法，简单来说，就好比，你A系统发送个请求到mq，然后B消息消费之后处理了。那A系统如何知道B系统的处理结果？用zk就可以实现分布式系统之间的协调工作。
A系统发送请求之后可以在zk上对某个节点的值注册个监听器，一旦B系统处理完了就修改zk那个节点的值，A立马就可以收到通知，完美解决。

分布式锁

对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行另外一个机器再执行。那么此时就可以使用zk分布式锁，一个机器接收到了请求之后先获取zk上的一把分布式锁，就是可以去创建一个znode，接着执行操作；然后另外一个机器也尝试去创建那个znode，结果发现自己创建不了，因为被别人创建了。（zk同级节点的创建具有排他性，同级下相同名字的节点只能创建一个）那只能等着，等第一个机器执行完了自己再执行。

元数据/配置信息

zk可以用作很多系统的配置信息的管理，比如kafka、storm等等很多分布式系统都会选用zk来做一些元数据、配置信息的管理，包括dubbo注册中心不也支持zk么

HA高可用性 （主备监听）

这个应该是很常见的，比如hadoop、hdfs、yarn等很多大数据系统，都选择基于zk来开发HA高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过zk感知到切换到备用进程。

根据zk临时节点的特性，系统A–work01 与系统A-- work02都可以在zk上创建临时节点，这里假设首次是work01创建节点active成功，所以work01成为主机， work02作为备机会监听active节点的变化，当work01主机宕机时候，此时active节点作为临时节点失去连接会自动消失，work02备机监听到active节点的变化后就会重新创建active节点，由此获取到锁，成为主机，完成备机到主机的转换。 此时work01从主机转换为备机，当work01恢复后去监听active节点，发现已创建节点则会按兵不动，当监听到节点发生变化（比如work02宕机）会重复上述流程再次完成备机到主机的切换。