复杂的业务交互过程中,不建议使用强一致性的分布式事务。
解决分布式事务的最好办法就是不考虑分布式事务。
就像刚说的问题一样,把分布式的事务过程拆解成多个中间状态,中间状态的东西不允许用户直接操作,等状态都一致成功,或者检测到不一致的时候全部失败掉。就解耦了这个强一致性的过程。
一般情况下准实时就成了。涉及到钱,有时候也可以这么搞。
淘宝几s内完整一个订单处理,不是什么问题吧。
银行也不是全部都强一致性。也会扎差,也会冲正。
特别是涉及到多个系统的时候,我们比如买机票,支付完成以后,只支付完成状态,然后返回给用户了,我们过几分钟再刷新页面,才会看到变成已出票,订单完成状态。
这个时候,如果我们要求所有处理,都是强一致性的,那么久完蛋了。页面要死在那儿几分钟,才把这个事务处理完成,返回给用户。
解决分布式事务的最好办法就是不考虑分布式事务。
拆分,大的业务流程,转化成几个小的业务流程,然后考虑最终一致性。
问题2:分布式事务是你们自己开发的,还是数据库自带的?
kimmking:
1、只要一个处理逻辑能保证要么成功,要么跟什么也没做一样,都算是事务。数据库事务,MQ也有事务。
你自己甚至可以写个程序生成两个文件,要么都生成了,要么都删掉不留痕迹,这也算是事务。
2、分布式事务这一块有个XA规范,实现XA接口的事务,都可以加入到一个分布式事务中,被XA容器管理起来。
3、补偿的办法,需要具体情况具体分析,没有一个各种场合都适用的框架。
时间: 2024-10-26 22:23:32