Zookeeper选举机制及相关概念

server和client：
server    指集群的每一台机器
client      指每一个向server请求服务的机器
zookeeper角色：
leader：为客户端提供写服务，负责进行投票的发起和决议，更新系统状态，事务请求的唯一调度和处理者
follower：为客户端提供读服务，参与投票，包括事务请求proposal投票和leader选举投票，接收客户端请求，为客户端返回结果
observe：为客户端提供读服务，不参与任何投票，包括事务请求proposal投票和leader选举投票，同步leader的状态，加快读写速度
znode（数据节点）：
zookeeper将所有数据存在内存中，数据模型是一棵树，用斜杠/进行分割的路径就是一个znode，zkCli.sh使用命令行就是对znode的操作
zap协议
为保证zookeeper服务的原子性，保证每个server间的状态同步，包括两种模式：
崩溃恢复模式：当服务启动或leader服务器崩溃退出与重启，zap进入崩溃恢复模式，选举leader服务器或新的leader服务器，当leader被选举出来后，且集群中有过半的机器完成与leader服务器的状态同步，zap就退出恢复模式
消息广播模式：当集群中有过半的follower完成 与leader的状态同步，就进入消息广播模式。当有新的server加入到zookeeper服务中，会以恢复模式启动，找到leader服务器，完成状态同步，然后一起参与到消息广播模式
zookeeper特性：
顺序一致性：同一个客户端的请求严格按照其发起的顺序执行
原子性：事务的一次执行在每个server上应该是一致的，要么都执行，要么都不执行
单一视图：每个server的数据视图都是一样的
实时性：在一定时间内，zookeeper应该保证client读取的数据是最新的
zookeeper选举
zookeeper节点状态：
LOOKING
LEADING
FOLLOWERING
OBSERVE
当最初的时候，每个server的最初状态都是LOOKING，当leader服务器选举出来后，leader服务器状态变为LEADING，不是observe服务器的server的状态自动变为FOLLOWERING，当leader服务器挂掉之后，所有非observe的server将状态都改为LOOKING，进行新的选举，选举出新的leader服务器，然后leader服务器状态变为LEADING，不是observe的server的状态自动变为FOLLOWERING。
zxid（zookeeper事务id）:zookeeper状态每次改变都会收到一个不同全局唯一的zxid，删除节点，创建节点都会使zookeeper状态改变，zxid不断递增
leader服务器选取规则：
优先检查zxid，zxid大的作为leader服务器
zxid，相同就比较myid大小，myid大的作为leader服务器
只有获取过半server的支持才能成为leader
zookeeper选举算法：
basic paxos和fast paxos
basic paxos：选举线程向所有server发起一次询问，按照服务器选取规则去比较，选出下一次要询问的server，当被选取的server有一般server支持，则成为leader服务器，不然就一直选举，直到选出了leader
fast paxos：一个server声明自己要做leader，其它server将配合工作，解决zxid和epoch冲突，并向该server发送接收提议的消息
zookeeper命令行使用：
将zookeeper加入环境变量后，在命令行运行zkCli.sh进入zookeeper命令行，连接不同的主机用./zkCli.sh -server ip:port
创建节点（znode）：create [-s][-e] path data acl -s为顺序节点，-e为临时节点，退出zookeeper命令行后就删除，不指定默认为永久节点 例：create /zk-permanent 123 创建永久节点/zk-permanent
读取节点（znode）：ls path 或者 ls2 path 或者 get path 例：ls / 查看根目录下的znode，get或ls2 /zk-permanent查看节点 /zk-permanent的详情
更新节点（znode）：set path data 例：set /zk-permanent 456 将/zk-permanent的内容更新为456
删除节点（znode）：delete path 例：delete /zk-permanent，注意，若删除节点存在子节点，则无法完成删除，必须先删除子节点才能删除父节点