Zookeeper：基于Zookeeper的分布式锁与领导选举

本文转发自技术世界，原文链接　http://www.jasongj.com/zookeeper/distributedlock/

1、Zookeeper特点

1.1 Zookeeper节点类型

如上文《Zookeeper架构及FastLeaderElection机制》所述，Zookeeper 提供了一个类似于 Linux 文件系统的树形结构。该树形结构中每个节点被称为 znode ，可按如下两个维度分类

• Persist vs. Ephemeral

1. Persist节点，一旦被创建，便不会意外丢失，即使服务器全部重启也依然存在。每个 Persist 节点即可包含数据，也可包含子节点
2. Ephemeral节点，在创建它的客户端与服务器间的 Session 结束时自动被删除。服务器重启会导致 Session 结束，因此 Ephemeral 类型的 znode 此时也会自动删除

• Sequence vs. Non-sequence

3. Non-sequence节点，多个客户端同时创建同一 Non-sequence 节点时，只有一个可创建成功，其它均失败。并且创建出的节点名称与创建时指定的节点名完全一样
4. Sequence节点，创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时，都能创建成功，只是序号不同

1.2 Zookeeper语义保证

Zookeeper 简单高效，同时提供如下语义保证，从而使得我们可以利用这些特性提供复杂的服务。

• 顺序性　客户端发起的更新会按发送顺序被应用到 Zookeeper 上
• 原子性 更新操作要么成功要么失败，不会出现中间状态
• 单一系统镜像　一个客户端无论连接到哪一个服务器都能看到完全一样的系统镜像（即完全一样的树形结构）。注：根据上文《Zookeeper架构及FastLeaderElection机制》介绍的 ZAB 协议，写操作并不保证更新被所有的 Follower 立即确认，因此通过部分 Follower 读取数据并不能保证读到最新的数据，而部分 Follwer 及 Leader 可读到最新数据。如果一定要保证单一系统镜像，可在读操作前使用 sync 方法。
• 可靠性　一个更新操作一旦被接受即不会意外丢失，除非被其它更新操作覆盖
• 最终一致性　写操作最终（而非立即）会对客户端可见
</