【我的区块链之路】- 说一说Paxos和Raft算法

【转载请标明出处】：https://blog.csdn.net/qq_25870633/article/details/82705703

文章参考自：

https://blog.csdn.net/jerry81333/article/details/74303194

https://www.cnblogs.com/linbingdong/p/6253479.html

https://happyer.github.io/2017/03/15/2017-03-15-paxos/?utm_campaign=studygolang.com&utm_medium=studygolang.com&utm_source=studygolang.com

在说说算法之前我们先来说一说一些分布式系统的核心问题，在分布式中我们非常非常看重的有一般网上经常说的三个点，CAP ！即：C (Consistency 一致性)、A (Availability 可用性)、P (Partition)；也就是我们经常所说的【CAP原理】；而在一致性中我们有非常非常注重四个点， ACID ！ 即：A (Atomicity  原子性)、C (Consistency 一致性)、 I (Isolation 隔离性)、 D (Durability 持久性)，也就是我们常说的【ACID原则】是的一致性原则中的一种。也有和ACID相对存在的【BASE原则】。也有我们经常所说的【FLP 不可能原理】！这些我们在下面都会一一道来。

大家做过后台的基本都知道，在分布式集群中，节点间的网络通信是不可靠的，包括消息延迟、乱序、内容错误等等；节点间的处理时间无法保障，结果可能出现错误，甚至节点自身可能发生宕机；同步调用是可以简化设计(避免上述问题)，但是降低了分布式系统的拓展性、甚至退化为单点系统。

FLP不可能原理：

在网络可靠，但允许节点失效(即使只有一个) 的最小化异步模型系统中，不存在一个可以解决一致性问题的确认性共识算法。(也就是说：不要浪费时间，祛味一步分布式系统设计在任意场景下(特定场景可以？)都能实现的共识算法)

正确理解FLP不可能原理，首先，弄懂“异步”的含义。

同步：指的是系统中各个节点的时钟误差存在上限，消息传递必须在一定时间内完成。否则失败。

异步：指系统中各个节点可能存在较大的时钟差异，同时消息传输的时间是人异常的，各个节点对消息的处理时间也可能任意长。这就造成无法判断某个消息迟迟没有响应到底是消息没到，还是传输失败，还是节点宕机。

FLP不可能原理是一种非常纯粹的异步系统，我们可以认为是一个可能存在拜占庭错误的系统；先撇开这个不说就算是正常的非拜占庭错误的前提下，paxos和raft算法都无法保证完全的共识，只是这种情况出现的概率比较小而已。

那么FLP不可能原理告诉我们研究共识算法压根就没有意义？

非也非也，正所谓，科学只是考虑了物理和数学意义上的最极端情形。所以，科学告诉你什么是不可能的，但是工程商只要付出一些代价，可以把它变得可行。

退一步说，如何付出一些代价？回答这个问题的就是 CAP 原理；

CAP原理：

在CAP原理中，分别说了C 一致性、A可用性、P分区容错性，在分布式系统中很难做到三者兼顾，一般我们只能做到其中两者完善。

C 一致性： 任何操作都是原子性的，后面的时间发生都能看到前面时间的结果，又或者说，任一节点上所看到的事件都应该是一样。

A 可用性：在有限的时间内，任何非宕机节点都能应答

P 分区容错性：网络可能会发生分区，即节点间的通信无法保障是，整个网络还是可以容忍这部分分区存在的

所以：在网络分区表的时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有收到其他节点的确认而不作应答【牺牲可用性】；要么，节点只能应答非一致性的结果【牺牲一致性】

【注】：网络分区是可能存在的，出现分区情况后可能及导致发生“脑裂”，多个新的主节点企图关闭其他主节点。

由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡。

CA 传统Oracle数据库

AP 大多数网站架构的选择

CP Redis、Mongodb

应用场景：

1. 【弱一致性】：即： AP，通常可能对一致性要求低一些；允许在新版本上线后过一段时间才最终更新成功，期间不保证一致性。如：实时性较弱的查询，如：gossip、CouchDB、Cassandra等等
2. 【弱可用性】：即：CP，满足一致性，分区容忍必的系统，通常性能不是特别高，所以不是那么可用；因为出自对一致性敏感，如：银行取款机，需要当系统故障时会拒绝服务。M哦能够DB、Redis、MapReduce等，Paxos和Raft算法主要处理这种情况。但在Paxos类算法中，可能存在着无法提供可用结果的情形（概率十分的小），同时允许少数节点离线。
3. 【弱分区容错性】：即：CA，满足可用性，分区容忍性的系统，通常可能对一致性要求低一些；现实中，网络分区出现的概率较小，但较难完全避免。两个阶段的提交算法，某些关系型数据库及ZK就是这个么设计的。

BASE原则：

BASE是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）的简写。其存在是和强调一致性的ACID处于对立的，其是对CAP中一致性和可用性权衡的结果，契合性思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使得系统达到最终一致性。

1、【基本可用性】：指分布式系统在出现不可预知的故障的时候，允许损失部分可用性。

2、【软状态】：指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同的节点之间的数据副本进行数据的同步过程存在延迟。

3、【最终一致性】：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

ACID原则：

其主要强调的是一致性。允许付出可用性的代价。

1、【原子性】：每次操作都是原子性的，要么整体成功，要么整体失败。

2、【一致性】：所有的状态都必须是一致的，不存在中间状态，即，在各个节点的状态必须是同时一致的。

3、【隔离性】：表示各个操作间必须是互不影响的。

4、【持久性】：表示状态的改变是持久的，不会被失效。

好了，总之分布式系统中的一些问题和一些设计原则我们就先了解到这里了，下面我们来吹一吹paxos和raft算法的牛逼。

Paxos：

在paxos算法中，首先具备了3中角色，Proposer （提案者）、Acceptor （接受者）、Learner （学习者）

该算法需要满足 Safety （安全） 和 Livense （活跃度）两方面的约束要求。

Safety 约束：保证 决议结果是对的；只有是Proposers 提出的天才可能被最终批准；在一次执行中，只批准一个最终决议，即被绝大多数 接受 的结果成为决议。

Liveness 约束： 保证决议过程能在有限时间内完成；决议最终总会产生，且Learner 能获得被批准的决议。

一句话说原理：多个提案者竞争的看看谁先取到提案的权利【得到绝大多数接受者的支持】，得到提案权的提案者发送提案给所有人进行确认，得到绝大多数人确认的提案成为决议。

Paxos并不保证系统随时处于一致的状态，单只要每次打成过程中至少超过一半的节点参与，这样最终整个系统都会获知共识的结果。Paxos能保证超过一半的节点正常工作时，系统总能以较大概率达成共识。

三种角色：

1. Proposer：提出提案等待大家认可该提案为决议。(系统中的提案都拥有一个自增的唯一提案号，<往往由客户端担任该角色>)。
2. Acceptor：负责对提案进行投票，认可提案。<往往由服务器担任该角色>
3. Learner：获取批准的结果 （学习acceptor所认可的结果），并帮忙传播，不参与投票过程。<客户端和服务器担任>

Paxos的流程：分为两个阶段，准备阶段、提交阶段。

准备阶段：

• proposer向网络内超过半数的acceptor发送prepare消息 (即：提交自己的提案编号)
• acceptor正常情况下回复promise消息（接受者时可保存收到过的提案的最大编号和认可的最大提案，如果收到的提案号比自己保留的最大提案号还大，则返回自己已认可的提案号；如果从未认可过提案，则返回空，并更新当前保存的最大提案号，并说明不再认可小于最大提案号的提案）

提交阶段：

• 在有足够多acceptor回复promise消息时，proposer发送accept消息（如果提案者收到大多数的回复，则发送带有刚才提案号的接受 accept 信息。<注意：如果收到的回复中不带有提案号，说明 提案锁定成功，则使用自己当前的提案内容；如果收到的回复中有提案内容，则替换当前提案值为返回的编号最大的提案值；如果没有收到足够的 回复，则会再次发送请求。<即 第一阶段的动作>）
• 正常情况下acceptor回复accepted消息 （接受者收到 提案者发来的 接受 accept 信息，如果发现 提案号 不小于 自己保存的当前已接收的最大提案号，则更新 认可的最大提案，并更新认可提案内容）

一旦多数接受者认可了共同提案值，则形成决议，成为最终确认。

如下所示：描述多Proposer的情况，T代表时间轴：

上图中，假设 A1和A5都是Proposer， A3位Accepter；A3在T1发出accepted给A1，然后在T2收到A5的prepare；而在T3的时候A1才通知A5最终结果(A1的提案结果 == 税率10%)。这里会有两种情况：

【1】A5发来的N5小于A1发出去的N1，那么A3直接拒绝(reject)A5
【2】A5发来的N5大于A1发出去的N1，那么A3回复promise，但带上A1的(N1, 10%) <因为之前A3已经认可A1的提案了>

最终A5也会接受10%<A1的提案>

再如：

上图描述，如果已经Promise一个更大的N，那么会直接Reject更小的k；如：A3已经发出给A5的Promise里头带的提案编号为N，如果这时A1发来的prepare里头的提案号 k < N 那么会被A3直接拒绝。

再如：

上述描述了，即使Promise了一个N，如果在未Accepted前，再收到一个更大的K，那么依旧会Reject那个即使已经Promise的N。即：A3之前给A1发出了Promise里头带有提案号为N，这时A5发来的prepare里头带有的提案号为K， K > N,这是A3会更新本地保存的N。<也就是拒绝了A1，因为A3对A1的accepted 还没发出去啊>

据说在微信的PaxosStore中 (及PhxPaxos)，每分钟调用Paxos协议过程数十亿次量级。

代码实现：

https://blog.csdn.net/lizhe_dashuju/article/details/80054693

Raft算法：

raft是paxos的改进版，在raft中首先具备了三种角色：Leader (领导者)、Candidate （候选者）、Follower （追随者）；

通常再做决策之前需要选举出一个全局的Leader来简化后续的决策过程。Leader决定了log的提交，且 log只能是Leader 想follower单向提交。<此处的log指的是各种事件发生记录>

Leader (领导者)：负责接收客户端的Log，并分发给其他节点。

Candidate （候选者）：发起选举请求，竞争Leader。

Follower （追随者）：负责接收Leader发送过来的Log，并刷新保存。

 

Raft 分为两个过程：选举Leader、日志同步。

选举Leader：

刚开始的时候所有节点都是Follower，在随机超时发生之后，未收到来自Leader或者 Candidate的消息是，则转变成Candidate，并发出选举请求。在最近时间片内的票超过一般者被选为Leader；如果还未选出Leader，则随机超时后进入下一轮从新选举；Follower自增当前任期，转换为Candidate，对自己投票，并发起 RequestVote RPC，等待下面三种情形发生：

1. 获得超过半数服务器的投票，赢得选举，成为Leader
2. 另一台服务器赢得选举，并接收到对应的心跳，成为Follower
3. 选举超时，没有任何一台服务器赢得选举，自增当前任期，重新发起选举

同步日志：

Leader接受客户端请求，Leader更新日志，并向所有Follower发送 Heatbeats （心跳），同步日志。所有Follwer都有，如果在ElectionTimeout时间之内，没有收到Leader的Headbeats，则认为Leader失效，重新选举Leader。Leader会找到系统中最新的日志记录。并强制所有Follower 刷新这个记录，<数据的同步是单向的>

安全性保证

1. 日志的流向只有Leader到Follower，并且Leader不能覆盖日志

2. 日志不是最新者不能成为Candidate

代码实现：https://blog.csdn.net/xiongwenwu/article/details/79981804

OK，逼逼了这么久，以上就是分布式系统及Paxos和Raft算法的解释。。。。