Zookeeper分布式锁实现原理

Zookeeper分布式锁的代码实现很简单，Curator(简化Zookeeper客户端的使用，使用时要保证Curator导入坐标的版本比Zookeeper版本高)已帮助我们封装好，使用起来代码不超过5行。但当我们需要进行中高级程序员面试时，回答好Zookeeper分布式锁的实现原理可以大大提高我们的“加钱”分。

核心思想：当客户端想要获取锁，需要先创建节点，使用完锁，再删除该节点。

1、当客户端获取锁时，在lock节点下创建一个临时顺序节点。为什么是临时顺序？
1）临时： 如果我们的client1拿到了锁，宕机了锁就不会被释放，其他的client就会一直拿不到锁，临时节点即使宕机也会自动删除，所以不能是持久化的节点。
2）顺序： 为了找最小节点。
2、然后获取lock下所有的临时节点，客户端获取节点后，如果发现自己创建的临时节点最小，则获取到锁，使用完锁后将该节点删除。
3、如果发现自己创建的节点在非lock的节点中不是最小的，说明自己还没有获取到锁，需要找到比自己小的那个节点，同时对其注册事件监听器，监听删除事件。
4、如果发现自己监听的节点被删除，客户端的Watcher会收到相应的通知，再次判断自己创建的节点是否是lock子节点中序号最小的，如果是则获取到锁，如果不是则继续重复以上步骤继续找到比自己小的节点，并注册监听。

在Zookeeper分布式锁中，最重要的就是 临时顺序 节点的概念，非最小序号的临时节点只会监听比自己小的一个节点。

Zookeeper相关的CAP理论：
CAP理论指出对于一个分布式计算系统来说，不可能同时满足以下三点，最多只能满足其中两项 ：
一致性（Consistency）： 在分布式环境中，一致性是指在多个副本环境间能否保持数据的一致特性，等同于所有节点访问一份最新数据。在一致性需求下，当一个系统在数据一致的状态下进行更新操作后，应保证系统数据仍处于一致的转态。
可用性（Availability）： 每次请求都能获取正确的响应，但不能保证获取的数据为最新数据。
分区容错性（Partition tolerance）： 分布式系统在遇到任何网络分区故障的时候，仍能保证对外提供一致性和可用性服务，除非是整个网络环境都发生变化。

在这三个基本需求中，最多只能满足两个，而P是必须的，所以只有AP和CP，zookeeper保证的是CP，在SpringCloud系统中的eruka实现的是AP.

Zookeeper集群选举过程：
各服务器 顺序启动，投票过半 时，该节点当选为Leader，其余为Follower。假如现在有Server1、Server2、Server3、Server4、Server5五台服务器，顺序启动后，Server3当选为Leader，其余为Follower。当Server3挂掉时，会重新选举，Server4投票过半，当选新的Leader。非Server3的Follower挂掉时，则不会重新选举Leader，依旧是Server3为Leader。

Zookeeper集群中有三种角色：

Leader领导者：
1）处理事务请求（增删改就是事务请求）
2）集群内部服务器的调度者
Follower跟随者：
1）处理客户端非事务请求（查询），转发事务请求给Leader服务器
2）参与Leader投票选举
Observer观察者：
1）处理客户端非事务请求（查询），转发事务请求给Leader服务器
（Follower查询压力大，所以添加Observer来分担压力，但其不具备选举功能）

注：事务性请求Follower转发给Leader处理后，由Leader同步给其他的Follwer，即满足CAP理论中一致性的设计。