Paxos算法简介
概述
一种基于消息传递且具有高度容错特性的 强一致性算法
注:强一致性,即数据要求时刻保持一致
解决的问题
如何快速正确的在一个分布式系统中对某个数据值达成一致,并且保证不论发生任何异常,都不会破坏整个系统的一致性。
分类
- Basic Paxos:最原始的Paxos算法;
- Multi Paxos:在Basic Paxos基础上提出的优化方案;
- Fast Paxos:为了提高收敛速度,在Multi Paxos基础上进一步优化的方案;
算法核心思想
- 仅讨论并接受最新的“提案”;
- 少数服从多数;
Basic Paxos算法
角色分类:
- Client:系统外部角色,请求的发起者;
- Proposer:接受Client请求,向集群提出提议(proposal)。并在冲突发生时,起到冲突调节的作用;(注:Basic Paxos中Propser不唯一)
- Acceptor(Voter):提议投票和接收者,只有在形成法定人数(Quorum,一般为majority多数派)时,提议才会最终被接受;
- Learner:提议接受者,不参与投票,仅充当backup(备份)的作用,对集群一致性没什么影响
注:集群中每个节点都可能充当多个角色
算法流程
注:提案Proposal包含编号N、以及内容Value
1a. Prepare:proposer提出一个提案,编号为N,此N大于这个proposer之前提出提案编号。请求acceptors的Quorum(多数派)接受;
1b. Promise:如果N大于此acceptor之前接受的任何提案编号则接受;否则拒绝;
2a. Accept:如果达到了多数派,proposer会广播accept请求,此请求包含提案编号N,以及提案内容;
2b. Accepted:如果此Acceptor在此期间没有收到任何编号大于N的提案,则接受此提案内容,并备份提案的value;否则忽略;
如图所示:
- Si(i=1,2,…,5)为提案发起者(Proposer);
- P(N)为发起的提案(N代表发起提案的编号);
- A(N)为广播的accept请求;
- 首先,由S1发起编号为P3.1的提案,得到S2、S3的投票(超过集群中半数以上的选票),提案进入Accept阶段。然而在Accepted之前,有来自S5发起的更新的提案P3.5,所以3.1提案被终止。
- 在P3.5提案进入Accepted阶段前,有来自S1发起的编号更新的提案P4.1。所以,3.5提案被终止。
- 后续进程同理,自始至终:只讨论、且接受提案编号大的提案。即提案想要被接受,需要在整个算法流程中没有编号更新的提案被提出。
Basic算法优化方式
- Multi Paxos:在集群所有Proposer中选取唯一的Leader进行“提案”的提交以及具体内容的传递,避免活锁的发生,同时简化流程
注:活锁,即每个Proposer都想自己的提案通过,因此在提案被否决后,proposer通过增大编号重复提交、抢占提案通道(如上图所示)
- Fast Paxos:在Multi Paxos的基础上,当提案被讨论通过后,由提案的发起者直接向集群中其他节点传递提案具体值value,而不需要经过Leader的转发,提高数据达成一致的速率
由提案的发起者直接向集群中其他节点传递提案具体值value,而不需要经过Leader的转发,提高数据达成一致的速率