常见共识算法
1.PBFT(拜占庭容错)
- 基于拜占庭将军问题,一致性的确保主要分为这三个阶段:预准备(pre-prepare)、准备(prepare)和确认(commit)。流程如下图所示:
其中C为发送请求端,0123为服务端,3为宕机的服务端,具体步骤如下:
- Request:请求端C发送请求到任意一节点,这里是0
- Pre-Prepare:服务端0收到C的请求后进行广播,扩散至123
- Prepare:123,收到后记录并再次广播,1->023,2->013,3因为宕机无法广播
- Commit:0123节点在Prepare阶段,若收到超过一定数量的相同请求,则进入Commit阶段,广播Commit请求
- 5.Reply:0123节点在Commit阶段,若收到超过一定数量的相同请求,则对C进行反馈
根据上述流程,在 N ≥ 3F + 1 的情況下一致性是可能解決,N为总计算机数,F为有问题的计算机总数
N=4 F=0 时:
得到数据 | 最终数据 | |
---|---|---|
A | 1 1 1 1 | 1 |
B | 1 1 1 1 | 1 |
C | 1 1 1 1 | 1 |
D | 1 1 1 1 | 1 |
N=4 F=1 时:
得到数据 | 最终数据 | |
---|---|---|
A | 1 1 1 0 | 1 |
B | 1 1 0 1 | 1 |
C | 1 0 1 1 | 1 |
D | 0 1 1 1 | 1 |
#####N=4 F=2 时:
得到数据 | 最终数据 | |
---|---|---|
A | 1 1 0 0 | NA |
B | 1 0 0 1 | NA |
C | 0 0 1 1 | NA |
D | 0 1 1 0 | NA |
由此可以看出,拜占庭容错能够容纳将近1/3的错误节点误差,IBM创建的Hyperledger就是使用了该算法作为共识算法。
2.PAXOS
PAXOS是一种基于消息传递且具有高度容错特性的一致性算法。
1.算法本身用语言描述极其精简:
2.三个角色
- Proposer:提议发起者。Proposer 可以有多个,Proposer 提出议案(value)。所谓 value,可以是任何操作,比如“设置某个变量的值为value”。不同的 Proposer 可以提出不同的 value,例如某个Proposer 提议“将变量 X 设置为 1”,另一个 Proposer 提议“将变量 X 设置为 2”,但对同一轮 Paxos过程,最多只有一个 value 被批准。
- Acceptor:提议接受者;Acceptor 有 N 个,Proposer 提出的 value 必须获得超过半数(N/2+1)的 Acceptor批准后才能通过。Acceptor 之间完全对等独立。
- Learner:提议学习者。上面提到只要超过半数accpetor通过即可获得通过,那么learner角色的目的就是把通过的确定性取值同步给其他未确定的Acceptor。
3.协议过程
- proposer将发起提案(value)给所有accpetor,超过半数accpetor获得批准后,proposer将提案写入accpetor内,最终所有accpetor获得一致性的确定性取值,且后续不允许再修改。
4.步骤
#####phase 1
- proposer向网络内超过半数的acceptor发送prepare消息
- acceptor正常情况下回复promise消息
phase 2
- 在有足够多acceptor回复promise消息时,proposer发送accept消息
- 正常情况下acceptor回复accepted消息
其中1,2,3,4代表顺序。
以下图描述多Proposer的情况,T代表时间轴,图中仅画全一个Proposer与Acceptor的关系:
A3在T1发出accepted给A1,然后在T2收到A5的prepare,在T3的时候A1才通知A5最终结果(税率10%)。这里会有两种情况:
- A5发来的N5小于A1发出去的N1,那么A3直接拒绝(reject)A5
- A5发来的N5大于A1发出去的N1,那么A3回复promise,但带上A1的(N1, 10%)
最终A5也会接受10%
上图描述,如果已经Promise一个更大的N,那么会直接Reject更小的N
上述描述了,即使Promise了一个N,如果在未Accepted前,再收到一个更大的N,那么依旧会Reject那个即使已经Promise的N 。
PAXOS的应用:
- PAXOS协议用于微信PaxosStore中,每分钟调用Paxos协议过程数十亿次量级。
3.RAFT
1.概括
- RAFT核心思想很容易理解,如果数个数据库,初始状态一致,只要之后的进行的操作一致,就能保证之后的数据一致。由此RAFT使用的是Log进行同步,并且将服务器分为三中角色:Leader,Follower,Candidate,相互可以互相转换。
- RAFT从大的角度看,分为两个过程:
- 选举Leader
- Leader生成Log,并与Follower进行Headbeats同步
2.选举Leader
- Follower自增当前任期,转换为Candidate,对自己投票,并发起RequestVote RPC,等待下面三种情形发生:
- 获得超过半数服务器的投票,赢得选举,成为Leader
- 另一台服务器赢得选举,并接收到对应的心跳,成为Follower
- 选举超时,没有任何一台服务器赢得选举,自增当前任期,重新发起选举
3.日志同步
- Leader接受客户端请求,Leader更新日志,并向所有Follower发送Heatbeats,同步日志。所有Follwer都有ElectionTimeout,如果在ElectionTimeout时间之内,没有收到Leader的Headbeats,则认为Leader失效,重新选举Leader
- 流程图示:
4.安全性保证
-
日志的流向只有Leader到Follower,并且Leader不能覆盖日志
-
日志不是最新者不能成为Candidate