zookeeper场景运用及原理

2020-03-20 本文已影响0人北海北_6dc3

Zookeeper通知机制客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

前面我谈过，zookeeper中存在4种类型的Znode节点，分别对应：

PERSISTENT:永久节点
EPHEMERAL:临时节点
PERSISTENT_SEQUENTIAL:永久节点序列化
EPHEMERAL_SEQUENTIAL:临时节点序列化

根据这个特性，我们就可实现分布式锁，原理是使用:临时节点序列化。

客户端连接 Zookeeper，并在 /lock 下创建临时且有序（即EPHEMERAL_SEQUENTIAL）的子节点，如，第一个子节点为 /lock/lock-000，第二个为 /lock/lock-001，以此类推；
创建成功后，获取 /lock 下的子节点列表，判断刚创建的子节点在列表中是否是序号最小的子节点，如果是，则认为是获得锁，否则，监听刚创建的子节点的前一位子节点的删除消息，等获得该子节点的变更通知后，重复此步骤，直至获得锁为止；
执行业务代码；
完成业务代码后，删除对应子节点释放锁；

与redis实现分布式锁区别：

Redis 需要自己实现重试逻辑，比较消耗性能；
zk 重试获取锁，对节点注册监听器即可，不需要主动尝试，性能开销小；【前面节点变化，通知】
如果 Redis 获取锁的客户端挂了，就不能主动删除 key，只能等待 key 的超时到期，而 zk 会主动发现客户端断连，并将临时 znode 删除，触发后面的监听器。

和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。

其中命名服务和配置管理可以考虑为一个公共的数据库，这个数据库能检测数据变化，会话状态，并发布通知

同队列管理相似功能