展开

关键词

面试被问分布式事务(2PC3PCTCC),这样解释没毛病!

二阶提交协议(2PC)和三阶提交协议(3PC)就是根据此协议衍生出来而来。如今Oracle、Mysql等数据库均已实现了XA接口。 2、三段提交(3PC) 三段提交(3PC)是对两段提交(2PC)的一种升级优化,3PC2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前,各参与者节点的状态都一致。 3、补偿事务(TCC) 很多初学者总是被TCC2PC3PC这几个概念搞混淆,傻傻分不清,实际上 TCC2PC3PC一样,都只是实现分布式事务的一种方案而已。 TCC(Try-Confirm-Cancel)又被称补偿事务,TCC2PC的思想很相似,事务处理流程也很相似,但2PC 是应用于在DB层面,TCC则可以理解为在应用层面的2PC,是需要我们编写业务逻辑来实现 总结 很浅显的介绍了一下2PC3PCTCC的概念,如有错误还望温柔指正,分布式事务一直都是面试中比较热点的问题,也是进阶高级Java工程师必备的知识点。

16320

面试被问分布式事务(2PC3PCTCC),这样解释没毛病!

二阶提交协议(2PC)和三阶提交协议(3PC)就是根据此协议衍生出来而来。如今Oracle、Mysql等数据库均已实现了XA接口。 2、三段提交(3PC) 三段提交(3PC)是对两段提交(2PC)的一种升级优化,3PC2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前,各参与者节点的状态都一致。 3、补偿事务(TCC) 很多初学者总是被TCC2PC3PC这几个概念搞混淆,傻傻分不清,实际上 TCC2PC3PC一样,都只是实现分布式事务的一种方案而已。 TCC(Try-Confirm-Cancel)又被称补偿事务,TCC2PC的思想很相似,事务处理流程也很相似,但2PC 是应用于在DB层面,TCC则可以理解为在应用层面的2PC,是需要我们编写业务逻辑来实现 总结 很浅显的介绍了一下2PC3PCTCC的概念,如有错误还望温柔指正,分布式事务一直都是面试中比较热点的问题,也是进阶高级Java工程师必备的知识点。

2K00
  • 广告
    关闭

    腾讯云校园大使火热招募中!

    开学季邀新,赢腾讯内推实习机会

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    分布式事务之深入理解什么是2PC3PCTCC协议?

    3PCTCC之类的基本问题,之后再单独去介绍RocketMQ事务消息相关的实践。 以上就是3PC相对于2PC的一个提高(相对缓解了2PC中的前两个问题),但是3PC依然没有完全解决数据不一致的问题。 6 补偿事务(TCC) 说起分布式事务的概念,不少人都会搞混淆,似乎好像分布式事务就是TCC。实际上TCC2PC3PC一样,只是分布式事务的一种实现方案而已。 TCC事务的处理流程与2PC两阶段提交类似,不过2PC通常都是在跨库的DB层面,而TCC本质上就是一个应用层面的2PC,需要通过业务逻辑来实现。 TCC的具体原理图如?: ? 7 消息队列MQ事务 在前面介绍2PC3PC的时候我们说没有根本解决性能问题,而如果通过MQ的事务消息来进行异步解耦,并实现系统的数据的最终一致性的话会不会好很多呢?

    1.5K20

    读完这一篇,我不信你还不懂分布式事务TCC

    前言 前面我们说了两期分布式事务模型,分别是2PC3PC2PC模型它的效率比较低,并且会出现事务阻塞等问题,所以引入了3PC模型, 3PC模型在2PC模型的基础上进行了改进,避免了事务阻塞问题,不过对于 2PC3PC模型,他们依然是阻塞的,也就是说当前事务在 执行的过程中,其他事务都会被阻塞,所以实际上他们的效率都不高,如果对于并发量不发的系统,那么可以选择它们,但是在高并发的 场景下,用2PC模型和 3PC模型,显然就不行了,所以今天我们引入了TCC模型。 TCC解释 前面的2PC3PC属于强一致性分布式事务,TCC属于最终一致性分布式事务,T是Try,第一个C是Confirm,第二个 C是Concel,这三个过程都需要工程师自己去编码,所以TCC对业务的入侵很大 总结 完成了TCC的分析,我们可以看出TCC事务之间并没有阻塞,但是事务的成败很大一部分是掌握在开发人员的手上,因为它不像2PC模式的 框架完全是由框架来帮我们完成事务的提交和回滚,在TCC模式中,事务的提交回滚都是要由我们去编写业务代码来实现

    8120

    分布式事务2PC && 3PC

    (from Wikipedia) 2PC 阶段1:请求阶段(commit-request phase,或称表决阶段,voting phase) 协调者节点向所有参与者节点询问是否可以执行提交操作 现实生活中其实很多地方都在使用 2PC : 组织者组织出游,给每个参与者发送出游确认邮件,每个参与者回复去或是不去给组织者,如果都回复ok,那么就可以出游,要是有一个人回复NO, 那么这次出游就取消( 使用了2PC) 2PC 存在的问题 同步阻塞问题 它的执行过程中间,节点都处于阻塞状态。 2PC 无法解决这个问题,这个问题有可能导致数据不一致的 ,于是就有了3PC(三阶段提交) 3PC 三阶段提交(英语:Three-phase commit),也叫三阶段提交协议(英语:Three-phase 参考 wikipedia 分布式系统的事务处理 关于分布式事务、两阶段提交协议、三阶提交协议 深入理解分布式系统的2PC3PC 吃水不忘挖井人:原文链接:http://int64.me/2016/%E5%

    17910

    .Net Core with 微服务 - 分布式事务 - TCC

    上一次我们讲解了分布式事务的 2PC3PC 。那么这次我们来理一下 TCC 事务。本次还是讲解 TCC 的原理跟 .NET 其实没有关系。 TCC Try 准备阶段,尝试执行业务 Confirm 完成业务 Cancel 回滚准备阶段的业务 TCC 事务其实是 2PC 的一个扩展。上一次我们说了 2PC ,在二阶段进行事务提交。 TCC 可以认为是业务层面的2PC 。 下面我们以使用客户积分兑换房间为示例说明一下 TCC 事务。 总结 TCC 事务是 2PC 的一种升级。TCC 相对于 2PC 不再依赖于本地数据库事物能力,它可以使用于应用层面的事务。 、3PC

    27020

    什么是 “分布式事务” ?

    这一篇内容还是避免不了俗套,主要的范围无非是XA、2PC3PCTCC,再最后到Seata。 但是,我认为这东西,只是适用于面试和理论的了解,你真要说这些方案实际生产中有人用吗? 2PC XA定义了规范,那么2PC3PC就是他的具体实现方式。 2PC叫做二阶段提交,分为投票阶段和执行阶段两个阶段。 3PC 既然2PC有这么多问题,所以就衍生出了3PC的概念,也叫做三阶段提交,他把整个流程分成了CanCommit、PreCommit、DoCommit三个步骤,相比2PC,增加的就是CanCommit TCC TCC的模式叫做Try、Confirm、Cancel,实际上也就是2PC的一个变种而已。 事务模式-Saga-图片来自阿里云官网 总结 这里从事务的ACID开始,向大家先说了XA是分布式事务处理的规范,之后谈到2PC3PC2PC有同步阻塞、单点故障和数据不一致的问题,3PC在一定程度上解决了同步阻塞和单点故障的问题

    34310

    分布式事务实现原理【BAT 面试题宝库附详尽答案解析】

    分布式事务常见解决方案: 2PC两段提交协议 3PC三段提交协议(弥补两端提交协议缺点) TCC或者GTS(阿里) 消息中间件最终一致性 使用LCN解决分布式事物,理念“LCN并不生产事务,LCN只是本地事务的搬运工 2PC 无法解决这个问题。 三阶段提交(3PC) ? 三阶段提交协议(3PC)主要是为了解决两阶段提交协议的阻塞问题,2pc存在的问题是当协作者崩溃时,参与者不能做出最后的选择。 以上就是3PC相对于2PC的一个提高(相对缓解了2PC中的前两个问题),但是3PC依然没有完全解决数据不一致的问题。 2PC / 3PC / XA ? 1、基础概念 最终一致性 RocketMQ是一种最终一致性的分布式事务,就是说它保证的是消息最终一致性,而不是像2PC3PCTCC那样强一致分布式事务,至于为什么说它是最终一致性事务下面会详细说明。 参考资料 分布式事务(1)---2PC3PC原理 分布式事务(2)---TCC原理 分布式事务(3)—RocketMQ实现分布式事务原理 分布式事务:深入理解什么是2PC3PC 分布式事务、

    44610

    女朋友问敖丙:什么是分布式事务?

    不过暖男为了保证文章的完整性确保所有人都听得懂,我还是得先说说 ACID,然后再来介绍下什么是分布式事务和常见的分布式事务包括 2PC3PCTCC、本地消息表、消息事务、最大努力通知。 3PC 3PC 的出现是为了解决 2PC 的一些问题,相比于 2PC 它在参与者中也引入了超时机制,并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态。 让我们来详细看一下。 当然 3PC 协调者超时还是在的,具体不分析了和 2PC 是一样的。 TCC 2PC3PC 都是数据库层面的,而 TCC 是业务层面的分布式事务,就像我前面说的分布式事务不仅仅包括数据库的操作,还包括发送短信等,这时候 TCC 就派上用场了! 相对于 2PC3PCTCC 适用的范围更大,但是开发量也更大,毕竟都在业务上实现,而且有时候你会发现这三个方法还真不好写。

    26730

    聊一下分布式事务

    分布式事务方案 2PC/3PC 2PC即二阶段提交) : 二阶段提交(英语:Two-phase Commit)是指在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法 阶段,可能存在只有部分参与者收到Commit消息(或处理成功)的情况 3PC 3PC即三阶段提交,它比2PC多了一个阶段,即把原来2PC的准备阶段拆分成CanCommit和PreCommit两个阶段,同时 但是在我看来3PC并没有解决2PC的根本问题,它只是在2PC的基础上做了一些优化,它增加了一个阶段(也增加了1个RTT)来提高对方可用性的概率,这本质跟TCP的三次握手一样,同样也改为四次握手,五次握手等等 看上去TCC2PC/3PC可能有点像,但是TCC强调的是补偿,而且对于对资源的“预留”,“确认”,“释放”,TCC并没有明确说要如何做,这个具体是要业务来定义的。 分布式事务一致性与Paxos一致性的思考 首先要明确一点的就是对于上述提到的分布式事务解决方案,如TCC、Saga、本地消息表等,其本质都是2PC

    21520

    一文理解分布式事务的解决方案

    本文将介绍分布式事务常见的解决方案: 2PC 3PC TCC Saga事务 基于本地消息表机制 基于事务消息机制 最大努力通知机制 常见解决方案 分布式事务是由多个本地事务组成的,分布式事务跨越了多设备 3PC 3PC相对2PC增加了三阶段模式以及超时机制。 解决2PC同步阻塞的情况. 同时3PC增加的第一阶段的询问通知,降低2PC中的数据不一致问题的概率。 但2PC中的单点故障问题,3PC并没有解决。 总结 2PC还是3PC都是协议,是一种指导思想,与项目中真正的落地方案还是有差别的。 但2PC3PC对于大型分布式系统很少会使用,因为在事务处理过程中,协调者需要同时连接多个数据库(RM)。 TCC 不管是2PC还是3PC都是依赖于数据库的事务提交和回滚。 但有时一些业务不仅仅涉及到数据库,例如发送一条短信、上传一张图片等业务层的逻辑。

    14120

    ​浅谈大数据中的 2PC3PC、Paxos、ZAB

    其实可能发现不管是CAP理论,还是BASE理论,他们都是理论,这些理论是需要算法来实现的,今天讲的2PC3PC、Paxos算法,ZAB算法就是干这事情。 3PC 三阶段提交(Three-phase commit),是二阶段提交(2PC)的改进版本。与两阶段提交不同的是,三阶段提交有两个改动点。 引入超时机制。同时在协调者和参与者中都引入超时机制。 也就是说,除了引入超时机制之外,3PC2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。 ? 在这里插入图片描述 第一阶段canCommit 3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求,参与者如果可以提交就返回Yes响应,否则返回No响应。 参考 2PC3PC通俗说 Paxos形象说 知乎李凯讲Paxos 不错的Paxos讲解

    15210

    一文读懂分布式事务及其解决方案

    三、分布式系统的一致性 1、CAP原则 2、Base理论 四、分布式事务的解决方案 1、2PC 2、3PC 3、TCC 4、本地消息表 5、Saga 五、总结 一、什么是事务?    2PC3PC比较 3PC2PC相比,主要是保证了在“协调者”单点故障情况下参与者的一致性。 但是并不能保证整个系统的一致性,如果是”参与者“故障还是会存在长时间阻塞的情况。 目前3PC在实际系统中很少使用,主要原因有如下两点: 2PC中由于”协调者“单点故障出现长时阻塞的情况很少出现。 由于3PC多引入了一个阶段,因此”协调者“与”参与者“之间多了一层通讯,效率与2PC相比太低。 3、TCC   TCC是服务化的二阶段编程模型,最终一致性,其Try、Confirm、Cancel 3个方法均由业务编码实现; Try操作作为一阶段,负责资源的检查和预留。

    5120

    分布式事务种类介绍

    二、3PC 三阶段提交 相对于二阶段提交,三阶段提交在一阶段和二阶段中增加了一步准备阶段,以确保事务在提交时,所有节点的状态是一致的! 相对二阶段提交所做的优化 相比较2PC而言,3PC对于协调者和参与者都设置了超时时间,而2PC只有协调者才拥有超时机制。 但是3PC依然没有完全解决数据不一致的问题。 三、补偿事务(TCCTCC(Try-Confirm-Cancel)又称补偿事务。 • 不作任何业务检查 • 只使用Try阶段预留的业务资源 • Confirm操作要满足幂等性 3.Cancel: 取消执行业务 • 释放Try阶段预留的业务资源 • Cancel操作要满足幂等性 4.TCC 缺陷 tcc事务补偿性对业务代码的侵入性过高,开发成本大!需要开发人员在业务层手动提供提交操作以及混滚操作!所以对开发人员要求也比较高!

    18520

    分布式事务(四)之TCC

    我们前边讲过的2PC3PC都属于两阶段型,两阶段型事务存在长期锁定资源的情况,导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。 TCC TCC 事务介绍 TCC方案是可能是目前最火的一种柔性事务方案了。 TCC事务处理流程和 2PC 二阶段提交类似,不过2PC通常都是在跨库的DB层面,而TCC本质就是一个应用层面的2PC,如下为TCC原理图。 以上文中的订单服务为例,2PC中只需要提供一个下单接口即可,而TCC中缺需要提供Try-Confirm-Cancel三个接口,大大增加了开发量。 2PC实现分布式事务分为准备阶段和提交阶段,2PC的关键是在准备阶段,在这个阶段所有参与者必须完成约束检查,达成关于分布式事务一致性的共识。第二阶段,根据之前达成的共识,完成相应的操作。

    11100

    我还不懂什么是分布式事务

    XA规范提供了一种重要思想: 1、引入全局事务的控制节点,事务的协调者 2、多个本地事务划分多阶段提交(也就是下面讲的2PC3PC) 我不懂分布式方案 有了规范就会有落地方案,下面介绍基于XA规范的几个实现协议 从百科可以看到3PC的引入主要就是为了解决上面我们说的2PC的缺点,咋就能解决呢? 3PC2PC第一阶段再次拆分为2个阶段,多了一个阶段其实就是在执行事务之前来确认参与者是否正常,防止个别参与者不正常的情况下,其他参与者都执行了事务锁定资源。 TCC(Try-Confirm-Cancel) 2PC/3PC 模式基于 支持本地 ACID 事务 的 关系型数据库: 一阶段 prepare 行为:在本地事务中,一并提交业务数据更新和相应回滚日志记录 TCC模式实现难度还是蛮大的,需要考虑很多异常场景,还要考虑资源如何锁定和释放,但是由于不会阻塞资源,应用方面也更广,据说还是有很多公司热衷于这种补偿型的事务实现方式 还有就是这里所说的TCC更多是一种思想

    21920

    .Net Core with 微服务 - 分布式事务 - 2PC3PC

    3PC 由于 2PC 的众多问题,又有人发明了 3PC 事务。 3PC 事务是对 2PC 的一次改进: 首先引入了超时机制避免事务长时间阻塞。 但是 3PC 任然无法完全解决问题,在 DoCommit 命令发布后,依然有可能部分参与者提交成功,部分失败,2PC 数据不一致的问题 3PC 依然无法避免。 总结 以上简单介绍了 2PC3PC 分布式事务的原理。我们可以看到 2PC 在理想情况下是可以保证数据一致性的。 3PC 虽然改进了 2PC 的一些缺点,但是仍然没有解决掉最致命的数据不一致的问题、以及性能的问题。所以 2PC3PC 并不是分布式事务的首选方案。 那么下期我们将继续这个话题,继续介绍 TCC 分布式事务。

    13140

    聊聊分布式事务

    分布式事务实现方案 基于数据库资源层面 2PC 两阶段提交协议 3PC 三阶段提交协议 基于业务层面 TCC 基于数据库资源层面实现方案,由于存在多个事务,我们需要存在一个角色管理各个事务的状态。 基于协调者与参与者的思想设定,分别提出了 2PC3PC 实现XA 分布式事务。 2PC 两阶段提交协议 如名字所知,这个过程主要分为两步。 于是针对 2PC 存在的缺点,提出改进方案,3PC3PC 三阶段提交协议 三阶段提交,在两阶段提交的基础下,改进两阶段。三阶段步骤如下。 TCC 分别为 Trying,Confirm,Cancel 三个单词缩写。不同于 2PC3PC 基于数据库层面,TCC 基于应用层面。 使用 2PC3PC 实现的分布式框架,业务应用层无需改动,接入较简单。但是相对应能较低,数据资源锁定较长。不太适合互联网等高并发业务场景。

    23920

    相关产品

    • 智慧会务

      智慧会务

      腾讯云智慧会务可以广泛运用于商务会议、行业论坛、企业年会、路演、演讲等诸多场景,通过小程序或者H5的能力,结合人脸识别、电子名片、同声传译、视频直播等技术,实现会议组织的在线化、数字化、无纸化。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券