分布式事务笔记-几种分布式事务的实现思路

2019-08-10  本文已影响0人  LIN_dsdj

旧文。整理出来发布。

本文记录了学习分布式事务相关的理论知识的笔记和自己的一些思考

什么是事务

在之前我们讲事务,很多情况下是将单体事务。

什么是分布式事务

概念

实现思路

2PC(Two-Phase Commit)

参考《从Paxos到Zookeeper 分布式一致性原理与实践》

二阶段提交,将事务的提交过程分成了两个阶段尽处理,其指定流程分为如下几个步骤

2PC
优点

原理简单、实现方便

缺点

同步阻塞、单点问题、脑裂、太过保守

3PC

3PC主要是对2PC存在的缺点进行改进

将二阶段提交协议的“提交事务请求”一分为二,行成了由CanCommit、PerCommit、和do Commit 三个阶段组成的事务处理协议。

来自维基百科

图片来自维基百科

优点

降低了参与者的阻塞范围,并且能够在出现单签故障后继续达成一致。

缺点

参与者接收到perCommit消息后,如果网络出现分区,此时协调者所在的节点和参与者无法进行正常的网络通信,这种情况下,参与者依然会信息事务提交,必然会出现数据不一致。

基于XA的分布式事务

基于XA的分布式事务

基于XA的分布式事务,在实际业务开发中我们应用的不多,编写的也不多,但是其是对2PC的一种演进。它更多的是应用在数据库中。

两个概念:

例如在mysql中:mysql在执行分布式事务(外部XA)的时候,mysql服务器相当于xa事务资源管理器(RM),此时作为mysql的服务器起码有两个。与mysql链接的客户端相当于事务管理器,需要注意的是MySQL中只有当隔离级别为Serializable时候才能使用分布式事务。

基于分布式消息的最终一致性

参考https://www.jianshu.com/p/04bad986a4a22

基于消息的最终一致性.png

使用场景:A系统为支付模块,B系统为订单模块。A模块支付成功,提交支付成功消息。B系统进行修改订单状态,如果订单修改失败,会导致钱已经支付出去了。借鉴消息的最终一致性思想,在支付系统最后完成支付的时候进行“挂起”等待操作,之后提交消息,等B系统提交成功还是失败的消息,使用回调通知A系统是否可以进行最后的支付操作。

优点:强一致性

缺点:A系统需要等待B系统,造成时间内存的浪费

TCC补偿性事务实现

参考https://mp.weixin.qq.com/s/mIW1_K5fAoa2OlSLdXSHpQ

TCC补偿性事务实现

T:Try 尝试

C:Confirm 确认

C:Cancel 取消

TCC:尝试执行、确认操作、取消操作

基于消息的分布式事务和TCC补偿性事务比较

在实际的应用的,两种都有进行用到,但是大多数的情况下是使用TCC事务,因为在分布式系统中系统对并发量、吞吐量的要求较高。对强一致性要求就不那么高,这个就可以参考CAP、BASE的分布式的基础理论了。

分布式事务框架


参考文章:
[1]: https://www.cnblogs.com/luoyunfei99/articles/6803682.html
[2]: https://www.jianshu.com/p/04bad986a4a2
[3]: https://mp.weixin.qq.com/s/mIW1_K5fAoa2OlSLdXSHpQ "拜托,面试请不要再问我TCC分布式事务的实现原理!"
[4]: 《从Paxos到Zookeeper分布式一致性原理与实践》

上一篇下一篇

猜你喜欢

热点阅读