zookeeper的了解以及选举算法介绍

zookeeper数据模型
   数据节点我们称为Znode，znode是zk中的最小单元，每个znode上都可以保存数据同时
   可以挂载子节点，因此构成了一个层次的命名空间，我们称之为树
树
       znode的节点路径标识方式与unix文件系统路径非常相似，都是由一些列的使用斜杠（/）
进行分割表示
事务ID
      事务是物理和抽象的应用状态的操作集
zk中，事务是指能够改变zk服务器状态的操作，我们也称之为事务的操作或更新操作
，一般包括数据节点创建与删除、数据节点的内容更新和客户端会话创建与失效等
操作，对于每一个事务请求，zk都会为其分配一个全局唯一的事务id，用zxid来表示
，通常是一个64位的数字。每一个Zxid对应一次更新操作，
节点特性
       持久节点、临时节点、顺序节点
状态信息
       get命令获取一个数据节点的内容
保证分布式原子性操作
Watcher 数据通知变更
        zk提供了一个分布式数据的订阅与发布，这个发布订阅模式定义了一种一对多的订阅
关系，能够让多个订阅者同时监听某一个主题对象，当这个主题自身状态变化时，会
通知所有的订阅者，他们能够做出相应的处理，在zk中引入了watcher机制。
Watcher接口
       包含keeperState和EventType俩个枚举类，通知状态和事件类型，同时定义了事件的
回调方法：process（WatchedEvent event）
工作机制
    zk的watcher机制：
客户端注册watcher
服务端处理watcher
客户端回调wathcer
服务端处理watcher
        服务端用serverCnxn储存
serverCnxn是一个zk客户端与服务端的之间的接口连接，代表一个客户端与服务器之间
连接。
Leader选举过程
    服务器启动时期的leader选举
在服务器初始化集群的阶段，当有一台（server1）服务器启动的时候，leader 是无法完成选举的
当第二台机器（server2）也启动后，此时俩台机器可以进行相互通信，每台机器都
视图找到一个leader，于是便进入了leader选举流程
1.每个server会发出一个投票
由于初始情况，因此server1与server2来说，都将自己作为leader服务器进行投票
每次投票包含基本元素：所选举的服务器myid和zxid，我们可以（myid，zxid）的
形式来表示。因为是初始化阶段，因此无论是server1还是server2，都会投给自己，
即server1的投票为（1,0），server2的投票为（2,0），然后将各自的投票发给集群
中的其他机器。
2.接收来自各个服务器的投票
每个服务器都会接收到其他服务器的投票，集群中每个服务器在接收投票，首先判断
投票的有效性，包括本轮投票、是否来自looking状态的服务器
3.处理投票
在接收来自其他服务器的投票后，针对每一个投票，服务器都需要将别人的投票和自己
的投票进行PK，pk规则如下
优先检查zxid。zxid比较大的服务器作为leader，如果zxid相同的话，那么比较myid，
myid较大的作为leader服务器。对于server1来说，会更新自己的投票，然后将投票重新发出去，对于
server2来说只需要将上一次投票信息发出去即可。
4.统计投票
每次投票后，服务器都会统计所有的投票，判断是否已有过半的机器接收到相同的
投票信息了，过半即（n/2）+1；即server1与server2都接收到相同信息（2,0）的时候
即认为选出了leader
        5.改变服务器状态
一旦确定了leader，每个服务器都会更新自己的状态：如果是follower，那么将变成为
following，如果是leader，那么会变成leading。
服务器运行期间的leader选举
     一旦leader挂了，那么整个集群都将暂时无法对外提供服务，而进入新一轮的leader
    选举，服务器运行期间选举和启动leader选举过程是一致的。
    1.变更状态
    当leader挂了之后，余下的非observer服务器都将自己的状态变更为looking，然后
    开始进入leader选举流程
    2.每个server会发出投票
    3.接收来自各个服务器的投票
    4.处理投票
    5.统计投票
    6.更改服务器状态
服务器状态
    looking寻找leader状态。当服务器处于该状态时，它会认为当前集群没有leader。因此
    需要进入leader选举流程。
    following：跟随者状态，表名该服务器是leader。
    leading：领导者状态，
    observing：观察者状态，表名当前服务器是observer。
投票数据结构
    Vote：id被推举的leader的sid值
          zxid被推举的leader事务id
          electionEpoch：逻辑时钟，用来判断多个投票是否在同一个选举周期。该值
          在服务端是一个自增序列，每次进入新一轮投票后，都会对该值进行加1操作
          peerEpoch：被推举的leader的epoch
          state：当前服务器状态
QuorumCnxManager:网络io
    每次服务启动的时候，都会启动一个quorumCnxManager，负责各台服务器之间的底层
    leader选举过程中的网络通信。在quorunCnxManager内部维护了一系列的队列，用于
保存接收、待发送的消息，以及消息发送器。
建立连接
        为了能够进行投票，zk集群中的所有机器都需要俩俩建立起网络连接。QuorumCnxManager
        在启动时候，会创建ServerSocket来监听Leader选举的通信端口。开启端口监听后，zk
能够不断接收地接收来自其他服务器的创建连接，在接收其他服务器的tcp连接时候，会交
由receiveConnection函数处理。为了避免俩台机器之间重复创建TCP连接，zk设计了
一种建立TCP的连接规则：只允许sid大的服务器主动和其他服务器建立连接，否则断开
连接，一旦建立连接，就会根据远程服务器sid来创建对应的消息发送器sendworker
和消息接收器RecWorker，并启动他们。
消息的接收与发送
    通过recvWorker与SendWorker进行相应的操作。
FastLeaderElection选举算法核心部分
    外部投票：特指其他服务器发来的投票
内部投票：自身的投票
选举轮次：zk服务器的leader选举的轮次
pk：指对内部投票和外部投票的进行一个对比来确定是否需要变更内部投票。
    1.自增选举轮次
2.初始化投票：（见Vote）

3.初始发送投票。zk会将刚刚初始化好的投票放入

sendqueue队列中，由workerSender

负责发送出去
4.接收外部投票。
5.判断选举轮次
        外部投票大于内部投票，那么就会更新自己的选举轮次，那么立即更新自己的选举
轮次，并清空之前接收到投票，然后使用初始化的投票来进行pk以确定是否需要变更
内部投票：自身的投票
外部投票轮次小于内部的投票，不做任何处理，返回步骤4
6.选票pk
1.如果外部被推举的leader服务器的选举轮次大于内部投票，那么就进行投票变更。
2.如果选举轮次一样的话，那么就比较俩者的事务zxid。如果外部的投票的zxid
大于内部投票，那么进行变更
        3.如果俩者的zxid一致的话，那么就比较俩者的sid，如果sid大于内部投票的话
那么就进行变革。
7.变更投票
   使用外部投票覆盖内部投票，变更完成后，将变更后的投票发出去。
8.选票归档。
9.统计投票
统计集群中是否有过半的服务器认可了当前的内部投票。否则返回步骤4
10.更新服务器状态。