自建手机网站,如何 在网站上面做推广,企业公众号开发,iis7如何设置ip做网站本文转发自技术世界#xff0c;原文链接 http://www.jasongj.com/zookeeper/distributedlock/ 1、Zookeeper特点
1.1 Zookeeper节点类型
如上文《Zookeeper架构及FastLeaderElection机制》所述#xff0c;Zookeeper 提供了一个类似于 Linux 文件系统的树形结构。该树形结构… 本文转发自技术世界原文链接 http://www.jasongj.com/zookeeper/distributedlock/ 1、Zookeeper特点
1.1 Zookeeper节点类型
如上文《Zookeeper架构及FastLeaderElection机制》所述Zookeeper 提供了一个类似于 Linux 文件系统的树形结构。该树形结构中每个节点被称为 znode 可按如下两个维度分类
Persist vs. Ephemeral
Persist节点一旦被创建便不会意外丢失即使服务器全部重启也依然存在。每个 Persist 节点即可包含数据也可包含子节点Ephemeral节点在创建它的客户端与服务器间的 Session 结束时自动被删除。服务器重启会导致 Session 结束因此 Ephemeral 类型的 znode 此时也会自动删除
Sequence vs. Non-sequence
Non-sequence节点多个客户端同时创建同一 Non-sequence 节点时只有一个可创建成功其它均失败。并且创建出的节点名称与创建时指定的节点名完全一样Sequence节点创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时都能创建成功只是序号不同
1.2 Zookeeper语义保证
Zookeeper 简单高效同时提供如下语义保证从而使得我们可以利用这些特性提供复杂的服务。
顺序性 客户端发起的更新会按发送顺序被应用到 Zookeeper 上原子性 更新操作要么成功要么失败不会出现中间状态单一系统镜像 一个客户端无论连接到哪一个服务器都能看到完全一样的系统镜像即完全一样的树形结构。注根据上文《Zookeeper架构及FastLeaderElection机制》介绍的 ZAB 协议写操作并不保证更新被所有的 Follower 立即确认因此通过部分 Follower 读取数据并不能保证读到最新的数据而部分 Follwer 及 Leader 可读到最新数据。如果一定要保证单一系统镜像可在读操作前使用 sync 方法。可靠性 一个更新操作一旦被接受即不会意外丢失除非被其它更新操作覆盖最终一致性 写操作最终而非立即会对客户端可见
1.3 Zookeeper Watch机制
所有对 Zookeeper 的读操作都可附带一个 Watch 。一旦相应的数据有变化该 Watch 即被触发。Watch 有如下特点
主动推送 Watch被触发时由 Zookeeper 服务器主动将更新推送给客户端而不需要客户端轮询。一次性 数据变化时Watch 只会被触发一次。如果客户端想得到后续更新的通知必须要在 Watch 被触发后重新注册一个 Watch。可见性 如果一个客户端在读请求中附带 WatchWatch 被触发的同时再次读取数据客户端在得到 Watch 消息之前肯定不可能看到更新后的数据。换句话说更新通知先于更新结果。顺序性 如果多个更新触发了多个 Watch 那 Watch 被触发的顺序与更新顺序一致。
2、 分布式锁与领导选举关键点
2.1 最多一个获取锁 / 成为Leader
对于分布式锁这里特指排它锁而言任意时刻最多只有一个进程对于单进程内的锁而言是单线程可以获得锁。
对于领导选举而言任意时间最多只有一个成功当选为Leader。否则即出现脑裂Split brain
2.2 锁重入 / 确认自己是Leader
对于分布式锁需要保证获得锁的进程在释放锁之前可再次获得锁即锁的可重入性。
对于领导选举Leader需要能够确认自己已经获得领导权即确认自己是Leader。
2.3 释放锁 / 放弃领导权
锁的获得者应该能够正确释放已经获得的锁并且当获得锁的进程宕机时锁应该自动释放从而使得其它竞争方可以获得该锁从而避免出现死锁的状态。
领导应该可以主动放弃领导权并且当领导所在进程宕机时领导权应该自动释放从而使得其它参与者可重新竞争领导而避免进入无主状态。
2.4 感知锁释放 / 领导权的放弃
当获得锁的一方释放锁时其它对于锁的竞争方需要能够感知到锁的释放并再次尝试获取锁。
原来的Leader放弃领导权时其它参与方应该能够感知该事件并重新发起选举流程。
3、非公平领导选举
从上面几个方面可见分布式锁与领导选举的技术要点非常相似实际上其实现机制也相近。本章就以领导选举为例来说明二者的实现原理分布式锁的实现原理也几乎一致。
3.1 选主过程
假设有三个Zookeeper的客户端如下图所示同时竞争Leader。这三个客户端同时向Zookeeper集群注册Ephemeral且Non-sequence类型的节点路径都为/zkroot/leader工程实践中路径名可自定义。 如上图所示由于是Non-sequence节点这三个客户端只会有一个创建成功其它节点均创建失败。 此时创建成功的客户端即上图中的Client 1即成功竞选为 Leader 。其它客户端即上图中的Client 2和Client 3此时均为 Follower。
3.2 放弃领导权
如果 Leader 打算主动放弃领导权直接删除/zkroot/leader节点即可。
如果 Leader 进程意外宕机其与 Zookeeper 间的 Session 也结束该节点由于是Ephemeral类型的节点因此也会自动被删除。
此时/zkroot/leader节点不复存在对于其它参与竞选的客户端而言之前的 Leader 已经放弃了领导权。
3.3 感知领导权的放弃
由上图可见创建节点失败的节点除了成为 Follower 以外还会向/zkroot/leader注册一个 Watch 一旦 Leader 放弃领导权也即该节点被删除所有的 Follower 会收到通知。
3.4 重新选举
感知到旧 Leader 放弃领导权后所有的 Follower 可以再次发起新一轮的领导选举如下图所示。 从上图中可见
新一轮的领导选举方法与最初的领导选举方法完全一样都是发起节点创建请求创建成功即为 Leader否则为 Follower 且 Follower 会 Watch 该节点新一轮的选举结果无法预测与它们在第一轮选举中的顺序无关。这也是该方案被称为非公平模式的原因
3.5 非公平模式总结
非公平模式实现简单每一轮选举方法都完全一样竞争参与方不多的情况下效率高。每个 Follower 通过 Watch 感知到节点被删除的时间不完全一样只要有一个 Follower 得到通知即发起竞选即可保证当时有新的 Leader 被选出给Zookeeper 集群造成的负载大因此扩展性差。如果有上万个客户端都参与竞选意味着同时会有上万个写请求发送给 Zookeper。如《Zookeeper架构》一文所述Zookeeper 存在单点写的问题写性能不高。同时一旦 Leader 放弃领导权Zookeeper 需要同时通知上万个 Follower负载较大。
4、公平领导选举
4.1 选主过程
如下图所示公平领导选举中各客户端均创建/zkroot/leader节点且其类型为Ephemeral与Sequence。 由于是Sequence类型节点故上图中三个客户端均创建成功只是序号不一样。此时每个客户端都会判断自己创建成功的节点的序号是不是当前最小的。如果是则该客户端为 Leader否则即为 Follower。
在上图中Client 1创建的节点序号为 1 Client 2创建的节点序号为 2Client 3创建的节点序号为3。由于最小序号为 1 且该节点由Client 1创建故Client 1为 Leader 。
4.2 放弃领导权
Leader 如果主动放弃领导权直接删除其创建的节点即可。
如果 Leader 所在进程意外宕机其与 Zookeeper 间的 Session 结束由于其创建的节点为Ephemeral类型故该节点自动被删除。
4.3 感知领导权的放弃
与非公平模式不同每个 Follower 并非都 Watch 由 Leader 创建出来的节点而是 Watch 序号刚好比自己序号小的节点。
在上图中总共有 1、2、3 共三个节点因此Client 2 Watch /zkroot/leader1Client 3 Watch /zkroot/leader2。注序号应该是10位数字而非一位数字这里为了方便以一位数字代替
一旦 Leader 宕机/zkroot/leader1被删除Client 2可得到通知。此时Client 3由于 Watch 的是/zkroot/leader2故不会得到通知。
4.4 重新选举
Client 2得到/zkroot/leader1被删除的通知后不会立即成为新的 Leader 。而是先判断自己的序号 2 是不是当前最小的序号。在该场景下其序号确为最小。因此Client 2成为新的 Leader 。 这里要注意如果在Client 1放弃领导权之前Client 2就宕机了Client 3会收到通知。此时Client 3不会立即成为Leader而是要先判断自己的序号 3 是否为当前最小序号。很显然由于Client 1创建的/zkroot/leader1还在因此Client 3不会成为新的 Leader 并向Client 2序号 2 前面的序号也即 1 创建 Watch。该过程如下图所示。 4.5 公平模式总结
实现相对复杂扩展性好每个客户端都只 Watch 一个节点且每次节点被删除只须通知一个客户端旧 Leader 放弃领导权时其它客户端根据竞选的先后顺序也即节点序号成为新 Leader这也是公平模式的由来延迟相对非公平模式要高因为它必须等待特定节点得到通知才能选出新的 Leader
5、总结
基于 Zookeeper 的领导选举或者分布式锁的实现均基于 Zookeeper 节点的特性及通知机制。充分利用这些特性还可以开发出适用于其它场景的分布式应用。
