前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >分布式进阶__zookeeper的zab协议工作原理之原子广播

分布式进阶__zookeeper的zab协议工作原理之原子广播

原创
作者头像
矿泉水
发布2018-05-11 11:50:52
1K3
发布2018-05-11 11:50:52
举报
文章被收录于专栏:风中追风

说zab协议之前必须提一下 paxos 协议 

paxos协议主要就是如何保证在分布式环网络环境下,各个服务器如何达成一致最终保证数据的一致性问题

ZAB协议,基于paxos协议的一个改进。

zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议

zookeeper并没有完全采用paxos算法, 而是采用zab Zookeeper atomic broadcast

zab协议的原理

1. 在zookeeper 的主备模式下,通过zab协议来保证集群中各个副本数据的一致性

2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求,并采用zab协议,

把数据的状态变更以事务请求的形式广播到其他的节点

3. zab协议在主备模型架构中,保证了同一时刻只能有一个主进程来广播服务器的状态变更

4. 所有的事务请求必须由全局唯一的服务器来协调处理,这个的服务器叫leader,其他的叫follower

leader节点主要负责把客户端的事务请求转化成一个事务提议(proposal),并分发给集群中的所有follower节点

再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈,那么leader就会commit这条消息。

5.然后再进行leader 和 follower 直接的数据同步。

这里有几个地方要注意一下:

1、follower服务器的投票并不是真正意义上的投票,而是follower 服务器 表示收到了 leader节点发过来的消息,给予一个收到的提示。 跟分布式事务中的 两阶段提交 中的第一阶段类似。

2、zab协议 与 分布式事务不同的是, 分布式事务 的两阶段提交要求所有事务处理节点(器)都要投票同意。

    而zab协议中 只要求半数 服务器节点投票同意即可。

    为什么只要半数就可以了呢?是因为zab协议就是为了保证在网络不可靠的情况下,整个集群还能正常的工作。

    有超过半数的服务器投票同意,那么leader节点就执行写的操作,commit之后,再进行原子广播给其它的follower节点, 让 follower节点来同步数据

    如果跟两阶段提交一样,还需要所有节点都同意的话,那明显与zab协议的使用场景不同了。

图的流程大致是:

1、客户端发来一个request给第一个follower节点,如果是读请求,follower节点直接将数据返回。

2、如果是写请求,也就是事务请求,那么follower节点就将请求转发给leader,leader再像集群中的 follower节点发起一个事务请求提议(proposal)。

3、follower节点正常情况下 都会返回一个ack 给 leader ,表示 follower 节点收到 leader的消息了,这里就是所谓的投票。

    正常情况下都会投票的,没有投票的情况就是 有的follower 节点 挂掉了 投不了票就没投。

3、当机器中超过半数的服务器 都投票了(leader 自己本身也参与投票),那么 leader就commit 这个事务请求,然后再通过原子广播 通知 集群中其它的 follower 跟 Ob 节点来同步数据。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • zab协议的原理
相关产品与服务
数据集成
数据集成(DataInLong)源于腾讯开源并孵化成功的 ASF 项目 Apache InLong(应龙),依托 InLong 百万亿级别的数据接入和处理能力支持数据采集、汇聚、存储、分拣数据处理全流程,在跨云跨网环境下提供可靠、安全、敏捷的全场景异构数据源集成能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档