Zookeeper
Zookeeper从设计模式角度来理解：是一个基 于观察者模式设计的分布式服务管理框架，它负责 存储和管理大家都关心的数据，然后接受观察者的 注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察 者做出相应的反应。
Zookeeper = 文件系统 + 通知机制
一、Zookeeper特点
- Zookeeper:一个领导者(Leader)，多个跟随者(Follower)组成的集群。
- 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
- 全局数据一致:每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
- 更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
- 数据更新原子性，一次数据更新要么成功，要么失败。
- 实时性，在一定时间范围内，Client能读到最新数据。
二、数据结构
ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个 节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过 其路径唯一标识。
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
1.统一命名服务
在分布式环境下，经常需要对应用/服 务进行统一命名，便于识别。例如：IP不容易记住，而域名容易记住。
2.统一配置管理
1. 分布式环境下，配置文件同步非常常见。
一般要求一个集群中，所有节点的配置信息是一致的，比如 Kafka 集群。对配置文件修改后，希望能够快速同步到各个节点上。2. 配置管理可交由ZooKeeper实现。
可将配置信息写入ZooKeeper上的一个Znode。各个客户端服务器监听这个Znode。一旦Znode中的数据被修改，ZooKeeper将通知 各个客户端服务器。
3.统一集群管理
1. 分布式环境中，实时掌握每个节点的状态是必要的。可根据节点实时状态做出一些调整。
2. ZooKeeper可以实现实时监控节点状态变化。可将节点信息写入ZooKeeper上的一个ZNode。监听这个ZNode可获取它的实时状态变化。
4.服务器动态上下线
5.软负载均衡
在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
三、选举机制
在了解zookeeper的选举机制之前，需要先了解在zookeeper集群中的3个ID。分别是SID、ZXID、Epoch。zookeeper的选举过程中依赖这3个ID来做判断。具体的选举过程也分别集群首次启动和非第一次启动两种情况。具体如下：
SID：服务器ID。用来唯一标识一台 ZooKeeper集群中的机器，每台机器不能重 复，和myid一致。
ZXID：事务ID。ZXID是一个事务ID，用来 标识一次服务器状态的变更。在某一时刻， 集群中的每台机器的ZXID值不一定完全一 致，这和ZooKeeper服务器对于客户端“更 新请求”的处理逻辑有关。
Epoch：每个Leader任期的代号。没有 Leader时同一轮投票过程中的逻辑时钟值是 相同的。每投完一次票这个数据就会增加
1.Zookeeper选举机制——第一次启动
- 服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上(3票，选举无法完成，服务器1状态保持为LOOKING；
- 服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的myid比自己目前投票推举的(服务器1)大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING；
- 服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING;
- 服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果:服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
- 服务器5启动，同4一样当小弟；
2.Zookeeper选举机制——非第一次启动
- 当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举:
服务器初始化启动。
服务器运行期间无法和Leader保持连接。
- 而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态:
集群中本来就已经存在一个Leader。对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连 接，并进行状态同步即可。
集群中确实不存在Leader。 假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举。
选举Leader规则：
- EPOCH大的直接胜出；
- EPOCH相同，事务id大的胜出；
- 事务id相同，服务器id大的胜出
四、节点类型（持久/短暂/有序号/无序号）
持久(Persistent)：客户端和服务器端断开连接后，创建的节点不删除
短暂(Ephemeral)：客户端和服务器端断开连接后，创建的节点自己删除
1. 持久化目录节点：客户端与Zookeeper断开连接后，该节点依旧存在；
2. 持久化顺序编号目录节点：客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号；
3. 临时目录节点：客户端与Zookeeper断开连接后，该节点被删除；
4. 临时顺序编号目录节点：客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号；
说明：创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数 器，由父节点维护
注意：在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序
五、监听器原理
客户端注册监听它关心的目录节点，当目录节点发生变化(数据改变、节点删除、子目 录节点增加删除)时，ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序。
1.监听原理详解
- 首先要有一个main()线程；
- 在main线程中创建Zookeeper客户端，这时就会创建两个线 程，一个负责网络连接通信(connet)，一个负责监听(listener)；
- 通过connect线程将注册的监听事件发送给Zookeeper；
- 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中；
- Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程；
- listener线程内部调用了process()方法；
2.常见的监听
- 监听节点数据的变化：get path [watch]
- 监听子节点增减的变化： ls path [watch]
六、客户端向服务端写数据流程
在了解Zookeeper保证最终一致性之前，先看下涉及到的关键内容。比如ZK内为了保证事务消息，运用到2PC的思想，实际处理写请求的过程中，会经过Proposal流程和Commit流程。
2PC（Two-Phase Commit）
2PC即二阶段提交，与二阶段提交相似的，还有三阶段提交。二阶段提交和三阶段提交可以认为是一种一致性协议，保障在分布式系统中数据的一致性，主要用于分布式事务的场景中。
二阶段提交，顾名思义就是分为两个阶段提交请求嘛，其流程可以认为是准备阶段和提交阶段。以下是简单的概括，其流程和原理实际上挺复杂的，但为了不跑偏文章的主题，就简单的概括一下2PC是什么。
准备阶段：事务的发起者本地执行事务，但不提交事务；然后给各个相关的服务发起分布式事务的提交请求，然后等待其他服务的响应；至于其他接收到提交请求非服务器，会给事务发起者响应ACK，可以简单认为是是否可以执行
提交阶段：当事务发起者收到所有的响应，如果所有的响应都是YES（可以执行），就提交本地事务并让其他服务执行事务请求；如果有部分响应不是YES，则回滚本地请求
Zookeeper处理事务流程
Proposal阶段：Leader会将写请求封装为一个Proposal提案，每个Proposal提案有一个全局Id，即zxid；然后会发送到所有的Follower，当Follower接收到后，会给Leader响应ACK
Commit阶段：当Leader接收到超过一半的Follower响应的ACK，就会认为Proposal发送成功，执行本地事务，并发送Commit消息给所有Follower；当Follower接收到Commit消息后，会将Follower内本地消息提交。
1.写流程之写入请求直接发送给Leader节点
- 客户端发送写请求，Leader接收到写请求后，生成Proposal提案且生成全局的zxid，并将Proposal提案写入磁盘事务日志文件。但实际上，为了提高性能，会先将Proposal写入os cache中，再在某时机将os cache中的内容写入磁盘事务文件
- 写入Proposal提案后，Leader会广播到每个Follower都独有的FIFO队列，这样的话，就能保证数据的顺序执行；当Follower接收到Proposal后，同样会类似Leader那样为了提高写数据的性能，先写到Follower的os cache中，然后在某时机写入磁盘事务日志文件；当Follower写入Proposal后，会给Leader响应ACK
- 当Leader接收到的ACK超过集群的一半，就会认为Proposal提交成功。Leader本地就会执行事务，将数据封装为Znode写到内存中，并发送commit命令给所有Follower，当其它Follower接收到commit命令后，同样会将数据封装为Znode写到内存中。
目前为止，就可以认为写请求处理完毕，客户端可以从Leader读取刚刚的写请求，但如果客户端从Follower读取的话，一定能读取到吗？
其答案是Zookeeper不能保证强一致性，只能保证顺序的最终一致性。咱们回过头想下写请求的事务处理过程。
当写请求生成的Proposal被广播到每一个Follower，只是先写到os cache或磁盘事务日志文件中，这时候并没有生成Znode写到内存，对于客户端来说是读取不到的；如果Leader发出commit请求的时候，由于网络原因或者Follower短暂的失去与Leader的连接，其实都有可能出现短暂的消息不一致，这是如果客户端请求访问还没生成Znode数据的话，肯定读取不到。所以这就解释了，为什么Zookeeper并不能保证强一致性。
但为什么说Zookeeper能保证顺序最终一致性呢？
这是因为Leader与Follower提交Proposal都是经过FIFO的队列，其保证了数据有序。除此之外，如果Leader提交commit后，Follower没有及时接收到commit，会有其他保障机制，保证最后集群内所有服务器都趋于数据一致。
以上就是写请求落在Leader上的大致经过，如果写请求落在Follower是怎样呢？其实流程上是没什么区别的，只不过是Follower将写请求转发给Leader，由Leader去处理写请求，然后就和上诉的流程一样，最后达到数据最终一致。
2.写流程之写入请求发送给follower节点
七、ZooKeeper 分布式锁案例
什么叫做分布式锁呢?
比如说"进程 1"在使用该资源的时候，会先去获得锁，"进程 1"获得锁以后会对该资源保持独占，这样其他进程就无法访问该资源，"进程 1"用完该资源以后就将锁释放掉，让其他进程来获得锁，那么通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。
