zookeeper从零开始学习
目录
一、zookeeper是什么？
Zookeeper是一个分布式协调服务，可以提供分布式锁,服务发现，分布式领导选举，配置管理等，zookeeper提供了一个linux文件系统的树状结构（可以认为是一个轻量级的文件系统，不适合大量存储信息或者大文件），同时提供对每个结点的监控与通知机制
二、zookeeper的组成，是由哪几个模块组成的？
Zookeeper 集群是一个基于主从复制的高可用集群，每个服务器承担以下角色
- leader ：一个zookeeper集群同一时间只能存在一个leader，发起并维护其他follower和observer间的心跳，所有的写请求必须通过leader完成再由leader将写操作广播给其他服务器，只要有超过半数的节点写操作成功(不包含observer)，请求就会被提交(类似2PC协议，经典的强一致、中心化的原子提交协议)
- follower： 一个集群中可能存在多个， 会影响leader的心跳，可以直接处理并返回客户端的读请求，而写请求会转发给leader，负责leader的选举投票
- Observer ：与follower类似，无投票的权力，zookeeper遵从高可用和强一致性(CAP原则-->CP 原则)。为了支持更多的客户端，可能需要更多的server，server增多，投票延迟增大，影响性能。引入observer，不参与投票，它负责接收客户端的请求，并转发给leader节点，加入observer可以提高伸缩性，同时不影响吞吐效率。
三、什么是ZAB 协议？
ZAB(Zookeeper Atomic Broadcast 原子广播协议) 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。
ZAB的两种设计模式
消息广播模式：把数据更新到所有的Follower(同步)
崩溃恢复模式：Leader发生崩溃时，如何恢复(选主)
当整个集群启动过程中，或者当 Leader 服务器出现网络中断、崩溃退出或重启等异常时，Zab协议就会 进入崩溃恢复模式，发起一轮Leader选举并实现数据同步。
当选举产生了新的 Leader，同时集群中有过半的机器与该 Leader 服务器完成了状态同步（即数据同步）之后，Zab协议就会退出崩溃恢复模式，进入消息广播模式。
这时，如果有一台遵守Zab协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么该新加入的服务器自动进入恢复模式：找到Leader服务器，并且完成数据同步。同步完成后，作为新的Follower一起参与到消息广播流程中。
数据更新到所有的Follower
在zookeeper集群中，数据副本的传递策略就是采用消息广播模式。
在zookeeper使用的事务，与二段提交相似，但是却又不同。由Leader服务器负责将一个客户端事务请求，转换成一个事务Proposal 生成一个全局唯一的事务id，并将该 Proposal 分发给集群中所有的 Follower 服务器，Leader服务器需要等待所有Follower服务器的反馈（Ack请求），在Zab协议中，只要超过半数的Follower服务器进行了正确的反馈后（也就是收到半数以上的Follower的Ack请求），那么 Leader 就会再次向所有的 Follower服务器发送 Commit 消息，要求其将上一个 事务proposal 进行提交。而且在协议当中规定每一个消息的严格的顺序关系，所每一个proposal按照其zxid的先后顺序进行排序和处理。
1）客户端发起一个写操作请求。
2）Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的ID，即zxid。
3）Leader 服务器为每个 Follower 服务器分配一个单独的队列，然后将需要广播的 Proposal 依次放到队列中取，并且根据 FIFO 策略进行消息发送。
4）Follower 接收到 Proposal 后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向 Leader 反馈一个 Ack 响应消息。
5）Leader 接收到超过半数以上 Follower 的 Ack 响应消息后，即认为消息发送成功，可以发送 commit 消息。
6）Leader 向所有 Follower 广播 commit 消息，同时自身也会完成事务提交。Follower 接收到 commit 消息后，会将上一条事务提交。
Leader发生崩溃时，如何恢复
一旦 Leader 服务器出现崩溃或者由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式。
在 Zab 协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的 Leader 服务器。因此 Zab 协议需要一个高效且可靠的 Leader 选举算法，从而确保能够快速选举出新的 Leader 。
Leader 选举算法不仅仅需要让 Leader 自己知道自己已经被选举为 Leader ，同时还需要让集群中的所有其他机器也能够快速感知到选举产生的新 Leader 服务器。
崩溃恢复主要包括两部分：Leader选举 和 数据恢复
Leader选举
在集群启动过程中的 Leader 选举过程(算法)与 Leader 断连后的 Leader 选举过程稍微 有一些区别，基本相同。
在Leader 断连后断链的流程中，Leader 挂后，余下的非 Observer 服务器都会将自己的服务器状态由 FOLLOWING 变更为 LOOKING，然后开始进入 Leader 选举过程。
其中选票pk规则如下：
优先检查 ZXID。ZXID 比较大的服务器优先作为 Leader。
如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为 Leader 服务器。
下面是选举流程：
数据恢复
leader选举出来了，下面就要进行数据恢复了
主要分为3步
发现阶段：Followers 和上一轮选举出的准 Leader 进行通信，同步 Followers 最近接收的事务 Proposal 。一个 Follower 只会连接一个 Leader，如果一个 Follower 节点认为另一个 Follower 节点，则会在尝试连接时被拒绝。被拒绝之后，该节点就会进入 Leader Election(选举阶段-选出准leader )阶段。这个阶段的主要目的是发现当前大多数节点接收的最新 Proposal，并且准 Leader 生成新的 epoch ，让 Followers 接收，更新它们的 acceptedEpoch。
同步阶段：同步阶段主要是利用 Leader 前一阶段获得的最新 Proposal 历史，同步集群中所有的副本。只有当 quorum（超过半数的节点） 都同步完成，准 Leader 才会成为真正的 Leader。Follower 只会接收 zxid 比自己 lastZxid 大的 Proposal。
广播阶段（Broadcast）：到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 Leader 可以进行消息广播。同时，如果有新的节点加入，还需要对新节点进行同步。
在同步阶段要考虑下，leader到底是如何挂掉的了其中有2种情况
1.Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃
在同步阶段要考虑下，leader到底是如何挂掉的了其中有2种情况
1.Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃
针对这种情况ZAP定义了：已经被处理的消息不能丢失
因为每次提交的事务都有一个zxid（全局唯一，递增），因此我们只需要找出所有机器内zxid最大的事务（既该事务是最后一个被提交的事务）并且把存放该zxid的机器选举为leader即可，还可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。
2.当leader收到事务请求，并且还没有发起事务投票之前，leader宕机。
针对这种情况ZAP定义了：已经被丢弃的消息不能再次出现
之前宕机的leader节点重新启动之后若再次被选为Leader，要把之前没有commit的事务重新commit，而当前的epoch大于该事务的epoch所以事务会被丢弃而不会被重新加载。也就是只有当事务zxid的epoch和当前的epoch相同时，事务才会被提交。
投票机制
每个 sever 首先给自己投票，然后用自己的选票和其他 sever 选票对比，权重大的胜出，使用权
重较大的更新自身选票箱。具体选举过程如下：
1. 每个 Server 启动以后都询问其它的 Server 它要投票给谁。对于其他 server 的询问，
server 每次根据自己的状态都回复自己推荐的 leader 的 id 和上一次处理事务的 zxid（系
统启动时每个 server 都会推荐自己）
2. 收到所有 Server 回复以后，就计算出 zxid 最大的哪个 Server，并将这个 Server 相关信
息设置成下一次要投票的 Server。
3. 计算这过程中获得票数最多的的 sever 为获胜者，如果获胜者的票数超过半数，则改
server 被选为 leader。否则，继续这个过程，直到 leader 被选举出来
4. leader 就会开始等待 server 连接
5. Follower 连接 leader，将最大的 zxid 发送给 leader
6. Leader 根据 follower 的 zxid 确定同步点，至此选举阶段完成。
7. 选举阶段完成 Leader 同步后通知 follower 已经成为 uptodate 状态
8. Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务了
目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1,2,3,4,5,按编号依次启动，它们
的选择举过程如下：
1. 服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反
馈信息，服务器 1 的状态一直属于 Looking。
2. 服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号
大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是
LOOKING。
3. 服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编
号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器
1,2 成为小弟。
4. 服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的
编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。
5. 服务器 5 启动，后面的逻辑同服务器 4 成为小弟。
四、zookeeper 工作原理(原子广播)？
1. Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制
的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。
2. 当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多
数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了。
3. 状态同步保证了 leader 和 server 具有相同的系统状态
4. 一旦 leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了，即进
入广播状态。这时候当一个 server 加入 zookeeper 服务中，它会在恢复模式下启动，发
现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。Zookeeper
服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的
followers 支持。
5. 广播模式需要保证 proposal 被按顺序处理，因此 zk 采用了递增的事务 id 号(zxid)来保
证。所有的提议(proposal)都在被提出的时候加上
了 zxid。
6. 实现中 zxid 是一个 64 为的数字，它高 32 位是 epoch 用来标识 leader 关系是否改变，
每次一个 leader 被选出来，它都会有一个新的 epoch。低 32 位是个递增计数。
7. 当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，恢复模式
需要重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的状态。
五、zookeeper 四种形式的目录节点？
1. PERSISTENT：持久的节点。
2. EPHEMERAL：暂时的节点。
3. PERSISTENT_SEQUENTIAL：持久化顺序编号目录节点。
4. EPHEMERAL_SEQUENTIAL：暂时化顺序编号目录节点。
总结
希望以后会更加完善维护此专题文章，也希望大家共同交流