对于学的live来进行笔记和总结，对于后面面试需要的知识点再慢慢补充。
为什么要用到Zookeeper？
单独开发的时候，我们只需要单独配置文件即可；但分布式开发的时候我们需要配置多个文件，这个时候双方的响应会很复杂。例如有三个配置文件，此时客户端发送请求则需要向三个配置文件都发送请求，而三个配置文件收到请求之后还需要都反馈给客户端。
解决：此时我们可以将三个配置文件抽象出来一个服务节点来处理，这样客户端就可以只向服务节点发送请求一次，而服务节点也只需要向客户端响应一次即可。
此时会遇到一个新的问题，假如服务节点宕机了话，那服务就会全盘停止。所以此时我们想建立多个服务节点，这样就算单个服务节点宕机，我们还有其他的服务节点可以提供服务。但这样又会遇到几个问题：①服务节点之间的同步一致性如何保证？②当客户端发来请求的时候，那个服务节点去响应？
解决：此时，我们就可以使用Zookeeper来解决这个问题。
Zookeeper是如何解决这个问题的呢？就要了解Zookeeper是什么。
一、Zookeeper
Zookeeper框架结构
zk的框架分别由不同的服务节点组成，每个节点具有不同的角色；Zookeeper角色分别有：Follower跟随者 、Observe观察者、Leader领导者、Leaner学习者；其中Leader只能有一个，是通过Follower角色选举出来的；其他角色没有投票权。
Follower跟随者：①具有投票权、②将事务请求转发给Leader，自身可处理非事务请求。
Observe观察者：可接受客户端连接，将客户端的事务请求转给Leader，主要作用是提高客户端的读取速度。
Leader领导者：处理事务请求；
Leader是如何处理事务请求的会涉及到zk的一个数据模型。
Zookeeper数据模型
①zk的数据模型是分层次的树型结构
②每个服务节点在zk中就是一个znode，且有一个唯一的路径标识
③每个节点可以包含2m左右的数据，超过会报错
④节点的数据可以更改，更改后会更新。
同时可以在每个 跟节点 下创建子节点，子节点有分别有不同的类型
Zookeeper节点类型
zk中的节点分别有三种类型：持久、临时、顺序。——例如在node根节点上创建一个子节点为node1
持久节点：将这个子节点设置为持久节点，只有从客户端手动删除它才会消失。
临时节点：若将节点node1设置为 临时节点，客户端会和zk通过心跳维持连接，客户端宕掉之后，这个连接就会消失，这个临时节点也会自动消失。
顺序节点：在根节点下创建一个 子节点一会在子节点后面添加一个 尾缀标识 -1，依次类推，这就是顺序节点。
Zookeeper读写机制（具体待了解）
zk中 由Follower处理读的事务请求，由Leader处理写的事务请求（通过Follower和Observe转发事务请求给Leader）
每个Server会保存一份数据副本，来实现在数据发生更改时，全局数据能够统一。
保证
①客户端的请求会按照请求的先后顺序依次执行（例如客户端发送了事务请求，然后再发送非事务请求，这两个请求是按照顺序来执行的）
②数据更新原子性，数据的更新要么成功要么失败
③全局唯一的数据视图，Client客户端无论连接到那个Server，数据视图都是一致的。
④实时性，在一定事件的范围内，Client客户端能持续读到最新数据（设计Paxos算法的过半提交）
侦听机制Watcher
Watcher在Zookeeper中是一个核心功能，watcher可以监控 跟目录节点 和 子目录节点的变化，一旦目录发生变化，服务器就会通知所有设置在这个目录节点上的watcher，从而每个客户端就会很快知道它所关注的目录节点的状态发生变化，从而做出响应的反应。（例如一个家庭定位器，这个定位器也就是Watcher，家庭的所有成员都在这个定位器上注册了，家庭的老一辈就会说根节点，小一辈就是子节点，不论那个节点发生变化，家庭定位器都能够清楚的知道，并且显示出来给保管家庭地位器的人）
Zookeeper的一些其他问题澄清：
zk如何保证服务节点数据的一致性？
配置文件在服务节点Server中，每个Serverd都会备份一份；并且每个Server会在配置文件中注册一个监听器来实时获取配置文件的修改情况；
当客户端进行第一次操作时需要获取配置文件，此时会向服务节点获取配置文件；
若客户端对配置文件进行了修改，则Server服务节点通过在配置文件的监听器得知配置文件被修改，就会将客户端修改的那部分配置文件复制一份到服务节点，同时通知其他Server节点，然后进行同步。
zk的服务节点是如何提供服务的？
客户端会维护着一份zk集群的目录节点列表，它有一个选择节点的算法（可以选择随机、或者轮循的算法）去执行它的访问。
二：Zookeeper的底层ZAB协议
首先，Zab协议结合了两阶段提交和Paxos算法，所以先理解两阶段提交和Paxos算法能够更加容易理解Zab协议。
两阶段提交：两阶段提交分别是：第一阶段：提交事务请求（三个小点）、第二阶段：执行事务请求（四个小点）
阶段一：提交事务阶段，用户提交请求，判断用户的数据是否可以执行其请求
1、事务询问：客户端发送事务请求给协调者，协调者询问服务节点是否可以操作（例如：用户在支付宝请求付款，协调者告诉服务节点（配置信息））
2、执行事务：各参与者执行事务操作，并将undo和redo信息记入事务日志（例如：记录用户的交易信息和操作）
3、参与者向协调者反馈事务询问的结果：如果参与者成功执行了书屋操作，那么就反馈给协调者yes响应。表示事务可以执行。反之则不可以。（例如：参与者查看额度足够，则给协调者yes响应，表示可以支付。反之则表示额度不足，不可以执行事务）
阶段二：执行事务阶段，用户的请求和其信息相符，则开始执行用户的请求，并反馈给用户
——协调者收到参与者‘可以执行事务’的结果后，进行具体的操作：
1、协调者发送信息给参与则，表示参与者可以开始执行事务。
2、参与者接收到之后执行事务，执行完事务之后并释放暂用的资源。
3、参与者发送执行完事务操作的消息给协调者
4、协调者接收参与则发送的信息，完成事务
两阶段提交的优缺点：
优点：原理简单，实现方便。
缺点：同步阻塞 - 在两阶段提交的第二个阶段会发生这个同步阻塞的问题。
在事务执行阶段有三个参与则，前两个参与者一和二执行快（网络原因），第三个参与则执行慢（网络原因），则前面两个需要等第三个执行完才能进行提交。脑裂（待）
Paxos算法
定义：Paxos算法解决的问题就是如何在一个可能发生宕机或者网络异常的分布式系统中，快速且正确的在集群内部对某个数据的值达成一致。
Paxos组成：
Proposer提案提出者：会有多个提案提出者，每个人会提出自己的提案
Acceptor议员：议员是一个‘’集合‘’进程，也就是说会有多个议员来决定是否通过，超过一半以上的议员同意提案才能通过
Leaner（学习者）：学习提案的结果......(略)
Paxos算法包括两个步骤：
1、提案生成
2、批准提案
Paxos算法例子理解：（待补充.....）
就好比有一个军队，有多个首领组成Acceptor，军队除了首领之外的士兵都是Proposer。
士兵提出某个提案给首领决定......大概就是士兵的例子辅助自己理解Paxos算法
为什么说ZAB协议是结合了两阶段提交和Paxos算法呢？？？
三：Zookeeper核心内容
Zookeeper的组成：Leader（接受所有的事务请求）、Follower（历史事务集合）、Observe（不参与选举，提高读性能）
Zxid：
ZAB协议概念：
ZAB的组成：故障恢复 和 消息广播，故障恢复分为两部分。
故障恢复
1、新Leader选举：
2、数据同步——分为三个part，需要总结一下。2.1：数据队列 - 协议层面讲解数据同步2.2：故障恢复，算法描述（协议层面讲解）2.3：数据同步具体实现
补充：故障恢复，又分为：数据同步，Leader选举、lastLeaderelection算法
lastLeaderelection算法：
消息广播
四、Zookeeper的应用场景
来源：oschina
链接：https://my.oschina.net/u/4432600/blog/4282036