理解zookeeper的选举机制

简介

1. zookeeper是一个分布式协调服务(为其他分布式程序服务)
2. 它自身就是一个分布式服务
3. 提供的服务:主从协调、服务器节点动态上下线感知、统一配置管理、分布式共享锁、统一名称服务……
4. 核心功能:
   
   • 管理用户程序提交的数据
   • 为用户程序提供数据节点监听服务
5. 角色:leader;follower(observer)
   
   • Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO。
   • Follower的逻辑就比较简单了。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。
   • 如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。

机制

只要有半数以上的节点存活,集群就能提供服务(==适合装在奇数台机器上==)

特性

1. Zookeeper：一个leader，多个follower组成的集群
2. 全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
3. 分布式读写，更新请求转发，由leader实施
4. 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
5. 数据更新原子性，一次数据更新要么成功，要么失败
6. 实时性，在一定时间范围内，client能读到最新数据

数据结构

1. 层次化的目录结构，命名符合常规文件系统规范
2. 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
3. 节点Znode可以包含数据和子节点（但是EPHEMERAL类型的节点不能有子节点)
4. 客户端应用可以在节点上设置监视器

节点类型

1. Znode有两种类型：
   短暂（ephemeral）（断开连接自己删除）
   持久（persistent）（断开连接不删除）
2. Znode有四种形式的目录节点（默认是persistent ）
   
   • PERSISTENT
   • PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ）
   • EPHEMERAL
   • EPHEMERAL_SEQUENTIAL
3. 创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护
4. 在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

================================重点内容选举机制==================================

zookeeper的选举机制（全新集群paxos：算法）

举个简单明了的例子

共五人参加选举,第一轮只能选自己,获得选票大于5/2(即2)时,成为leader.
回合一:

A启动,开始第一轮选举,A选择自己.

投票结果:[(A-->A)]

A只获得一票,小于2所以不能成为leader,进入LOOKING(竞选状态)。

回合二:

B启动起来,投票给自己,告诉其他人,并接收到A的(第一回合)投票信息;
此时,A接收到B的(第二回合)投票信息,A知道进入第二回合了,重新投票,由于B的leaderID大,所以A投给了B.

投票结果:[(A-->B),(B-->B)]

B获得两票,但是仍没有超过2,所以A,B进入LOOKING(竞选状态)。

回合三:

C启动起来,投票给自己,告诉其他人,并接收到了A和B的投票信息
此时,AB也接收到了C的投票信息,一看第三回合了,重新投票,由于C的leaderID最大,
就将自己的一票都给了C

投票结果:[(A-->C),(B-->C),(C-->C)]
C获得三票,大于2,所以C进入leaderinng状态


剩下回合,由于C获得的票数已经超过半数,所以D和E的投票是不能改变现实的
=============有人可能会疑问,D的leader比C大啊,他们应该都选D啊?=======