请选择 进入手机版 | 继续访问电脑版

分布式一致性协议2pc 3pc paxos zab 和zookeeper原理解析

[复制链接]
东方龙头 发表于 2021-1-2 17:36:39 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
从paxos到zookeeper 分布式一致性

本文从分布式系统到分布式事务的一致性的各种协议再到zk的是如何实现分布式事务的一致性的及其在分布式系统中的应用,最后附上zk的学习思维导图。
目次
从paxos到zookeeper 分布式一致性
1分布式架构演进
2.一致性协议
二阶段提交
阶段1:投票阶段(prepare阶段)
阶段二:事务提交阶段
三阶段提交
2.2 paxos算法
4. zk的zab协议 和paxos
API使用
Curator
Zk应用场景
大型分布式系统应用
zk技能黑幕
zk的启动流程
zk的数据存储
逻辑布局znode
物理布局数据存储
Zab协议工作原理
规复模式
广播模式
Zk运维
分布式架构演进


  • 大型主机,会合式到寻常主机的分布式
  • 分布式事务

    • 问题

      • 通信异常

        • 三态:乐成,失败,超时

      • 网络分区

        • 脑裂:由于节点间的网络延时不绝增加,会造成只有部门节点能正常通信,形成小集群,造成网络分区,有时网络分区会导致部门节点完成需要所有节点到场的事务

      • 节点故障

    • 从单机事务的acid到cap、base

      • Acid

        • A:只有乐成大概失败
        • C:数据是否正确状态
        • I:幻读:两次事务,同样的读利用出现不一致,导致业务处置惩罚问题

          •   



      • Cap

        • 分布式一致性(和单机事务一致性有区别):副本之间的数据一致性,强一致性和弱一致性
        • 可用性:正常的时间内返回正常的效果
        • 分区容错性:任何分区错误,系统都能包管一致性和可用性,包罗节点退出和参加

      • Base

        • Basic available 根本可用:时间损失,服务降级
        • Soft state:允许存在中间状态的不一致
        • Eventually consistency:最终状态一致     



一致性协议

 
每个节点不知道其他节点的事务提友爱况,所以引入中间者举行协调。
二阶段提交

组织游泳运动需要买票和提交付款

阶段1:投票阶段(prepare阶段)


  • 协调者向事务到场者发起事务询问
  • 到场者在当地执行事务start,并执行事务,但不提交
  • 到场者返回事务start的效果
阶段二:事务提交阶段

协调治点根据到场者的反馈判断是否执行事务的提交,两种情况:
1.如果到场者阶段一都返回ok,则协调治点向到场节点发起commit
2.到场者commit当地事务,并返回ack
如果到场者阶段一返回的都是no,大概后节点超时
协调治点发起rollback请求,到场节点都rollback
优缺点:

  • 简朴实现
  • 会发生阻塞
  • 提交阶段到场节点commit消息丢失
三阶段提交

根本和2pc差不多,准备阶段之前参加了询问阶段,询问到场节点是否可以执行事务,低沉了事务准备节点的阻塞概率,但是没有管理commit丢失的情况。

 
paxos算法

参考:Paxos made simple
paxos是非常结实的分布式一致性协议,也导致他非常的复杂难懂,待增补。
 
zk的zab协议 和paxos

zk的设计目标是分布式协调服务,接纳的是zab协议叫原子广播,比paxos更简朴,设计目标的假设条件也更宽松。
Zk提供分布式一致性服务包罗:

  • 定名服务,域名服务
  • 负载均衡
  • Pubsub
  • 队列
  • 分布式锁
  • 设置管理
  • 服务发现注册
API使用

Curator

提供了许多实用功能的实现:

  • 节点监听
  • 选举master
  • 分布式锁
  • 分布式计数器,元子类
  • 分布式barrier
  • 队列
  • 分布式信号
Zk应用场景

分布式协调:焦点都是基于znode的顺序一致性和通知机制,根本都是分布式锁的逻辑。

  • 设置服务
  • 动态dns
  • Uuid
  • 协调通知
  • 集群管理:实现高可用
大型分布式系统应用


  • Yarn

    • 集群管理:实现主备切换,高可用
    • 防止脑裂:fencing,通过acl判断是否是master,预防master假死后规复的情况

  • Hbase
  • Kafka

    • Broker注册
    • Topic注册
    • 生产和消费负载均衡
    • Offset记载

  • Otter和cannal
  • Jstorm
这里有张zk的知识图谱:

zk技能黑幕

架构图

zk的启动流程


zk的数据存储

逻辑布局znode


  • 节点版本号:和节点的顺序号不是一样的

    •   


  • znode的ACL

    •  权限模式:授权对象:权限

      • 权限模式

        • Ip

          • 指定ip

        • Digest

          • 通过特定字段组合的hash值,如:name+passwd


      • 授权对象id

        •  

      • 权限

        • CDRWA,A:admin


    • 可以自界说权限管理器
    • 使用

      • Create path data acl
      • Setacl path acl


物理布局数据存储


  • 内存数据
  • 事务日志,datalogdir

    • Zxid 末端定名,固定巨细分片
    • 事务日志生存,事务相关数据和利用

  • 数据快照,datadir
Zab协议工作原理

zab的工作原理分两种情况:一种是服务启动大概故障重启规复,一种是写事务提交这种也叫广播模式

  • 规复模式

    • 场景重启、故障、断网
    • 主要作用是选leader

      •  
      • 选票的布局



      • 节点的范例

        • leader:负责吸收事务提交
        • follower:负责投票和复制leader的提交
        • observer:负责同步数据,没投票权

      • 节点的状态

        • looking
        • following
        • observing
        • leading

      • 选举流程

        •  

      •  表明: 1、自增选举轮次。Zookeeper规定所有有效的投票都必须在同一轮次中,在开始新一轮投票时,会首先对logicalclock举行自增利用。
        2、初始化选票。在开始举行新一轮投票之前,每个服务器都会初始化自身的选票,而且在初始化阶段,每台服务器都会将自己推举为Leader。
        3、发送初始化选票。完成选票的初始化后,服务器就会发起第一次投票。Zookeeper会将刚刚初始化好的选票放入sendqueue中,由发送器WorkerSender负责发送出去。
        4、吸收外部投票。每台服务器会不绝地从recvqueue队列中获取外部选票。如果服务器发现无法获取到任何外部投票,那么就会立即确认自己是否和集群中其他服务器保持着有效的毗连,如果没有毗连,则立即创建毗连,如果已经创建了毗连,则再次发送自己当前的内部投票。
        5、判断选举轮次。在发送完初始化选票之后,接着开始处置惩罚外部投票。在处置惩罚外部投票时,会根据选举轮次来举行差别的处置惩罚。


                        外部投票的选举轮次大于内部投票。若服务器自身的选举轮次落伍于该外部投票对应服务器的选举轮次,那么就会立即更新自己的选举轮次(logicalclock),而且清空所有已经收到的投票,然后使用初始化的投票来举行PK以确定是否变动内部投票。最终再将内部投票发送出去。
                       外部投票的选举轮次小于内部投票。若服务器吸收的外选票的选举轮次落伍于自身的选举轮次,那么Zookeeper就会直接忽略该外部投票,不做任那边理,并返回步调4。
                       外部投票的选举轮次便是内部投票。此时可以开始举行选票PK。
                             6、选票PK。在举行选票PK时,符合任意一个条件就需要变动投票。
                                      若外部投票中推举的Leader服务器的选举轮次大于内部投票,那么需要变动投票。
                                     若选举轮次一致,那么就对比两者的ZXID,若外部投票的ZXID大,那么需要变动投票。
                                               若两者的ZXID一致,那么就对比两者的SID,若外部投票的SID大,那么就需要变动投票。
                              7、变动投票。颠末PK后,若确定了外部投票优于内部投票,那么就变动投票,纵然用外部投票的选票信息来覆盖内部投票,变动完成后,再次将这个变动后的内部投票发送出去。
                              8、选票归档。无论是否变动了投票,都会将刚刚收到的那份外部投票放入选票聚集recvset中举行归档。recvset用于记载当前服务器在本轮次的Leader选举中收到的所有外部投票(按照服务队的SID区别,如{(1, vote1), (2, vote2)...})。
                              9、统计投票。完成选票归档后,就可以开始统计投票,统计投票是为了统计集群中是否已经有过半的服务器认可了当前的内部投票,如果确定已经有过半服务器认可了该投票,则终止投票。否则返回步调4。
                              10、更新服务器状态。若已经确定可以终止投票,那么就开始更新服务器状态,服务器首选判断当前被过半服务器认可的投票所对应的Leader服务器是否是自己,若是自己,则将自己的服务器状态更新为LEADING,若不是,则根据详细情况来确定自己是FOLLOWING或是OBSERVING。
                               以上10个步调就是FastLeaderElection的焦点,此中步调4-9会颠末几轮循环,直到有Leader选举产生。参考:https://www.cnblogs.com/veblen/p/10992103.html

  • 广播模式

    • 场景:写请求
    • 写的事务请求都是转发到leader节点举行的
    • 如何包管顺序一致性

      • 每次广播生玉成局唯一的zxid
      • 执行过半二阶段提交

        • Foller有个fifo队列,每次proposal都有将先写事务日志,leader也写事务日志,leader发起commit后提交事务,follower也提交,如果leader收到过半节点的提交确认则认为事务提交乐成。

      • 所有提交有唯一的Zxid,leader会Currenthashmap生存所有待提交的zxid,leader提交前会判断是否有比当前收到的ack对应的zxid小的zxid未提交,如果有则当前的zxid纵然过半了也不能提交。


  • 和paxos的区别

    • Zk是分布式主从协议
    • Pxs是分布式一致性协议:https://zhuanlan.zhihu.com/p/31780743

Zk运维

zk的运维也是很重要的一块,如何举行容灾和高可用还能到达一致性和分区容错性,包罗:

  • Jmx
  • 下令
  • 参数设置
  • 集群,节点数奇数
  • 多机房摆设,每个机房的节点数,防止脑裂
  •       3机房
  •       2机房
  • 集群扩容缩容   

    • 需要重启,一台台重启


来源:https://blog.csdn.net/Houson_c/article/details/111996638
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )