分布式事务的典型处理方式:2PC、TCC、异步确保和最大努力型

1. 柔性事务和刚性事务

柔性事务满足BASE理论(基本可用,最终一致)
刚性事务满足ACID理论

本文主要围绕分布式事务当中的柔性事务的处理方式进行讨论。

柔性事务分为

  1. 两阶段型
  2. 补偿型
  3. 异步确保型
  4. 最大努力通知型几种。 由于支付宝整个架构是SOA架构,因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要,以上几种事务类似就是针对分布式环境下业务需要设定的。

2. 两阶段提交(2PC)型

两阶段型:就是分布式事务两阶段提交,对应技术上的XA、JTA/JTS。
这是分布式环境下事务处理的典型模式。

2、事务补偿型(TCC事务):

TCC型事务(Try/Confirm/Cancel)可以归为补偿型。
补偿型的例子,在一个长事务( long-running )中 ,一个由两台服务器一起参与的事务,服务器A发起事务,服务器B参与事务,B的事务需要人工参与,所以处理时间可能很长。如果按照ACID的原则,要保持事务的隔离性、一致性,服务器A中发起的事务中使用到的事务资源将会被锁定,不允许其他应用访问到事务过程中的中间结果,直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定,系统的可用性将不可接受。
WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子,服务器A的事务如果执行顺利,那么事务A就先行提交,如果事务B也执行顺利,则事务B也提交,整个事务就算完成。但是如果事务B执行失败,事务B本身回滚,这时事务A已经被提交,所以需要执行一个补偿操作,将已经提交的事务A执行的操作作反操作,恢复到未执行前事务A的状态。这样的SAGA事务模型,是牺牲了一定的隔离性和一致性的,但是提高了long-running事务的可用性。
例子来源:OASIS的WS-BusinessActivity文档

3、异步确保型

将一些同步阻塞的事务操作变为异步的操作,避免对数据库事务的争用,典型例子是热点账户异步记账、批量记账的处理。

4、最大努力型

PPT中提到的例子交易的消息通知(例如商户交易结果通知重试、补单重试)

如果有技术背景,可以参考另外一个文档 大规模SOA系统中的分布事务处事 ,对支付宝分布式事务处理机制有较为详细描述。
更详细的也可以参考OASIS的相关资料。

参考资料:
https://www.zhihu.com/question/31813039(梁川)
支付宝架构与技术
大规模SOA系统中的分布式事务处理


from: http://kaimingwan.com/post/fen-bu-shi/fen-bu-shi-shi-wu-de-dian-xing-chu-li-fang-shi-2pc-tcc-yi-bu-que-bao-he-zui-da-nu-li-xing

  • 8
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
TCC(Try-Confirm-Cancel)是一种分布式事务解决方案,它通过将一个事务拆分成三个阶段(Try、Confirm、Cancel)来保证事务的一致性。而在分布式环境下,TCC通常使用3PC协议来实现。 3PC(Three-Phase Commit)协议是一种常用的分布式事务协议,它将一个分布式事务分为三个阶段(CanCommit、PreCommit、DoCommit),并通过协调者(Coordinator)和参与者(Participant)之间的消息交换来实现事务的原子性和一致性。 具体来说,TCC使用的3PC协议流程如下: 1. CanCommit 阶段:协调者向参与者发送CanCommit请求,询问参与者是否可以执行该事务。如果参与者可以执行,则发送Yes响应,否则发送No响应。 2. PreCommit 阶段:协调者向参与者发送PreCommit请求,告诉参与者可以执行该事务,并让它准备好提交或撤销事务。如果参与者准备好了,则发送Ack响应。 3. DoCommit 阶段:协调者向参与者发送DoCommit请求,告诉参与者提交该事务。如果参与者成功提交了事务,则发送Ack响应,否则发送Abort响应。 如果任何一个阶段出现问题,协调者会向参与者发送Cancel请求,撤销事务。 需要注意的是,在TCC中,Try阶段和Cancel阶段由应用程序自己来实现,3PC协议主要用于Confirm和DoCommit阶段的协调。此外,由于3PC协议的复杂性和性能问题,TCC并不适用于所有的分布式事务场景,开发者需要根据具体的业务需求来选择合适的解决方案。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值