Zookeeper的搭建和使用_第三节_zk其他特性

1.zookeeper实现高可用的原理
参考 https://blog.csdn.net/u010853261/article/details/66476518
主从架构模型 leader节点挂掉 通过选举机制 选出一个来作为leader 避免单点故障高可用很容易理解，就是一台或者一部分服务器都宕机，也能保证正常提供服务。
Zookeeper是分布式管理协作框架，Zookeeper集群用来保证Hadoop集群的高可用。
Zookeeper集群能够保证NameNode服务高可用的原理是：Hadoop集群中有两个NameNode服务，两个NameNode都定时地给Zookeeper发送心跳，告诉Zookeeper我还活着，可以提供服务，某一个时间只有一个是Action状态，另外一个是Standby状态，一旦Zookeeper检测不到Action NameNode发送来的心跳后，就切换到Standby状态的NameNode上，将它设置为Action状态，所以集群中总有一个可用的NameNode，达到了NameNode的高可用目的。
Zookeeper集群也能保证自身的高可用，保证自身高可用的原理是，Zookeeper集群中的各个机器分为Leader和Follower两个角色，写入数据时，要先写入Leader，Leader同意写入后，再通知Follower写入。客户端读取数时，因为数据都是一样的，可以从任意一台机器上读取数据。
这里Leader角色就存在单点故障的隐患，高可用就是解决单点故障隐患的。Zookeeper从机制上解决了Leader的单点故障问题，Leader是哪一台机器是不固定的，而是选举出来的。选举流程是，集群中任何一台机器发现集群中没有Leader时，就推荐自己为Leader，其他机器来同意，当超过一半数的机器同意它为Leader时，选举结束，所以Zookeeper集群中的机器数据必须是奇数。这样就算当Leader机器宕机后，会很快选举出新的Leader，保证了Zookeeper集群本身的高可用。
集群中的写入操作都是先通知Leader，，实际上当超过一半的机器写入成功后，就认为写入成功了，所以就算有些机器宕机，写入也是成功的。 所有的写操作都会被forward到Leader
zookeeperk客户端读取数据时，可以读取集群中的任何一个机器。所以部分机器的宕机并不影响读取。

2.zookeeper是如何保证事物顺序一致性的
假设有一个Zookeeper集群（N>=3，N为奇数），那么只有一个Leader（通过FastLeaderElection选主策略选取），所有的写操作（客户端请求Leader或Follower的写操作）都由Leader统一处理，Follower虽然对外提供读写，但写操作会提交到Leader，由Leader和Follower共同保证同一个Follower请求的顺序性，Leader会为每个请求生成一个zxid（高32位是epoch，用来标识leader选举周期，每次一个leader被选出来，都会有一个新的epoch，标识当前属于哪个leader的统治时期，低32位用于递增计数）
针对同一个Follower A提交的写请求request1、request2，某些Follower虽然可能不能在请求提交成功后立即看到（也就是强一致性），但经过自身与Leader之间的同步后，这些Follower在看到这两个请求时，一定是先看到request1，然后再看到request2，两个请求之间不会乱序，即顺序一致性
zookeeper使用了ZAB(Zookeeper Atomic Broadcast)协议，保证了leader,follower的一致性，leader 负责数据的读写，而follower只负责数据的读，如果follower遇到写操作，会提交到leader;
当leader宕机的话，使用 Fast Leader Election 快速选举出新的leader,节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。
其客户端根据链接的follower不同，可能读取到不同的数据。这是由于副本没有完全同步，存在时间差的原因。由于follower分担了读取数据的压力，zookeeper只要保留全局leader即可，不再进行细分。
如下所示：leader==》读写，follower==>只负责读；
Zookeeper工作方式
》Zookeeper集群包含一个1个Leader，多个Follower
》所有的Follower都可提供读服务
》所有的写操作都会被forward到Leader
》Client与Server通过NIO通信
》全局串行化所有的写操作
》保证同一客户端的指令被FIFO执行
》保证消息通知的FIFO
3.zookeeper是如何选主的
投票机制
半数通过
　　　　– 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的命令。而且这里还有个小细节，就是其实谁先启动谁当头。

Serverid 在myid中 有zookeeper机器的编号
Zxid
注意 版本最新(zkid)的 是 leader （当leader挂掉后）
先看 zkid 后看 myid

4.zookeeper的4种节点类型，有什么区别？

分布式协调系统当做作业来留

特点 说明
最终一致性 为客户端展示同一个视图，这是zookeeper里面一 个非常重要的功能
可靠性 如果消息被到一台服务器接受，那么它将被所有的
服务器接受。（随便连）
实时性 Zookeeper不能保证两个客户端能同时得到刚更新 的数据，如果需要最新数据，应该在读数据之前调 用sync()接口。（最终一致性）
独立性 各个Client之间互不干预
原子性 更新只能成功或者失败，没有中间状态。
顺序性 所有Server，同一消息发布顺序一致。（单点，多点会有事务问题）

特点 说明
最终一致性 为客户端展示同一个视图，这是zookeeper里面一 个非常重要的功能
可靠性 如果消息被到一台服务器接受，那么它将被所有的
服务器接受。（随便连）
实时性 Zookeeper不能保证两个客户端能同时得到刚更新 的数据，如果需要最新数据，应该在读数据之前调 用sync()接口。（最终一致性）
独立性 各个Client之间互不干预
原子性 更新只能成功或者失败，没有中间状态。
顺序性 所有Server，同一消息发布顺序一致。（单点，多点会有事务问题）

5.工作原理
6.» Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。
7.　　　当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。
8.　　　状态同步保证了leader和server具有相同的系统状态
9.　　» 一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，
10.　　　发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分
11.　　　的followers支持。
12.　　» 广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。
13.　　　实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
14.　　» 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。　
15.　　» 每个Server启动以后都询问其它的Server它要投票给谁。
　　» 对于其他server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）
　　» 收到所有Server回复以后，就计算出zxid最大的哪个Server，并将这个Server相关信息设置成下一次要投票的Server。
　　» 计算这过程中获得票数最多的的sever为获胜者，如果获胜者的票数超过半数，则改server被选为leader。否则，继续这个过程，直到leader被选举出来　　
16.　　» leader就会开始等待server连接
　　» Follower连接leader，将最大的zxid发送给leader
　　» Leader根据follower的zxid确定同步点
　　» 完成同步后通知follower 已经成为uptodate状态
　　» Follower收到uptodate消息后，又可以重新接受client的请求进行服务了