目录
1.工作原理
2.选举概述
3.选举机制
1.工作原理
zookeeper是一个分布式应用程序协调服务、开源的组件，有分布式服务的基本都可以用zookeeper。
- 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的请求进行服务了
- zookeeper的角色
» 领导者（leader），负责进行投票的发起和决议，更新系统状态
» 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
» Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
» 客户端（client），请求发起方
obServer:
为了使用observer模式，在任何想变成observer模式的配置文件中加入如下配置：
peerType=observer
并在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：
server.1:localhost:2181:3181:observer
- zookeeper的读写机制
» Zookeeper是一个由多个server组成的集群
» 一个leader，多个follower
» 每个server保存一份数据副本
» 全局数据一致
» 分布式读写
» 更新请求转发，由leader实施
- zookeeper的保证
» 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
» 数据更新原子性，一次数据更新要么成功，要么失败
» 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
» 实时性，在一定事件范围内，client能读到最新数据
- 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结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
zookeeper节点有四种状态，Looking、Following、Leading、Observing
Looking：寻找Leader状态，当Server处于该状态时，此Server会认为当前集群中没有Leader，需要进入Leader选举状态。
Following： 跟随者状态，表明该Server角色为Follower。
Leading： 领导者状态，表明当前服务器角色是Leader。
Observing： 观察者状态，表明当前服务器角色是Observer。
- zookeeper的zxid
• znode节点的状态信息中包含czxid, 那么什么是zxid呢?
• ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.
创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.
事务日志
事务日志指zookeeper系统在正常运行过程中，针对所有的更新操作，在返回客户端“更新成功”的响应前，zookeeper会保证已经将本次更新操作的事务日志已经写到磁盘上，只有这样，整个更新操作才会生效。
根据上文所述，可以通过zoo.cfg文件中的dataLogDir配置项找到事物日志存储地点：
在datalog/目录下存在一个文件夹version-2，该文件夹中保存着事物日志文件:
**表示写入该日志的第一个事务的ID，十六进制表示。
zookeeper的事务日志为二进制文件，不能通过vim等工具直接访问。其实可以通过zookeeper自带的jar包读取事务日志文件。
- zookeeper的节点
» Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
» Znode的类型在创建时确定并且之后不能再修改
» 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
» 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
» Znode有四种形式的目录节点
» PERSISTENT（持久的）
» EPHEMERAL(暂时的)
» PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）
» EPHEMERAL_SEQUENTIAL（暂时化顺序编号目录节点）
2.选举概述
Leader选举是ZooKeeper中最重要的技术之一，也是保证分布式数据一致性的关键所在。
从3.4.0版本开始，ZooKeeper只保留了TCP版本的FastLeaderElection选举算法。
3.选举机制
- 形象化举例
• 半数通过
– 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的命令。而且这里还有个小细节，就是其实谁先启动谁当头。
为什么要进行Leader选举？
Leader主要作用是保证分布式数据一致性，即每个节点的存储的数据同步。遇到以下两种情况需要进行Leader选举
1）服务器初始化启动
2）服务器运行期间无法和Leader保持连接，Leader节点崩溃，逻辑时钟崩溃。
1.服务器初始化时Leader选举 zookeeper由于其自身的性质，一般建议选取奇数个节点进行搭建分布式服务器集群。以3个节点组成的服务器集群为例，说明服务器初始化时的选举过程。启动第一台安装zookeeper的节点时，无法单独进行选举，启动第二台时，两节点之间进行通信，开始选举Leader。
1）每个Server投出一票。他们两都选自己为Leader，投票的内容为（SID，ZXID）。SID即Server的id，安装zookeeper时配置文件中所配置的myid；ZXID，事务id，为节点的更新程度，ZXID越大，代表Server对Znode的操作越新。由于服务器初始化，每个Sever上的Znode为0，所以Server1投的票为（1,0），Server2为（2,0）。两Server将各自投票发给集群中其他机器。
2）每个Server接收来自其他Server的投票。集群中的每个Server先判断投票有效性，如检查是不是本轮的投票，是不是来Looking状态的服务器投的票。
3）对投票结果进行处理。先了解下处理规则 - 首先对比ZXID。ZXID大的服务器优先作为Leader - 若ZXID相同，比如初始化的时候，每个Server的ZXID都为0，就会比较myid，myid大的选出来做Leader。 对于Server而言，他接受到的投票为（2,0），因为自身的票为（1,0），所以此时它会选举Server2为Leader，将自己的更新为（2,0）。而Server2收到的投票为Server1的（1,0）由于比他自己小，Server2的投票不变。Server1和Server2再次将票投出，投出的票都为（2,0）。
4） 统计投票。每次投票之后，服务器都会统计投票信息，如果判定某个Server有过半的票数投它，那么该Server将会作为Leader。对于Server1和Server2而言,统计出已经有两台机器接收了（2,0）的投票信息，此时认为选出了Leader。
5）改变服务器状态。当确定了Leader之后，每个Server更新自己的状态，Leader将状态更新为Leading，Follower将状态更新为Following。
2.服务器运行期间的Leader选举 zookeeper运行期间，如果有新的Server加入，或者非Leader的Server宕机，那么Leader将会同步数据到新Server或者寻找其他备用Server替代宕机的Server。若Leader宕机，此时集群暂停对外服务，开始在内部选举新的Leader。假设当前集群中有Server1、Server2、Server3三台服务器，Server2为当前集群的Leader，由于意外情况，Server2宕机了，便开始进入选举状态。过程如下
1） 变更状态。其他的非Observer服务器将自己的状态改变为Looking，开始进入Leader选举。
2） 每个Server发出一个投票（myid，ZXID），由于此集群已经运行过，所以每个Server上的ZXID可能不同。假设Server1的ZXID为145，Server3的为122，第一轮投票中，Server1和Server3都投自己，票分别为（1，145）、（3,122）,将自己的票发送给集群中所有机器。
3） 每个Server接收接收来自其他Server的投票，接下来的步骤与初始化时相同。
