zookeeper分布式锁使用场景介绍

总结了一下之前项目上的经历，大致来说，zk的使用场景如下，我就举几个简单的：

 

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

 

这里需要注意的一个问题是，如果系统B在完成订单的库存更新之后，会把这个消息反馈给zookeeper，系统A就及时监听到这个节点的变化，

如果反馈成功，这条消息就不用做处理，如果监听到那个节点对库存的更新失败，系统A就会重发消息到MQ，这样就保证了消息不会丢失的场景。

另外，在这个请求调用链里面，使用MQ主要是做一个异步、限流的处理。当有大量的请求和并发过来的时候，直接将消息反馈给MQ，由MQ直接去进行异步处理。

 

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

 

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

 

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