分布式锁中-基于Zookeeper的实现

Zookeeper（后续简称ZK）是一个分布式的，开放源码的分布式应用程序协调服务，通常以集群模式运转，其协调能力可以理解为是基于观察者设计模式来实现的；ZK服务会使用Znode存储使用者的数据，并将这些数据以树形目录的形式来组织管理，支持使用者以观察者的角色指定自己关注哪些节点\数据的变更，当这些变更发生时，ZK会通知其观察者；为满足本篇目标所需，着重介绍以下几个关键特性：,,ZooKeeper's Hierarchical Namespace,,ZooKeeper Service,,监听机制：给某个节点注册监听器，该节点一旦发生变更（例如更新或者删除），监听者就会收到一个Watch Event，可以感知到节点\数据的变更,,临时节点：session链接断开临时节点就没了，不能创建子节点（很关键）,ZK的分布式锁正是基于以上特性来实现的，简单来说是：,,可能读者是单篇阅读，这里引入上一篇《分布式锁上-初探》中的一些内容，一个分布式锁应具备这样一些功能特点：,基于上文的内容，这里简单总结一下ZK的能力矩阵（其它分布式锁的情况会在后续文章中补充）：,关于性能不太高的一种说法,因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后Leader服务器还需要将数据同步到所有的Follower机器上，这样频繁的网络通信，性能的短板是非常突出的。在高性能，高并发的场景下，不建议使用ZooKeeper的分布式锁。,由于ZooKeeper的高可用特性，在并发量不是太高的场景，也推荐使用ZK的分布式锁。,Zookeeper 客户端框架 Curator 提供的 InterProcessMutex 是分布式锁的一种实现，acquire 方法阻塞|非阻塞获取锁，release 方法释放锁，另外还提供了可撤销、可重入功能。,4.1 接口介绍,4.2 pom依赖,4.3 示例,通过这个实例对照第2节内容来理解加解锁的流程，以及如何避免惊群效应。,本文转载自微信公众号「架构染色」，可以通过以下二维码关注。转载本文请联系【架构染色】公众号作者。,,