Zookeeper应用场景实现

一：分布式锁

zookeeper 分布式锁，如果自己实现的话，大抵的实现方式如下：

公平锁

在 zookeeper 的指定节点（locks）下创建临时顺序节点 node_n ;

获取 locks 下面的所有子节点 children。

对子节点按节点自增序号从小到大排序。

判断本节点是不是第一个子节点，如果是，则获取到锁。如果不是，则监听比该节点小的那个节点的删除事件。

若监听事件生效，则回到第二步重新判断，直到获取到锁。

 

非公平锁

在 zookeeper 的某个节点（lock）上创建临时节点 znode。

创建成功，就表示获取到了这个锁；其他客户端来创建锁会失败，只能注册对这个锁的监听。

其他客户端监听到这个锁被释放（znode节点被删除），就会尝试加锁（创建节点），继续执行第二步。

 

zookeeper recipes 客户端为提供了多种分布式锁实现

InterProcessMutex（可重入排他锁）

InterProcessSemaphoreMutex（不可重入排他锁）

InterProcessReadWriteLock（分布式读写锁）

InterProcessSemaphore（共享信号量 —— 设置最大并行数量）

 

 

二：ID生成器

使用ZooKeeper持久顺序节点的次序特性。来维护节点的编号。

这里，我们采用第二种，通过ZooKeeper持久顺序节点特性，来配置维护节点的编号NODEID。

集群节点命名服务的基本流程是：

（1）启动节点服务，连接ZooKeeper， 检查命名服务根节点根节点是否存在，如果不存在就创建系统根节点。

（2）在根节点下创建一个临时顺序节点，取回顺序号做节点的NODEID。如何临时节点太多，可以根据需要，删除临时节点。

基本的算法，和生成分布式ID的大部分是一致

 

扩展：

witter的snowflake 算法，是一种著名的分布式服务器用户ID生成算法。SnowFlake算法所生成的ID 是一个64bit的长整形数字。这个64bit被划分成四部分

1：第一位

占用1bit，其值始终是0，没有实际作用。

2：时间戳

占用41bit，精确到毫秒，总共可以容纳约69年的时间。

3：工作机器id

占用10bit，最多可以容纳1024个节点。

4：序列号

占用12bit，最多可以累加到4095。这个值在同一毫秒同一节点上从0开始不断累加。

总体来说，在工作节点达到1024顶配的场景下，SnowFlake算法在同一毫秒内最多可以生成多少个全局唯一ID呢？这是一个简单的乘法：

同一毫秒的ID数量 = 1024 X 4096 = 4194304

400多万个ID，这个数字在绝大多数并发场景下都是够用

 

 

 

 

 

发布订阅	wacther机制和znode
分布式锁	临时有序节点和wacther机制
分布式队列	临时有序节点
负载均衡	负载均衡算法和znode
ID生成器	临时有序节点
统一命名服务	znode
master选举	znodes