当前位置:   article > 正文

分布式共识算法paxos,Raft,ZAB原理_共识算法 zab

共识算法 zab

前言

对于分布式中,多个节点的数据强一致性问题,通常采用如下策略或算法为解决方案。

  • 主从同步
  • paxos
    • basic paxos
    • multi paxos
    • fast paxos
  • Raft
  • ZAB

一、paxos

basic paxos

paxos 首先假设通信是安全的

证明

角色
  • Proposer 提议发起者,处理客户端请求,将客户端的请求发送到集群中,以便决定这个值是否可以被批准。
  • Acceptor 提议批准者,负责处理接收到的提议,他们的回复就是一次投票。会存储一些状态来决定是否接收一个值
  • learner 记录者,负责记录提案。
过程
client Proposer Acceptor1 Acceptor2 Acceptor3 Learneras request(value) 客户端发起一个提案为value的请求 为提案value生成一个编号n 提出编号为n的提案 提出编号为n的提案 提出编号为n的提案 n>当前Acceptor记录的最大编号 接受这个提案 n>当前Acceptor记录的最大编号 接受这个提案 n>当前Acceptor记录的最大编号 接受这个提案 alt [第一阶段:prepare] 同意提案的响应过半数 则继续第二阶段 否则响应client为错误 提交提案内容acceprt(n,value) 提交提案内容acceprt(n,value) 提交提案内容acceprt(n,value) n>=当前Acceptor记录的最大编号 接受这个提案 提交(n,value)到learner记录 n>=当前Acceptor记录的最大编号 接受这个提案 提交(n,value)到learner记录 n>=当前Acceptor记录的最大编号 接受这个提案 提交(n,value)到learner记录 accpet数量过半,则value达成共识 响应client的请求 alt [第二阶段:accept] client Proposer Acceptor1 Acceptor2 Acceptor3 Learneras

缺陷
  • 效率低下
  • 难以实现
  • paxos存在活锁问题,多个proposer提出提案,且n不断增长,则任何一个提案都无法被达成。
  • 如果learner不止一个,则learner间数据同步依然是个问题

Multi-paxos

multi paxos 是paxos算法的优化,升级版。以便该算法能够被应用在现实中。
lamport 对multi-paxos 的具体实现其实是并没有细节的指定的, 只是简单提了一下. 所以有各种不同的multi-paxos 的实现

和paxos的区别

multi-paxos对角色进行了新的抽象

  • Leader/master:唯一的proposer ,
    • multi-paxos规定只能有一个提案提出者,所有请求都需要经过leader。
    • 这个策略保证了提案的有序,所以简化掉了paxos的prepare阶段。
  • node: 去掉了各种角色,统一为节点,更接近计算机实现
    • 通过一定的策略竞选出某个节点为第n任主节点,则其它节点为从节点
    • 从节点负责接收主节点的数据,也就是提案,可以理解为数据库的主从同步。
过程
  1. 发起者(leader)直接告诉其他节点,准备递交协议号为I+1的协议
  2. 收到了大部分从节点的回复后,主节点就直接回复client成功写入

二、Raft

因为paxos难以理解,难以实现,所以raft应运而生。
可以说raft是multi-paxos的优化升级版,更易理解,且补充了实现方案。
paxos 是对于一个问题达成一致的协议
而raft 本身是对一堆连续的问题达成一致的协议
raft是etcd的采用的共识算法

动画演示 http://thesecretlivesofdata.com/raft/
官网:https://raft.github.io/

Raft和multi-paxos的区别

raft 是基于对multi paxos 的两个限制形成的

  • 发送的请求的是连续的, 也就是说raft 的append 操作必须是连续的. 而paxos 可以并发的. (其实这里并发只是append log 的并发提高, 应用的state machine 还是必须是有序的)
  • 选主是有限制的, 必须有最新, 最全的日志节点才可以当选. 而multi-paxos 是随意的 所以raft 可以看成是简化版本的multi paxos(这里multi-paxos 因为允许并发的写log, 因此不存在一个最新, 最全的日志节点, 因此只能这么做. 这样带来的麻烦就是选主以后, 需要将主里面没有的log 给补全, 并执行commit 过程)
问题定义

raft将共识问题划分成三个子问题,实现了这三个子问题,则实现了共识问题。

  • 选主
  • log同步
  • safety 在所有的操作中,集群共识一直是一致。
角色定义
  • leader 接受客户端请求,并向Follower同步请求日志,当日志同步到大多数节点上后告诉Follower提交日志。
  • follower 接受并持久化Leader同步的日志,在Leader告之日志可以提交之后,提交日志。
  • candidate follower在精选leader时,会先变成candidate
选举过程
  1. 一个follower节点总是在等待超时,在超时前接收到leader的心跳,则重置超时。如果超时,则变为candidate节点开始竞选,任期(term)+1,Vote count为1(自己投了自己)。并向其他节点发送竞选通知。
  2. 如果得到选票响应超过半数,则该节点变为leader节点。并周期向其他节点发送心跳。
  3. 如果得到选票响应不超过半数,则等待随机时间。如果期间内没有给其他节点投票,则发起第二轮选举。
日志同步过程
client leader node1 node2 客户端向leader发送请求 内容为set 1 记录log:set 1 同步log:set 1 同步log:set 1 响应 响应 如果响应数大于半数 确认log:set 1 success 确认log:set 1 确认log:set 1 client leader node1 node2
网络故障处理

1.网络分区
则每个分区都会产生一个leader,但只有节点较多的分区能够保存数据成功。
在分区恢复后,任期较低的leader节点变为follower,并从leader节点同步日志。


ZAB

zab 与raft基本相同,也是multi-paxos的一种实现
是zookeeper的实现算法

与raft区别
  • zab中一个leader周期叫做epoch raft中叫做term
  • zab心跳包由从节点发往主节点,raft是主节点发往从节点
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/不正经/article/detail/296458
推荐阅读
相关标签
  

闽ICP备14008679号