什么是分布式事务
问题的引出
先看一张图,一个电商平台的架构图。
对于用户来说的一个创建订单的过程,背后很可能跨越了多个应用服务。涉及诸如:订单、库存、积分、优惠券等多个微服务模块,而每个模块的数据库可能存在不同节点上,但是其中的任何一个环节都有可能程序运行错误,导致数据的不一致。
例如这个支付操作里涉及到的多个数据库。
单一数据库可以简单的使用事务来保证一致性,但是分布式的问题则需要分布式的事务来控制数据的一致性。
分布式事务的产生的原因
-
数据库分库分表
-
由于单表的数据量巨大导致的分库分表,则会涉及到多个数据库的一致性问题。
-
-
应用SOA化
-
业务的服务化。多个业务中心有各自的数据库,也会涉及多个数据库的一致性问题
-
事务的ACID特性
分布式事务本质也是一个事务,则需要满足ACID特性。
-
原子性(A)
-
在整个事务中的所有操作,要么全部完成,要么全部不做,没有中间状态。
-
-
一致性(C)
-
事务必须始终保持系统处于一致的状态,不管在任何给定的时间并发事务有多少。
-
-
隔离性(I)
-
隔离性就是说,事务与事务之间不会互相影响,一个事务的中间状态不会被其他事务感知。
-
-
持久性(D)
-
一旦事务完成了,那么事务对数据所做的变更就完全保存在了数据库中,即使发生停电,系统宕机也是如此。
-
常见的分布式事务解决方案
两阶段提交--XA提交机制
XA提交机制
-
XA中大致分为两部分:
-
事务管理器:作为全局的调度者,负责各个本地资源的提交和回滚
-
本地资源管理器:往往由数据库实现
-
-
XA机制将提交过程两个阶段
-
prepare
-
commit
-
流程:
-
事务管理模块在prepare服务A的DB事务、服务B的DB事务都成功后。
-
逐个commit这些DB事务。
DB在prepare返回OK后,如果没有收到来自事务管理模块的commit/rollback请求则会一直保留该分支事务的数据。
出现错误的情况:
-
若在prepare阶段出现故障,则回滚prepare过的分支事务,从而达到全局事务回滚。
-
若在commit阶段出现故障,后续仍然可以再次commit那些未成功commit的分支事务,最终达到全局事务提交。
优点缺点
-
优点:实现简单易懂
-
缺点:性能不理想,高并发场景下表现不佳
消息事务+最终一致性
流程
借助消息队列,在处理业务逻辑的地方,发送消息,业务逻辑处理成功后,提交消息,确保消息是发送成功的。成功后的消息去通知下一步操作的B系统服务,直到全部执行完毕。
出现错误的情况:
-
通过消息队列投递来进行处理,如果成功,则结束,如果没有成功,则重试,直到成功。
-
但是注意要做到幂等性控制,因为在系统调用没有达到期望的结果后会重试,不然就会出现重复的问题。
优点缺点
-
优点:实现和逻辑简单易懂,性能大幅度提升。
-
缺点:牺牲了一定的一致性,效果是最终一致性的。
三阶段提交--TCC(Try-Confirm-Cancel)机制
流程:
-
事务管理模块是在服务A、服务B执行完毕后即刻提交其参与的DB事务。
-
-
如果全局事务决定提交,则逐个调用服务A和服务B的confirm逻辑
-
如果全局事务决定回滚,则逐个调用服务A和服务B的cancel逻辑。
-
出现错误的情况:
-
只需要根据全局事务当前状态,将服务A、服务B相应的confirm/cancel逻辑重新调用即可。
-
但是,confirm/cancel逻辑可能会被多次调用,因此,需要保证其幂等性。
优点缺点
-
优点:完全控制粒度
-
缺点:不同的业务场景所写的代码都不一样,复用性较差。
参考资料
-
分布式最终一致方案梳理,Bright Moon ‘ s Blog,cnblogs.com/BrightMoon/p/5622618.html
-
深入理解分布式事务,高并发下分布式事务的解决方案,mine_song,blog.csdn.net/mine_song/article/details/64118963
-
分布式服务的事务如何处理?- bytefox的回答 - 知乎,
zhihu.com/question/29483490/answer/237665712
参考:10 分钟看懂分布式事务