1、Zookeeper的角色

  • 领导者（leader），负责进行投票的发动和决定，更新零碎状态。
  • 学习者（learner），包含跟随者（follower）和观察者（bserver），follower用于承受客户端申请并想客户端返回后果，在选主过程中参加投票
  • Observer能够承受客户端连贯，将写申请转发给leader，但observer不加入投票过程，只同步leader的状态，observer的目标是为了扩大零碎，进步读取速度
  • 客户端（client），申请发起方

　　　　

　　　　　

　　Zookeeper的外围是原子播送，这个机制保障了各个Server之间的同步。实现这个机制的协定叫做Zab协定。Zab协定有两种模式，它们别离是恢复模式（选主）和播送模式（同步）。当服务启动或者在领导者解体后，Zab就进入了恢复模式，当领导者被选举进去，且大多数Server实现了和leader的状态同步当前，恢复模式就完结了。状态同步保障了leader和Server具备雷同的零碎状态。

　 为了保障事务的程序一致性，zookeeper采纳了递增的事务id号(zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否扭转，每次一个leader被选出来，它都会有一个新的epoch，标识以后属于那个leader的统治期间。低32位用于递增计数。

　　• 每个Server在工作过程中有三种状态：
　　　　LOOKING：以后Server不晓得leader是谁，正在搜查
　　　　LEADING：以后Server即为选举进去的leader
　　　　FOLLOWING：leader曾经选举进去，以后Server与之同步

其余可考查：[https://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html](https://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html)

2、Zookeeper 的读写机制

*Zookeeper是一个由多个server组成的集群*一个leader，多个follower*每个server保留一份数据正本*全局数据统一*分布式读写*更新申请转发，由leader施行

3、Zookeeper 的保障

* 更新申请程序进行，来自同一个client的更新申请按其发送程序顺次执行。* 数据更新原子性，一次数据更新要么胜利，要么失败。* 全局惟一数据视图，client无论连贯到哪个server，数据视图都是统一的。* 实时性，在肯定事件范畴内，client能读到最新数据。

4、Zookeeper节点数据操作流程

　　　　　　　

　　　　注：1.在Client向Follwer收回一个写的申请

　　　　　　2.Follwer把申请发送给Leader

　　　　　　3.Leader接管到当前开始发动投票并告诉Follwer进行投票

　　　　　　4.Follwer把投票后果发送给Leader

　　　　　　5.Leader将后果汇总后如果须要写入，则开始写入同时把写入操作告诉给Leader，而后commit;

　　　　　　6.Follwer把申请后果返回给Client

　　　　• Follower次要有四个性能：
　　　　• 1. 向Leader发送申请（PING音讯、REQUEST音讯、ACK音讯、REVALIDATE音讯）；
　　　　• 2 .接管Leader音讯并进行解决；
　　　　• 3 .接管Client的申请，如果为写申请，发送给Leader进行投票；
　　　　• 4 .返回Client后果。
　　　　• Follower的音讯循环解决如下几种来自Leader的音讯：
　　　　• 1 .PING音讯： 心跳音讯；
　　　　• 2 .PROPOSAL音讯：Leader发动的提案，要求Follower投票；
　　　　• 3 .COMMIT音讯：服务器端最新一次提案的信息；
　　　　• 4 .UPTODATE音讯：表明同步实现；
　　　　• 5 .REVALIDATE音讯：依据Leader的REVALIDATE后果，敞开待revalidate的session还是容许其承受音讯；
　　　　• 6 .SYNC音讯：返回SYNC后果到客户端，这个音讯最后由客户端发动，用来强制失去最新的更新。

5、Zookeeper leader 选举 　

　　• 半数通过
　　　　– 3台机器 挂一台 2>3/2
　　　　– 4台机器 挂2台 2！>4/2

　　• A提案说，我要选本人，B你批准吗？C你批准吗？B说，我批准选A；C说，我批准选A。(留神，这里超过半数了，其实在事实世界选举曾经胜利了。

　　　然而计算机世界是很严格，另外要了解算法，要持续模仿上来。)
　　• 接着B提案说，我要选本人，A你批准吗；A说，我曾经超半数批准入选，你的提案有效；C说，A曾经超半数批准入选，B提案有效。
　　• 接着C提案说，我要选本人，A你批准吗；A说，我曾经超半数批准入选，你的提案有效；B说，A曾经超半数批准入选，C的提案有效。
　　• 选举曾经产生了Leader，前面的都是follower，只能遵从Leader的命令。而且这里还有个小细节，就是其实谁先启动谁当头。

　　

　　

6、zxid
　　• znode节点的状态信息中蕴含czxid, 那么什么是zxid呢?
　　• ZooKeeper状态的每一次扭转, 都对应着一个递增的Transaction id, 该id称为zxid. 因为zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1必定先于zxid2产生.

　　　创立任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态产生扭转, 从而导致zxid的值减少.

7、Zookeeper工作原理
　　» Zookeeper的外围是原子播送，这个机制保障了各个server之间的同步。实现这个机制的协定叫做Zab协定。Zab协定有两种模式，它们别离是恢复模式和播送模式。
　　　当服务启动或者在领导者解体后，Zab就进入了恢复模式，当领导者被选举进去，且大多数server的实现了和leader的状态同步当前，恢复模式就完结了。
　　　状态同步保障了leader和server具备雷同的零碎状态
　　» 一旦leader曾经和少数的follower进行了状态同步后，他就能够开始播送音讯了，即进入播送状态。这时候当一个server退出zookeeper服务中，它会在恢复模式下启动，
　　　发现leader，并和leader进行状态同步。待到同步完结，它也参加音讯播送。Zookeeper服务始终维持在Broadcast状态，直到leader解体了或者leader失去了大部分的followers反对。

　　» 播送模式须要保障proposal被按程序解决，因而zk采纳了递增的事务id号(zxid)来保障。所有的提议(proposal)都在被提出的时候加上了zxid。
　　　实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否扭转，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
　　» 当leader解体或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式须要从新选举出一个新的leader，让所有的server都复原到一个正确的状态。　
　　» 每个Server启动当前都询问其它的Server它要投票给谁。
　　» 对于其余server的询问，server每次依据本人的状态都回复本人举荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会举荐本人）
　　» 收到所有Server回复当前，就计算出zxid最大的哪个Server，并将这个Server相干信息设置成下一次要投票的Server。
　　» 计算这过程中取得票数最多的的sever为获胜者，如果获胜者的票数超过半数，则改server被选为leader。否则，持续这个过程，直到leader被选举进去　　

　　» leader就会开始期待server连贯
　　» Follower连贯leader，将最大的zxid发送给leader
　　» Leader依据follower的zxid确定同步点
　　» 实现同步后告诉follower 曾经成为uptodate状态
　　» Follower收到uptodate音讯后，又能够从新承受client的申请进行服务了

8、数据一致性与paxos 算法　　

　　• 据说Paxos算法的难了解与算法的知名度一样令人敬佩，所以咱们先看如何保持数据的一致性，这里有个准则就是：
　　• 在一个分布式数据库系统中，如果各节点的初始状态统一，每个节点都执行雷同的操作序列，那么他们最初能失去一个统一的状态。
　　• Paxos算法解决的什么问题呢，解决的就是保障每个节点执行雷同的操作序列。好吧，这还不简略，master保护一个
　　   全局写队列，所有写操作都必须 放入这个队列编号，那么无论咱们写多少个节点，只有写操作是按编号来的，就能保障一
　　　致性。没错，就是这样，可是如果master挂了呢。
　　• Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，
　　　只有取得过半数选票的写操作才会被 批准（所以永远只会有一个写操作失去批准），其余的写操作竞争失败只好再发动一
　　　轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点承受了一个
　　　编号为100的写操作，之后又承受到编号为99的写操作（因为网络提早等很多不可预感起因），它马上能意识到本人 数据
　　　不统一了，主动进行对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。

 举荐书籍：《从Paxos到Zookeeper分布式一致性原理与实际》

9、Observer 　
　　• Zookeeper需保障高可用和强一致性；
　　• 为了反对更多的客户端，须要减少更多Server；
　　• Server增多，投票阶段提早增大，影响性能；
　　• 衡量伸缩性和高吞吐率，引入Observer
　　• Observer不参加投票；
　　• Observers承受客户端的连贯，并将写申请转发给leader节点；
　　• 退出更多Observer节点，进步伸缩性，同时不影响吞吐率

10、 为什么zookeeper集群的数目，个别为奇数个？
　　•Leader选举算法采纳了Paxos协定；
　　•Paxos核心思想：当少数Server写胜利，则工作数据写胜利如果有3个Server，则两个写胜利即可；如果有4或5个Server，则三个写胜利即可。
　　•Server数目个别为奇数（3、5、7）如果有3个Server，则最多容许1个Server挂掉；如果有4个Server，则同样最多容许1个Server挂掉由此，

　　  咱们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节俭服务器资源，个别咱们采纳奇数个数，作为服务器部署个数。

11、Zookeeper 的数据模型
　　» 层次化的目录构造，命名合乎惯例文件系统标准
　　» 每个节点在zookeeper中叫做znode,并且其有一个惟一的门路标识
　　» 节点Znode能够蕴含数据和子节点，然而EPHEMERAL类型的节点不能有子节点
　　» Znode中的数据能够有多个版本，比方某一个门路下存有多个数据版本，那么查问这个门路下的数据就须要带上版本
　　» 客户端利用能够在节点上设置监视器
　　» 节点不反对局部读写，而是一次性残缺读写

12、Zookeeper 的节点
　　» Znode有两种类型，短暂的（ephemeral）和长久的（persistent）
　　» Znode的类型在创立时确定并且之后不能再批改
　　» 短暂znode的客户端会话完结时，zookeeper会将该短暂znode删除，短暂znode不能够有子节点
　　» 长久znode不依赖于客户端会话，只有当客户端明确要删除该长久znode时才会被删除
　　» Znode有四种模式的目录节点
　　» PERSISTENT（长久的）
　　» EPHEMERAL(临时的)
　　» PERSISTENT_SEQUENTIAL（长久化程序编号目录节点）
　　» EPHEMERAL_SEQUENTIAL（临时化程序编号目录节点）