专栏首页分布式架构分布式架构设计篇(六)-刚性事务之3PC详解
原创

分布式架构设计篇(六)-刚性事务之3PC详解

引言:2PC必须注意的问题

咱们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。但是不幸的是2PC还是存在几个问题:

1、全流程的同步阻塞:不管是第一阶段还是第二阶段,所有参与节点都是事务阻塞型。当参与者占有公共资源时,其他第三方访问公共资源可能不得不处于阻塞状态。

2、TM单点故障:由于全流程依赖TM的协调,一旦TM发生故障。参与者会一直阻塞下去。尤其在第二阶段,TM发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。所有参与者必须等待TM重新上线(TM重新选举)后才能继续工作。

3、TM脑裂引起数据不一致:在第二阶段中,当TM向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中TM发生了故障,这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

4、TM脑裂引起事务状态不确定:TM再发出commit消息之后宕机,而接收到这条消息的参与者同时也宕机了。那么即使通过选举协议产生了新的TM,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

一、3PC定义

2PC是CP的刚性事务,追求数据强一致性。但是通过我们上面分析可以得知TM脑裂可能造成数据不一致和事务状态不确定问题。无法达到CP的完美状态。因此业界就出现了3PC,用来处理TM脑裂引起的数据不一致和事务状态不确定问题。

因为3PC是为彻底解决的2PC的数据不一致和事务状态不确定问题而出现。根据这一个前提,加上笔者对3PC的理解,总结出3PC的注释事项:

1)3PC确保任何分支下的数据一致性 2)3PC确保任何分支最多3次握手得到最终结果(超时机制) 3)RM超时后的事务状态必须从TM获取。2PC只有TM的超时机制,3PC新增了参与者(RM)的超时机制,一方面辅助解决了2PC的事务/事务问题,还能降低一定的同步阻塞问题。因为TM、RM双向超时机制,所以维基百科对3PC定义为“非阻塞”协议。

二、优雅的3PC流程

3PC 分成3个阶段:CanCommit(准备阶段)、PreCommit(对齐阶段)、DoCommit(提交阶段);笔者根据资料对3阶段进行比较合适的翻译,非官方翻译。

准备阶段:跟2PC的表决阶段很类似,TM向参与者发送commit请求,参与者如果可以提交就返回Yes,否则返回No,询问超时默认参与者为No。唯一差别在于SQL层面:准备阶段只做了SQL处理,并未记录事务日志(Undo 和Redo)

对齐阶段:TM 和 各个参与者对齐事务状态,TM 通知各个参与者事务最终状态,各个参与者如果一致未收到事务对齐通知,会在超时后从TM反查事务状态实现事务状态对齐。在SQL层面:事务状态对齐后,记录事务日志(Undo 和Redo)

提交阶段:该阶段进行真正的事务提交。根据第二阶段得到的事务状态结果,各参与者根据TM的通知命令进行提交/abort或者超时后自动提交/abort。

下图是笔者根据资料和个人理解整理出来的一个自认为比较合理的3PC流程图:

三、总结

或许3PC也不完美,网上有好多各版本的3PC的流程图和解释。有的甚至还存在明显的问题,为3PC的理解带来了更大的苦难。身为架构师,就需要去追寻本质,了解3PC的前世今生,抓住3PC的本质,就很容易理解3PC了。

对于数据一致性,Google Chubby的作者Mike Burrows说过:“there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos。”

译文:世上只有一种一致性算法,那就是Paxos,所有其他一致性算法都是Paxos算法的不完整版。

- 作者介绍 -

林淮川

毕业于西安交通大学;奈学教育《百万架构师训练营》讲师及企业级源码内源负责人,前大树金融高级架构师、技术委员会开创者、技术总监;前天阳宏业交易事业部技术主管;多年互联网金融行业(ToB)经验。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 分布式架构设计篇(十一)-柔性事务之最大努力通知事务详解

    ​ 咱们在上一篇文章探讨了事务消息,事务消息是基于MQ实现的一种异步事务。接下来咱们开始聊聊咱们分布式事务系列中的最后一个方案:最大努力通知事务。最...

    林淮川
  • 分布式架构设计篇(五)-刚性事务之2PC详解

    ​ 分布式场景下,多个服务同时对服务一个流程,比如电商下单场景,需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等...

    林淮川
  • 分布式架构设计篇(七)-刚性事务总结和柔性事务概述

    ​ 在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等...

    林淮川
  • 分布式架构,刚性事务-2PC必须注意的问题及3PC详细解

    咱们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。但是不幸的是2PC还是存在几个问题:

    江帅帅
  • 分布式架构,刚性事务-2PC必须注意的问题及3PC详细解说

    咱们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。但是不幸的是2PC还是存在几个问题:

    江帅帅
  • 敲黑板:分布式架构,刚性事务-2PC必须注意的问题!+3PC详细解说!

    咱们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。但是不幸的是2PC还是存在几个问题:

    孙玄@奈学教育
  • 数据库事务隔离级别(脏读、幻读、不可重复读)【BAT 面试题宝库附详尽答案解析】

    为了解决上述问题,数据库通过锁机制 解决并发访问的问题。根据锁定对象不同:分为行级锁和表级锁;根据并发事务锁定的关系上看:分为共享锁定和独占锁定,共享锁定会防止...

    一个会写诗的程序员
  • Spring事务的实现源码分析,以及事务不起作用原因分析

    这篇文章写完后我改了N次,反复的读,反复的改,为的是能让读者看懂。源码分析类的文章真的很难写,懂是一回事,写又是另一回事,能写给别人看得懂又是一回事。太多英文单...

    Java艺术
  • Java问题排查工具清单

    平时的工作中经常碰到很多疑难问题的处理,在解决问题的同时,有一些工具起到了相当大的作用,在此书写下来,一是作为笔记,可以让自己后续忘记了可快速翻阅,二是分享,希...

    Java技术江湖
  • Java问题排查工具清单

    平时的工作中经常碰到很多疑难问题的处理,在解决问题的同时,有一些工具起到了相当大的作用,在此书写下来,一是作为笔记,可以让自己后续忘记了可快速翻阅,二是分享,希...

    Java团长

扫码关注云+社区

领取腾讯云代金券