李艳鹏:分布式一致性协议

国际开放标准组织Open Group定义了DTS(分布式事务处理模型),模型中包含4个角色:应用程序、事务管理器、资源管理器、通信资源管理器四部分。事务处理器是统管全局的管理者,资源处理器和通信资源处理器是事务的参与者。

J2EE规范也包含此分布式事务处理模型的规范,并在所有的AppServer中进行实现,J2EE规范中定义了TX协议和XA协议,TX协议定义应用程序与事务管理器之间的接口,而XA协议定义了事务管理器与资源处理器之间的接口,在过去,大家使用AppServer,例如:Websphere、Weblogic、Jboss等配置数据源的时候会看见类似XADatasource的数据源,这就是实现了DTS的关系型数据库的数据源。企业级开发JEE中,关系型数据库、JMS服务扮演资源管理器的角色,而EJB容器则扮演事务管理器的角色。

下面我们就介绍两阶段提交协议、三阶段提交协议以及阿里巴巴提出的TCC,它们都是根据DTS这一思想演变出来的。

1. 两阶段提交协议

上面描述的JEE的XA协议就是根据两阶段提交来保证事务的完整性,并实现分布式服务化的强一致性。

两阶段提交协议把分布式事务分成两个过程,一个是准备阶段,一个是提交阶段,准备阶段和提交阶段都是由事务管理器发起的,为了接下来讲解方便,我们把事务管理器称为协调者,把资管管理器称为参与者。

两阶段如下:

  1. 准备阶段:协调者向参与者发起指令,参与者评估自己的状态,如果参与者评估指令可以完成,参与者会写redo或者undo日志(这也是前面提起的Write-Ahead Log的一种),然后锁定资源,执行操作,但是并不提交
  2. 提交阶段:如果每个参与者明确返回准备成功,也就是预留资源和执行操作成功,协调者向参与者发起提交指令,参与者提交资源变更的事务,释放锁定的资源;如果任何一个参与者明确返回准备失败,也就是预留资源或者执行操作失败,协调者向参与者发起中止指令,参与者取消已经变更的事务,执行undo日志,释放锁定的资源

两阶段提交协议成功场景示意图如下:

我们看到两阶段提交协议在准备阶段锁定资源,是一个重量级的操作,并能保证强一致性,但是实现起来复杂、成本较高,不够灵活,更重要的是它有如下致命的问题:

  1. 阻塞:从上面的描述来看,对于任何一次指令必须收到明确的响应,才会继续做下一步,否则处于阻塞状态,占用的资源被一直锁定,不会被释放
  2. 单点故障:如果协调者宕机,参与者没有了协调者指挥,会一直阻塞,尽管可以通过选举新的协调者替代原有协调者,但是如果之前协调者在发送一个提交指令后宕机,而提交指令仅仅被一个参与者接受,并且参与者接收后也宕机,新上任的协调者无法处理这种情况
  3. 脑裂:协调者发送提交指令,有的参与者接收到执行了事务,有的参与者没有接收到事务,就没有执行事务,多个参与者之间是不一致的

上面所有的这些问题,都是需要人工干预处理,没有自动化的解决方案,因此两阶段提交协议在正常情况下能保证系统的强一致性,但是在出现异常情况下,当前处理的操作处于错误状态,需要管理员人工干预解决,因此可用性不够好,这也符合CAP协议的一致性和可用性不能兼得的原理。

2. 三阶段提交协议

三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题,并且把两个阶段增加为三个阶段:

  1. 询问阶段:协调者询问参与者是否可以完成指令,协调者只需要回答是还是不是,而不需要做真正的操作,这个阶段超时导致中止
  2. 准备阶段:如果在询问阶段所有的参与者都返回可以执行操作,协调者向参与者发送预执行请求,然后参与者写redo和undo日志,执行操作,但是不提交操作;如果在询问阶段任何参与者返回不能执行操作的结果,则协调者向参与者发送中止请求,这里的逻辑与两阶段提交协议的的准备阶段是相似的,这个阶段超时导致成功
  3. 提交阶段:如果每个参与者在准备阶段返回准备成功,也就是预留资源和执行操作成功,协调者向参与者发起提交指令,参与者提交资源变更的事务,释放锁定的资源;如果任何一个参与者返回准备失败,也就是预留资源或者执行操作失败,协调者向参与者发起中止指令,参与者取消已经变更的事务,执行undo日志,释放锁定的资源,这里的逻辑与两阶段提交协议的提交阶段一致

三阶段提交协议成功场景示意图如下:

  1. 询问阶段:协调者询问参与者是否可以完成指令,协调者只需要回答是还是不是,而不需要做真正的操作,这个阶段超时导致中止
  2. 准备阶段:如果在询问阶段所有的参与者都返回可以执行操作,协调者向参与者发送预执行请求,然后参与者写redo和undo日志,执行操作,但是不提交操作;如果在询问阶段任何参与者返回不能执行操作的结果,则协调者向参与者发送中止请求,这里的逻辑与两阶段提交协议的的准备阶段是相似的,这个阶段超时导致成功
  3. 提交阶段:如果每个参与者在准备阶段返回准备成功,也就是预留资源和执行操作成功,协调者向参与者发起提交指令,参与者提交资源变更的事务,释放锁定的资源;如果任何一个参与者返回准备失败,也就是预留资源或者执行操作失败,协调者向参与者发起中止指令,参与者取消已经变更的事务,执行undo日志,释放锁定的资源,这里的逻辑与两阶段提交协议的提交阶段一致
  4. 然而,这里与两阶段提交协议有两个主要的不同:
  5. 增加了一个询问阶段,询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为,但是它并不能发现所有的这种行为,只会减少这种情况的发生
  6. 在准备阶段以后,协调者和参与者执行的任务中都增加了超时,一旦超时,协调者和参与者都继续提交事务,默认为成功,这也是根据概率统计上超时后默认成功的正确性最大

三阶段提交协议与两阶段提交协议相比,具有如上的优点,但是一旦发生超时,系统仍然会发生不一致,只不过这种情况很少见罢了,好处就是至少不会阻塞和永远锁定资源。

3. TCC

上面两节讲解了两阶段提交协议和三阶段提交协议,实际上他们能解决案例2-转账和案例3-下订单和扣库存中的分布式事务的问题,但是遇到极端情况,系统会发生阻塞或者不一致的问题,需要运营或者技术人工解决。无论两阶段还是三阶段方案中都包含多个参与者、多个阶段实现一个事务,实现复杂,性能也是一个很大的问题,因此,在互联网高并发系统中,鲜有使用两阶段提交和三阶段提交协议的场景。

阿里巴巴提出了新的TCC协议,TCC协议将一个任务拆分成Try、Confirm、Cancel,正常的流程会先执行Try,如果执行没有问题,再执行Confirm,如果执行过程中出了问题,则执行操作的逆操Cancel,从正常的流程上讲,这仍然是一个两阶段的提交协议,但是,在执行出现问题的时候,有一定的自我修复能力,如果任何一个参与者出现了问题,协调者通过执行操作的逆操作来取消之前的操作,达到最终的一致状态。

可以看出,从时序上,如果遇到极端情况下TCC会有很多问题的,例如,如果在Cancel的时候一些参与者收到指令,而一些参与者没有收到指令,整个系统仍然是不一致的,这种复杂的情况,系统首先会通过补偿的方式,尝试自动修复的,如果系统无法修复,必须由人工参与解决。

从TCC的逻辑上看,可以说TCC是简化版的三阶段提交协议,解决了两阶段提交协议的阻塞问题,但是没有解决极端情况下会出现不一致和脑裂的问题。然而,TCC通过自动化补偿手段,会把需要人工处理的不一致情况降到到最少,也是一种非常有用的解决方案,根据线人,阿里在内部的一些中间件上实现了TCC模式。

我们给出一个使用TCC的实际案例,在秒杀的场景,用户发起下单请求,应用层先查询库存,确认商品库存还有余量,则锁定库存,此时订单状态为待支付,然后指引用户去支付,由于某种原因用户支付失败,或者支付超时,系统会自动将锁定的库存解锁供其他用户秒杀。

TCC协议使用场景示意图如下:

总结一下,两阶段提交协议、三阶段提交协议、TCC协议都能保证分布式事务的一致性,他们保证的分布式系统的一致性从强到弱,TCC达到的目标是最终一致性,其中任何一种方法都可以不同程度的解决案例2:转账、案例3:下订单和扣库存的问题,只是实现的一致性的级别不一样而已,对于案例4:同步超时可以通过TCC的理念解决,如果同步调用超时,调用方可以使用fastfail策略,返回调用方的使用方失败的结果,同时调用服务的逆向cancel操作,保证服务的最终一致性。

原文发布时间为:2017-12-6

本文作者:李艳鹏

时间: 2024-09-20 06:33:31

李艳鹏:分布式一致性协议的相关文章

三:分布式事务一致性协议2pc和3pc

一:分布式一致性协议--->对于一个分布式系统进行架构设计的过程中,往往会在系统的可用性和数据一致性之间进行反复的权衡,于是就产生了一系列的一致性协议.--->长期探索涌现出一大批经典的一致性协议和算法.其中最著名的就是二阶段提交协议,三阶段提交协议和paxos算法. 二:2PC与3PC--->在分布式系统中,每一个机器节点虽然都能够明确知道自己在进行事务操作过程中的结果是成功或失败,但却无法直接获取到其他分布式节点的操作结果.因此,当一个事务操作需要跨越多个分布式节点的时候,为了保持事

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

点击我的博客查看原文. Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的思想.如果对 Paxos 算法感兴趣,可以看我的另一篇文章:分布式系列文章--Paxos算法原理与推导 摘要 Raft 是用来管理复制日志(replicated log)的一致性协议.它跟 multi-Paxos 作用相同,效率也相当,但是它的组织结构跟 Paxos 不同.这

分布式一致性算法:由数学证明推导出Paxos

序 Basic-Paxos是分布式一致性算法的元祖算法之一,现代的分布式一致性算法基本都是Basic-Paxos算法的优化.改进或简化. 由于过于晦涩难懂,Basic-Paxos也是最难理解的算法之一,然而有理由相信,直接从数学证明推导出Basic-Paxos算法是理解它最便捷的方法. 单提案表决:单轮投票一致性 定义1 设分布式节点总集合,定义集合 ,且中任意两个成员的交集不为空,则称为的法定集(或称多数派). 定义2 定义为单轮投票的全部要素的集合,为参加投票的法定集合的集合,为本轮投票的编

女娲:阿里云分布式一致性协同服务架构详解

他的演讲内容主要分为四个方面:分布式协同服务背景.女娲服务架构以及技术演进.典型女娲服务应用场景分享.全球化架构下的女娲进化,下面是本次分享内容整理.点击查看回顾视频 分布式协同服务背景 分布式协同服务 在大规模云计算场景中,为保障数据分布式一致性,数量众多的计算节点往往依赖分布式协同服务来同步对共享资源的互斥访问,或者依赖分布式协同服务的消息通知功能来协调各自之间动作,使众多节点作为一个整体完成一项工作. 作为云计算分布式系统的核心,在设计分布式协同服务之初需要考虑互斥性.消息通知和扩展性三个

【区块链之技术进阶】掰一掰区块链共识机制与分布式一致性算法

咱们在之前的很多篇文章里简单地提起了"共识算法"以及"共识攻击",大家应该对于我们之前提到的"共识攻击"印象还比较深刻吧,对的,就是我们所说的这和公司占有股份一个道理,当你占有整个公司"51%"的股份时,那就是控股了,岂不是可以为所欲为了呢?在区块链技术这也一样,咱们都知道区块链记账以后是不可以篡改的,就算是合理交易写错地址了也不行!but!当你能说服整个区块链上51%的结点同意你的请求时就能够修改记账信息,当这一方法用到不好

EMC李君鹏:掘金大数据 云平台是基础

大数据的挑战已经为业界普遍关注,而各家厂商所谓http://www.aliyun.com/zixun/aggregation/14294.html">的大数据产品也如雨后春笋般不断问世,同时关于大数据的疑惑和争论也不绝于耳,这也让用户有无所适从的感觉.日前,来自EMC的大数据和存储专家.EMC高级产品经理李君鹏做客IT专家网<专家会客室>,为我们解答了关于大数据的一些误解和疑惑,并给出了将大数据的潜在价值转化为真正的业务价值的方法. 李君鹏表示,大数据本身就是一个问题集,云技术

缓存一致性协议

缓存一致性协议 操作系统的CPU和内存并不是直接交互操作的.我们的CPU有一级缓存,CPU直接操作一级缓存,由一级缓存和内存进行交互. 当然,有的CPU有二级缓存,甚至三级缓存等.实际上,大概二十年前,一级缓存是直接和内存交互的,现在,一般是二级缓存和内存直接通讯. 每个CPU都有一级缓存,但是,我们却无法保证每个CPU的一级缓存数据都是一样的. 所以同一个程序,CPU进行切换的时候,切换前和切换后的数据可能会有不一致的情况.那么这个就是一个很大的问题了. 如何保证各个CPU缓存中的数据是一致的

计算机体系结构5_缓存一致性协议

一,AMD64缓存一致性协议         通过缓存一致性协议保证各个缓存之间,缓存与主存之间,多处理器之间的数据一致性.AMD64的缓存一致性协议为MOESI(modified, owned,  exclusive,shared,invalid)协议.                                  当cache line没有保存有效的数据时,被称作invalid,有效的数据可以来自主存或者其他处理器的缓存.                  .              

摩托罗拉李艳:女性更易带动创新氛围

[搜狐IT消息]5月14日消息,2012年,国际电信联盟将" 世界电信和信息社会日"的主题确定为"信息通信与女性"(Women and Girls in ICT),旨在呼吁各成员国政府和企业重视女性群体平等享有信息通信技术成果的权利及其在ICT行业中的地位."工作是为了更好地生活"摩托罗拉副总裁兼移动终端事业部中国区总经理李艳女士表示,无论外企还是国企,对于女性员工在政策上都比较照顾,在发展机会上两者都给予女性员工足够的空间.不同点在于外企对于女