分布式一致性算法，你肯定不了解一下

集中式与分布式

集中式

就是将全部的业务都部署在一个中心主机（节点）上，全部的功能都由这个主机集中处理。算法

特色数据库

部署结构简单、不须要考虑多个主机之间的分布式协做问题。服务器

分布式

分布式系统：指将硬件或者软件组件部署在不一样的网络计算机上，彼此之间仅仅经过消息传递进行通讯和协调的系统。markdown

特色网络

分布性：多台计算机可空间上随意分布，跨机房、跨城市均可以。
对等性：分布式系统中没有主/从之分，都是对等的节点或者服务。
- 副本：指分布式系统对数据或服务冗余，以此提供高可用。
- 数据副本：是指在不一样的节点上持久化一份数据，当某一个节点上存储的数据丢失时，能够从副本上读取到该数据，这是分布式系统数据丢失问题最为有效的手段。
- 服务副本：指多个节点提供一样的服务，每一个节点都有能力接收来自外部的请求并进行相应的处理。
**并发性：**分布式系统中的多个节点，可能会并发地操做一些共享资源，诸如数据库或分布式存储等。
**缺少全局时钟：**一个典型的分布式系统是由一系列在空间上随意分布的进程组成，进程彼此之间经过消息进行通讯。所以，没法判断两个事件谁先谁后。可以使用逻辑时钟。
**故障老是会发生：**除非需求指标容许，在系统设计时不能放过任何异常状况。如宕机、网络分区、网络超时等。

每一次分布式系统的请求与响应三态：成功，失败，超时。架构

超时状况：并发

没有成功发送到接收方，在发送过程当中发生信息丢失。
成功发送到接收方，并成功处理，但返回给发送方过程当中发生信息丢失。

因此须要有幂等。分布式

分布式事务

分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的**不一样节点之上。**一般一个分布式事务中会涉及对多个数据源或业务系统的操做。分布式事务也能够被定义为一种嵌套型的事务，同时也就具备了ACID事务的特性。oop

CAP理论

Consistency(一致性)：数据一致更新，全部数据变更都是同步的（强一致性）。性能
Availability(可用性)：好的响应性能
Partition tolerance(分区容错性) ：可靠性

分区容错性：分布式系统在遇到任何网络分区故障的时候，任然须要保证对外提供知足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区：是指在分布式系统中，不一样的节点分布在不一样的子网络（机房或异地网络等）中，因为一些特殊的缘由致使这些子网络之间出现网络不连通的情况，但各个子网络的内部网络是正常的，从而致使整个网络的环境被切成了若干个孤立的区域。

定理：任何分布式系统只可同时知足二点，无法三者兼顾。

须要根据实际业务进行取舍。

CA系统（放弃P）：指将全部数据（或者仅仅是那些与事务相关的数据）都放在一个分布式节点上，就不会存在网络分区。因此强一致性以及可用性获得知足。
CP系统（放弃A）：若是要求数据在各个服务器上是强一致的，然而网络分区会致使同步时间无限延长，那么如此一来可用性就得不到保障了。坚持事务ACID（原子性、一致性、隔离性和持久性）的传统数据库以及对结果一致性很是敏感的应用一般会作出这样的选择。
AP系统（放弃C）：这里所说的放弃一致性，并非彻底放弃数据一致性，而**是放弃数据的强一致性，而保留数据的最终一致性。**若是即要求系统高可用又要求分区容错，那么就要放弃一致性了。由于一旦发生网络分区，节点之间将没法通讯，为何知足高可用，每一个节点只能用本地数据提供服务，这样就会致使数据不一致。一些遵照BASE原则数据库，（如：Cassandra、CouchDB等）每每会放宽对一致性的要求（知足最终一致性便可），一次来获取基本的可用性。

BASE理论

Basically Available基本可用：指分布式系统在出现不可预知的故障的时候，容许损失部分可用性——但不是系统不可用。
- 响应时间上的损失：假如正常一个在线搜索0.5秒以内返回，但因为故障（机房断电或网络不通），查询结果的响应时间增长到1—2秒。
- 功能上的损失：若是流量激增或者一个请求须要多个服务间配合，而此时有的服务发生了故障，这时须要进行服务降级，进而保护系统稳定性。
Soft state软状态：容许系统在不一样节点的数据副本之间进行数据同步的过程存在延迟。
Eventually consistent最终一致：最终数据是一致的就能够了，而不是时时高一致。

BASE思想主要强调基本的可用性，若是你须要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲。

一致性协议

一致性协议：为了使基于分布式系统架构下的全部节点进行事务处理过程当中可以保持原子性和一致性而设计的一种算法。一般有二阶段提交协议、三阶段提交协议、Paxos、Zookeeper的ZAB协议、Raft、Pbft等。

2PC、3PC引入了两个概念。

**协调者：**负责统一调度分布式节点的执行逻辑

参与者：被调度的分布式节点

2PC：Two-Phase Commit二阶段提交协议

二阶段主要采起：先尝试，后提交。

2PC优缺点

二阶段优势：原理简单，实现方便；解决分布式事务的原子性，要么所有执行成功，要么所有执行失败
二阶段缺点：
1. 同步阻塞：在提交执行过程当中，各个参与者都在等待其余参与者响应的过程当中，将没法执行其余操做。
2. 单点问题：只有一个协调者，协调者挂掉，整个二阶段提交流程没法执行；更为严重是，在阶段二时，协调者出现问题，那参与者将会一直处于锁定事务状态中，没法继续完成事务操做。
3. 数据不一致：在阶段二，协调者发送了Commit请求后，发生了网络故障，致使只有部分参与者收到commit请求，并执行提交操做，就致使数据不一致问题。
4. 太过保守：阶段一中，若参与者出现故障，协调者没法收到参与者的询问反馈，只能经过自身超时机制来中断事务。这样的策略显得过于保守。

3PC:Three-phase Commit 三阶段提交协议

由于2PC有不少问题，因此在2PC基础上，改进为3PC：canCommit、preCommit、doCommit三个阶段。

改进点：

3PC是将2PC的第一阶段分为两个阶段，先发起事务询问，再执行事务。
同时在协调者、参与者中引入超时机制。

3PC优缺点

三阶段优势：
- 下降了二阶段的同步阻塞范围（在第二阶段，只要参与者收到preCommit请求，就会执行事务，此后，无论能不能收到协调者的doCommit请求,都会执行事务提交，不会出现阻塞问题）
- 解决单点问题：进入阶段三会出现两种状况： 1：协调者出现问题； 2：协调者与参与者之间出现网络故障；
  - 都致使参与者没法收到doCommit请求，但参与者在超时以后都会提交事务
三阶段缺点：
- 数据不一致：参与者收到preCommit请求，此时若是出现网络分区，协调者与参与者之间没法进行正常网络通讯，参与者在超时以后仍是会进行事务提交，就会出现数据不一致。

因此2PC、3PC各有优缺点，可根据实际业务场景进行选择。既然2PC、3PC都会产生数据不一致。下面咱们来看一看分布式领域经常使用的一致性算法。

Paxos算法

Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的基于消息传递且具备高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。 Paxos算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。

Paxos以及下面的RAFT都假设不存在拜占庭将军问题，只考虑节点宕机、网络分区、消息不可靠等问题。属于CFT（Crash Fault Tolerance）算法。

系统中有三种角色proposers，acceptors，和 learners。能够一个节点多个角色。

proposers 提出提案，提案信息包括提案编号和提议的 value；
acceptor 收到提案后能够接受（accept）提案，若提案得到多数派（majority）的 acceptors 的接受，则称该提案被批准（chosen）；
learners 只能“学习”被批准的提案。

多数派：指 n / 2 +1 。n为总节点数量。

Paxos算法分为两个阶段。具体以下：

阶段一：
- Proposer选择一个提案编号N，而后向半数以上的Acceptor发送编号为N的Prepare请求。
- 若是一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的全部Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（若是有的话）做为响应反馈给Proposer，同时该Acceptor承诺再也不接受任何编号小于N的提案。
  
  例如：一个acceptor已经响应过的全部prepare请求对应的提案编号分别为一、二、。。。。5和7，那么该acceptor在接收到一个编号为8的prepare请求后，就会将编号为7的提案做为响应反馈给Proposer。
阶段二
- 若是Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对**[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是阶段一收到的响应中编号最大的提案的value**，若是响应中不包含任何提案，那么V就由Proposer本身决定（任意值）。
- 若是Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求作出过响应，它就接受该提案。

注意：Proposer能够随时丢弃提案，而且提出新的提案；Acceptor也能够随时响应，接受编号更大的提案。

思考：若是两个Proposer还处于第一阶段时，互相提出编号更大的提案？会发生什么？

这时候会出现“活锁”状态，陷入了无限死循环中（破坏了算法活性）。

那须要怎么防止呢？

能够选出一个主Proposer，只有主Proposer能够提出提案。

至于怎么选择，不属于Paxos的范畴，能够参考RAFT使用竞选，谁快谁当选；也能够参考PBFT的依次成为leader等。

RAFT算法

RAFT算法分为两个阶段：Leader选举，日志复制。也有三种角色，分别为：

Leader（领导者）：负责发送要进行共识的数据，若是客户端发送的数据不是发送到Leader而是其余角色，其余角色会进行转发至Leader。
Follower（追随者）：参与共识的角色
Candidate（候选者）：若是Follower没有收到Leader的心跳响应超过150——300ms，会进行Leader选举。

每一个节点的身份均可以是以上三种中的其一。

Leader选举阶段：
- 全部节点初始状态为Follower状态，此时没有Leader，确定会与Leader的心跳超时（通常150——300ms，随机的，这样就是想谁先发出竞选，谁当选leader），此时Candidate就会发出leader竞选给其余节点（你们快选我啊，leader挂掉了）；其余节点收到竞选请求，会响应赞成，当一个Candidate收到大多数（n/2 + 1）节点的回复，就成为leader。而后与Candidate保持心跳链接。Raft有个Term（任期）的概念，只有在发生Leader选举阶段，term+1，表示新的leader产生，挂掉的节点，或者挂掉的leader重启后，会发现本身的term小于最新的，此时就会切换到日志复制，去同步以前丢失的消息。
- 若是同时有多个Candidate发出竞选，而且都没有得到大多数投票，会一直进行竞选，直到选出leader
日志复制（是一个2PC提交）
- leader收到客户端或者其余节点转发过来须要共识的值，会跟随心跳一块儿广播给其余节点，进行写入
- 其余节点写入后响应成功给leader，当leader收到大多数的follower响应的成功，发出commit命令
- 其余节点收到commit后，进行事务提交，响应成功为leader，leader收到大多数的commit成功，Raft完成。
若是leader没有挂掉，或者发生网络分区，就会一直是这个leader进行事务发起。

我这里只是对于算法正常流程的描述，强烈推荐动画版RAFT（看不懂算我输，不过记得回来点个赞，哈哈哈）

总结

本文从集中式到分布式理论CAP、BASE以及2PC、3PC流程，描述了分布式事务经常使用的思想；再详细说明了Paxos以及Raft算法流程等。Paxos以及Raft算法属于CFT算法范畴，都能容忍最多n/2（向下取整）的节点出现宕机、网络分区等的强一致性算法。Paxos属于比较晦涩的算法，工程实现比较复杂，但其思想颇有借鉴意义。有兴趣的能够去看看Paxos的推导过程，我的认为颇有意思，可以想明白每一步，对于理解其余算法，也大有帮助；也能够去看看Zookeerper的ZAB算法，后面有机会专门写一篇。但这些算法不能真正意义上用于区块链共识，毕竟leader说什么，其余节点就会执行，没有节点之间的共识过程。那什么算法能够用于区块链共识呢？

参考书籍：

《从Paxos到Zookeeper++分布式一致性原理与实践++》

参考连接：

PAXOS算法

RAFT动画版

本文使用 mdnice 排版