Zookeeper工作原理

最新推荐文章于 2021-05-25 06:49:22 发布

乘风御浪云帆之上

最新推荐文章于 2021-05-25 06:49:22 发布

阅读量656

点赞数 1

分类专栏： zookeeper 文章标签： zookeeper 工作原理 zookeeper工作原理

本文链接：https://blog.csdn.net/eieiei438/article/details/88392538

版权

zookeeper 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Zookeeper工作原理

Zookeeper的工作原理

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

Zookeeper角色

角色名称	英文名	主要功能	备注
领导者	leader	负责进行投票的发起和决议，更新系统状态
学习者之跟随者	learner-follower	用于接收客户端请求并向客户端返回结果	在选举过程中参与投票
学习者之观察者	learner-observer	接收客户端的的连接，将写请求转发给leader	不参与投票过程，只同步leader的状态，目的是为了扩展系统
客户端	client	请求发起发

摘用图示

Zookeeper核心

原子广播
- 这个机制保证了各个Server之间的同步，实现这个机制的协议为Zab协议，它有两种模式：恢复（选主）模式和广播（同步）模式，当服务启动或者在领导者崩溃时，Zab进入恢复模式，当领导者被选举出来并且大部分Server完成了和leader同步状态之后，恢复模式就结束了，状态同步保证了leader和Server具有相同的系统状态
- 为了保证事务的顺序一致性，zookeeper采用的是递增的事务id号即zxid来标识事务，所有的提议（proposal）都是在被提出之后加上了zxid，zxid是64位的数字，高32位是epoch用来标识leader关系是否改变，每一次leader被选出来，它会有新的epoch，标识当前属于哪个leader，低32位用于递增计数
- 每个Server有三种工作状态
  1. LOOKING，当前的Server不知道谁是leader，正在搜寻
  2. LEADING，当前的Server为被选出来的leader
  3. FOLLOWING，leader已经被选出来，当前Server与之同步
zxid
- Zookeeper状态的每一次改变，都对应这一个递增的Transaction的id，如果zxid1小于zxid2，则1先于2发生；创建任意节点或者更新删除节点数据，都会导致Zookeeper状态发生改变，从而导致zxid的值增加

Zookeeper的读写

Zookeeper是一个由多个server组成的集群，一个leader多个follower，每个server保存一份数据副本，全局数据一致，采用分布式读写数据，更新请求转发由leader管理

Zookeeper数据一致性的原理

更新请求顺序进行，来自同一个client的更新请求按其发送的顺序依次执行，数据更新原子性--要么成功，要么失败；数据视图一致；实时性，client读取最新的数据
节点数据同步流程
1. Client向Follower发出一个写请求
2. Follower把请求发送给Leader
3. Leader接收到以后开始发起投票并通知Follower进行投票
4. Follower把投票结果发送给Leader
5. Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit
6. Follower把请求结果返回给Client

Follower

-主要功能 - 向Leader发送请求 - 接收Leader消息进行处理 - 接收Client的请求，如果为写请求，则交给Leader进行投票 - 返回Client结果 - 消息循环处理 - PING：心跳消息 - PROPOSAL：Leader发起的提案，要求Follower进行投票 - COMMIT：服务器最近的提案信息 - UPTODATE：表明同步完成 - REVALIDATE：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许接受消息 - SYNC：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新

Observer

Zookeeper需要保证高可用和强一致性
为了支持更多的客户端，需要增加更多的server
server增多，投票阶段延迟增大，影响性能
权衡伸缩性和高吞吐率，引入Observer
Observer不参与投票
Observer接受客户端的连接，并将写请求转发给leader节点
加入更多的Observer节点，提高伸缩性，同时不影响吞吐率

Zookeeper的选举机制

半数通过
- A（选自己，BC同意吗？），B（同意），C（同意）
- B（选自己，AC同意吗？），A（A已经半数同意，B提案无效），C（A已经半数同意，B提案无效）
- C（选自己，AB同意吗？），A（A已经半数同意，C提案无效），B（A已经半数同意，C提案无效）
工作状态
选举状态

paxos算法

数据一致性：在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么它们最后能得到一个一致的状态
paxos：通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作去争取选票，只有半数以上才会批准，其他操作只能继续发起投票，严格编号排序，当序号大的执行完小的又来执行，则自动停止对外服务并重启同步过程，任何一个节点挂掉都不影响整个集群的数据一致性
小故事
- Paxos描述了这样一个场景，有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效。每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。
- 好，现在议会开始运作，所有议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。其他议员收到消息以后查了一下记事本，哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。
- 现在看冲突的解决：假设总共有三个议员S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。S1想设为1元/度, S2想设为2元/度。结果S3先收到了S1的提议，于是他做了和前面同样的操作。紧接着他又收到了S2的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号1，于是他拒绝了这个提议：对不起，这个提议先前提过了。于是S2的提议被拒绝，S1正式发布了提议: 1号提议生效。S2向S1或者S3打听并更新了1号法令的内容，然后他可以选择继续发起2号提议。
- 角色
```
小岛(Island)——ZK Server Cluster

议员(Senator)——ZK Server

提议(Proposal)——ZNode Change(Create/Delete/SetData…)

提议编号(PID)——Zxid(ZooKeeper Transaction Id)

正式法令——所有ZNode及其数据
```
- 貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos的作者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。