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

 

 

集中式与分布式

集中式

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

特点

部署结构简单、不需要考虑多个主机之间的分布式协作问题。

分布式

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

特点

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

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

超时情况：

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

所以需要有幂等。

分布式事务

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

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三个阶段。

改进点：

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

3PC-第一阶段 3PC-事务中断1 3PC-第三阶段 3PC-事务中断2

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。可以一个节点多个角色。

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

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

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

• 阶段一：

  • Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。

  • 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。

    例如：一个acceptor已经响应过的所有prepare请求对应的提案编号分别为1、2、。。。。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选举，日志复制。也有三种角色，分别为：

1. Leader（领导者）：负责发送要进行共识的数据，如果客户端发送的数据不是发送到Leader而是其他角色，其他角色会进行转发至Leader。
2. Follower（追随者）：参与共识的角色
3. 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 排版

• 还没有人评论，欢迎说说您的想法！