分布式一致性算法的目的是为了解决分布式系统

一致性算法可以通过共享内存(需要锁)或者消息传递实现,本文讨论后者实现的一致性算法,不仅仅是分布式系统中,凡是多个过程需要达成某种一致的场合都可以使用。

本文讨论无论2PC、3PC和Paxos,均无法彻底解决分布式一致性问题。解决一致性问题,唯有Paxos。

Paxos算法是保证在分布式系统中写操作能够顺利进行,保证系统中大多数状态是一致的,没有机会看到不一致,因此,Paxos算法的特点是一致性>可用性。

vector clock向量时钟是另外一种保证复制的算法,其特点是可用性>一致性,但是,一旦发生冲突,不像Paxos能自行解决,需要人工干预编写代码解决。

Paxos算法和Vector Clock都是由Leslie Lamport提出。

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

2PC,二阶段提交协议,即将事务的提交过程分为两个阶段来进行处理:准备阶段和提交阶段。事务的发起者称协调者,事务的执行者称参与者。

阶段1:准备阶段
  1、协调者向所有参与者发送事务内容,询问是否可以提交事务,并等待所有参与者答复。
  2、各参与者执行事务操作,将Undo和Redo信息记入事务日志中(但不提交事务)。
  3、如参与者执行成功,给协调者反馈YES,即可以提交;如执行失败,给协调者反馈NO,即不可提交。

阶段2:提交阶段
  此阶段分两种情况:所有参与者均反馈YES、或任何一个参与者反馈NO。
  所有参与者均反馈YES时,即提交事务。
  任何一个参与者反馈NO时,即中断事务。

提交事务:(所有参与者均反馈YES)
  1、协调者向所有参与者发出正式提交事务的请求(即Commit请求)。
  2、参与者执行Commit请求,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务提交

附如下示意图:

中断事务:(任何一个参与者反馈NO)
  1、协调者向所有参与者发出回滚请求(即Rollback请求)。
  2、参与者使用阶段1中的Undo信息执行回滚操作,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务中断。

附如下示意图:

2PC的缺陷

  1、同步阻塞:最大的问题即同步阻塞,即:所有参与事务的逻辑均处于阻塞状态。
  2、单点:协调者存在单点问题,如果协调者出现故障,参与者将一直处于锁定状态。
  3、脑裂:在阶段2中,如果只有部分参与者接收并执行了Commit请求,会导致节点数据不一致。
  由于2PC存在如上同步阻塞、单点、脑裂问题,因此又出现了2PC的改进方案,即3PC。

3PC (Three-Phase Commit 三阶段提交协议)

3PC,三阶段提交协议,是2PC的改进版本,即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。

阶段1:CanCommit
  1、协调者向所有参与者发出包含事务内容的CanCommit请求,询问是否可以提交事务,并等待所有参与者答复。
  2、参与者收到CanCommit请求后,如果认为可以执行事务操作,则反馈YES并进入预备状态,否则反馈NO。

阶段2:PreCommit
  此阶段分两种情况:
  1、所有参与者均反馈YES,即执行事务预提交。
  2、任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈,即中断事务。
 
  事务预提交:(所有参与者均反馈YES时)
  1、协调者向所有参与者发出PreCommit请求,进入准备阶段。
  2、参与者收到PreCommit请求后,执行事务操作,将Undo和Redo信息记入事务日志中(但不提交事务)。
  3、各参与者向协调者反馈Ack响应或No响应,并等待最终指令。
 
  中断事务:(任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈时)
  1、协调者向所有参与者发出abort请求。
  2、无论收到协调者发出的abort请求,或者在等待协调者请求过程中出现超时,参与者均会中断事务。

阶段3:do Commit
   此阶段也存在两种情况:
  1、所有参与者均反馈Ack响应,即执行真正的事务提交。
  2、任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈,即中断事务。
 
  提交事务:(所有参与者均反馈Ack响应时)
  1、如果协调者处于工作状态,则向所有参与者发出do Commit请求。
  2、参与者收到do Commit请求后,会正式执行事务提交,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务提交。
 
  中断事务:(任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈时)
  1、如果协调者处于工作状态,向所有参与者发出abort请求。
  2、参与者使用阶段1中的Undo信息执行回滚操作,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务中断。
 
  注意:进入阶段三后,无论协调者出现问题,或者协调者与参与者网络出现问题,都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时,参与者都会在等待超时之后,继续执行事务提交。

附示意图如下:

3PC的优点和缺陷

  优点:降低了阻塞范围,在等待超时后协调者或参与者会中断事务。避免了协调者单点问题,阶段3中协调者出现问题时,参与者会继续提交事务。
 
  缺陷:脑裂问题依然存在,即在参与者收到PreCommit请求后等待最终指令,如果此时协调者无法与参与者正常通信,会导致参与者继续提交事务,造成数据不一致。

Paxos

Paxos是一种基于消息传递的分布式一致性算法,由Leslie Lamport(莱斯利·兰伯特)于1990提出。是目前公认的解决分布式一致性问题的最有效算法。

现实中Paxos的实现以及成为一些世界级软件的心脏,如Cassandra, Google的 Spanner数据库, 分布式锁服务Chubby。

要解决的问题及应用场景

  Paxos算法要解决的问题,可以理解为:一个异步通信的分布式系统中,如何就某一个值(决议)达成一致。
  而此处异步通信是指,消息在网络传输过程中存在丢失、超时、乱序现象。
 
  其典型应用场景为:
  在一个分布式系统中,如果各节点初始状态一致,而且每个节点执行相同的命令序列,那么最后就可以得到一个一致的状态。为了保证每个节点执行相同的命令序列,即需要在每一条指令上执行一致性算法(如Paxos算法),来保证每个节点指令一致。

概念定义

  Proposal:为了就某一个值达成一致而发起的提案,包括提案编号和提案的值。
 
  涉及角色如下:
  Proposer:提案发起者,为了就某一个值达成一致,Proposer可以以任意速度、发起任意数量的提案,可以停止或重启。
  Acceptor:提案批准者,负责处理接收到的提案,响应、作出承诺、或批准提案。
  Learner:提案学习者,可以从Acceptor处获取已被批准的提案。

约定

  Paxos需要遵循如下约定:
  1、一个Acceptor必须批准它收到的第一个提案。
  2、如果编号为n的提案被批准了,那么所有编号大于n的提案,其值必须与编号为n的提案的值相同。

算法描述

  阶段一:准备阶段
 
  1、Proposer选择一个提案编号n,向Acceptor广播Prepare(n)请求。
  2、Acceptor接收到Prepare(n)请求,如果编号n大于之前已经响应的所有Prepare请求的编号,那么将之前批准过的最大编号的提案反馈给Proposer,并承诺不再接收编号比n小的提案。否则不予理会。
 
  阶段二:批准阶段
 
  1、Proposer收到半数以上的Acceptor响应后,如果响应中不包含任何提案,那么将提案编号n和自己的值,作为提案发送Accept请求给Acceptor。否则将编号n,与收到的响应中编号最大的提案的值,作为提案发送Accept请求给Acceptor。
  2、Acceptor收到编号为n的Accept请求,只要Acceptor尚未对编号大于n的Prepare请求做出响应,就可以批准这个提案。

死循环问题

  如果Proposer1提出编号为n1的提案,并完成了阶段一。与此同时Proposer2提出了编号为n2的提案,n2>n1,同样也完成了阶段一。于是Acceptor承诺不再批准编号小于n2的提案,当Proposer1进入阶段二时,将会被忽略。同理,此时,Proposer1可以提出编号为n3的提案,n3>n2,又会导致Proposer2的编号为n2的提案进入阶段二时被忽略。以此类推,将进入死循环。
 
  解决办法:
 
  可以选择一个Proposer作为主Proposer,并约定只有主Proposer才可以提出提案。因此,只要主Proposer可以与过半的Acceptor保持通信,那么但凡主Proposer提出的编号更高的提案,均会被批准。

Learner

  一旦Acceptor批准了某个提案,即将该提案发给所有的Learner。为了避免大量通信,Acceptor也可以将批准的提案,发给主Learner,由主Learner分发给其他Learner。考虑到主Learner单点问题,也可以考虑Acceptor将批准的提案,发给主Learner组,由主Learner组分发给其他Learner。


参考

https://blog.51cto.com/11821908/2058651

https://blog.51cto.com/11821908/2058996

https://www.cnblogs.com/hugb/p/8955408.html

https://www.jianshu.com/p/89c92bfc48f4

https://baike.baidu.com/item/Paxos%20%E7%AE%97%E6%B3%95

https://www.jdon.com/artichect/paxos.html

https://github.com/oldratlee/translations/tree/master/paxos-made-simple

分布式一致性算法 2PC 3PC Paxos的更多相关文章

  1. 分布式一致性算法2PC和3PC

    为了解决分布式一致性问题,产生了不少经典的分布式一致性算法,本文将介绍其中的2PC和3PC.2PC即Two-Phase Commit,译为二阶段提交协议.3PC即Three-Phase Commit, ...

  2. 分布式:2PC,3PC,Paxos,Raft,ISR [转]

    本文主要讲述2PC及3PC,以及Paxos以及Raft协议. 两类一致性(操作原子性与副本一致性) 2PC协议用于保证属于多个数据分片上的操作的原子性.这些数据分片可能分布在不同的服务器上,2PC协议 ...

  3. 分布式一致性算法——paxos

    一.什么是paxos算法 Paxos 算法是分布式一致性算法用来解决一个分布式系统如何就某个值(决议)达成一致的问题. 人们在理解paxos算法是会遇到一些困境,那么接下来,我们带着以下几个问题来学习 ...

  4. [转帖]分布式一致性协议介绍(Paxos、Raft)

    分布式一致性协议介绍(Paxos.Raft) https://www.cnblogs.com/hugb/p/8955505.html  两阶段提交 Two-phase Commit(2PC):保证一个 ...

  5. 分布式一致性算法:Raft 算法(论文翻译)

    Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的 ...

  6. 【转】Raft 为什么是更易理解的分布式一致性算法

    编者按:这是看过的Raft算法博客中比较通俗的一篇了,讲解问题的角度比较新奇,图文并茂,值得一看.原文链接:Raft 为什么是更易理解的分布式一致性算法 一致性问题可以算是分布式领域的一个圣殿级问题了 ...

  7. 【转】分布式一致性算法:Raft 算法(Raft 论文翻译)

    编者按:这篇文章来自简书的一个位博主Jeffbond,读了好几遍,翻译的质量比较高,原文链接:分布式一致性算法:Raft 算法(Raft 论文翻译),版权一切归原译者. 同时,第6部分的集群成员变更读 ...

  8. 分布式一致性算法--Paxos

    Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法.Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致.在工程实践意义上来说, ...

  9. 分布式一致性协议-2PC与3PC(二)

    一.分布式一致性 一个事务需要跨多个分布式节点,又要保持事务的ACID特性,需要引入协调者来统一调度所有分布式节点的执行逻辑,被调度的节点称为参与者. 协调者负责调用参与者,并决定最终是否提交事务.基 ...

随机推荐

  1. 【MySQL】CentOS7中使用systemctl工具管理启动和停止MySQL

    centos7以前版本,可以使用这个/etc/init.d/mysqld start 来启动mysql 但是centos7之后,通过systemctl start mysqld.service 这个要 ...

  2. Python机器学习笔记:奇异值分解(SVD)算法

    完整代码及其数据,请移步小编的GitHub 传送门:请点击我 如果点击有误:https://github.com/LeBron-Jian/MachineLearningNote 奇异值分解(Singu ...

  3. oracle字符集与乱码(转)

    作者:hcling97    http://blog.sina.com.cn/hcling97 2013年5月15日 转载请注明出处 字符集问题一直叫人头疼,究其原因还是不能完全明白其运作原理. 在整 ...

  4. 在.NET Core 中实现健康检查

    .NET Core中提供了开箱即用的运行状况检查,首先,我将在.NET Core API应用程序中执行运行状况检查,接下来,我们将使用DbContext集成SQL Server或数据库的运行状况检查, ...

  5. Redis 实战 —— 07. 复制、处理故障、事务及性能优化

    复制简介 P61 关系型数据库通常会使用一个主服务器 (master) 向多个从服务器 (slave) 发送更新,并使用从服务器来处理所有读请求. Redis 也采用了同样的方法实现自己的复制特性,并 ...

  6. linux通过ntp同步时间

    1.安装服务 yum install ntp ##安装ntp服务,这个和ntpdate不一样哦,用这个比较好 systemctl start ntpd.service ###启动服务 systemct ...

  7. 如何将python中pip源设置为国内源

    1.Windows Python的学习过程中,往往会学习到很多库,而安装各类库的时候,往往不尽人意,下载速度从几KB到十几KB.甚至下载到一半还超时报错.这都是因为pip源是访问国外的官方源,如果需要 ...

  8. AES 密钥与 RSA 密钥的关系

    AES 加密说明 - 支付宝开放平台 https://opendocs.alipay.com/open/common/104567 AES 密钥是对接口请求和响应内容进行加密,密文无法被第三方识别,从 ...

  9. Hive语法小释

    阅读本文你可以获取: 1.数据库的查询 2.hive表的基本操作(建表三种常用方式.删除表.修改表.加载数据.内外表转换.添加分区.复制数据) 3.SQL到HiveQL的的一些不同点 1.   基本操 ...

  10. 代理模式详解:静态代理+JDK/CGLIB 动态代理实战

    1. 代理模式 代理模式是一种比较好的理解的设计模式.简单来说就是 我们使用代理对象来代替对真实对象(real object)的访问,这样就可以在不修改原目标对象的前提下,提供额外的功能操作,扩展目标 ...