分布式事务的解决方案介绍

前要：关于分布式事务问题

当我们的在进行传统模块开发时，假如在一个系统里面包括员工，财务，请假模块。每当我们进行对这些模块进行操作时需要保证当我开启一个事务的时候到我把全部的模块走完没有错误的情况下提交，但是当其一插入时报错可以将事务进行回滚，这就是在传统项目下的事务操作。

当在进行分布式系统的开发时，每个模块独立开发，也就意味着每个模块例如员工，财务，请假模块都分别分布在一台机器上分别对应模块数据库。当每个模块进行事务操作时如果是正常情况没有问题，如果其一模块出错徐亚回滚怎么保证三台机器的事务的回滚。

解决方法：

1.两阶段提交方案

第一阶段，使用一个叫事务管理器的东西进行多个数据库的协调管理。每一个系统在执行之前该管理器会去判断每个事务操作是否能够执行，如果都返回ok就进入第二阶段，一旦其一不能执行直接取消操作

第二阶段，提交，每个模块去操作对应的数据库，如果每一个数据库都回复ok，那么执行。其一异常就回滚

适合的场景：这个方法比较适合在单模块应用，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。

2.TLL方案

这个其实是用到了补偿的概念，分为了三个阶段：

1）Try阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留

2）Confirm阶段：这个阶段说的是在各个服务中执行实际的操作

3）Cancel阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作

给大家举个例子吧，比如说跨银行转账的时候，要涉及到两个银行的分布式事务，如果用TCC方案来实现，思路是这样的：

1）Try阶段：先把两个银行账户中的资金给它冻结住就不让操作了

2）Confirm阶段：执行实际的转账操作，A银行账户的资金扣减，B银行账户的资金增加

3）Cancel阶段：如果任何一个银行的操作执行失败，那么就需要回滚进行补偿，就是比如A银行账户如果已经扣减了，但是B银行账户资金增加失败了，那么就得把A银行账户资金给加回去

比较适合的场景：这个就是除非你是真的一致性要求太高，是你系统中核心之核心的场景，比如常见的就是资金类的场景，那你可以用TCC方案了，自己编写大量的业务逻辑，自己判断一个事务中的各个环节是否ok，不ok就执行补偿/回滚代码。而且最好是你的各个业务执行的时间都比较短。但是这样的话这个业务代码量维护起来比较难！

3.本地消息表

模型：

（1）首先业务系统A先往业务表操作一条数据的同时，插入一条数据到本地消息表中

（2）系统A将消息发送到MQ里面给系统B消费

（3）系统B接受到消息，在一个事务里面将一条数据先插入到信息表里面在往业务表里面插入数据，这样做的原因是为了防止消费了同一条数据的情况。当消费信息已被处理那么会回滚没有就进行操作。

（4）系统B操作成功之后会更新本地消息表的状态和A消息表的状态（可以通过ZK实现A消息表的修改）

（5）如果B系统操作失败那么两边的本地表的状态都没有变化，A会定时去扫描本地表的状态没有改变就去MQ里面发消息给B消费

（6）这个方案保证了最终一致性，就算B操作失败了，A也会不断的去发消息让B去进行重试

缺点：这个有点严重依赖本地消息表，如果是在高并发的场景下就不太实用

4.可靠消息一致性方案

模型：

（1）A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了

（2）如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉mq发送确认消息，如果失败就告诉mq回滚消息

（3）如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地的事务

（4）mq会自动定时轮询所有prepared消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认消息？那是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，确认消息发送失败了。

（5）这个方案里，要是系统B的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如B系统本地回滚后，想办法通知系统A也回滚；或者是发送报警由人工来手工回滚和补偿

5、最大努力通知方案

（1）系统A本地事务执行完之后，发送个消息到MQ

（2）这里会有个专门消费MQ的最大努力通知服务，这个服务会消费MQ然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统B的接口

（3）要是系统B执行成功就ok了；要是系统B执行失败了，那么最大努力通知服务就定时尝试重新调用系统B，反复N次，最后还是不行就放弃

结语：分布式事务问题在分布式开发过程是需要考虑的问题，但是这个东西在开发和维护的过程不管是那种方案都是相当麻烦的，所以在开发过程中应该考虑到分布式事务开发问题的解决也应该考虑到使用了分布式事务性能吞吐量都会下降也会加大对维护的成本，所以一般在比如涉及到金钱，优惠券，积分等场景时为了确保数据的一致性情况下可以使用分布式事务来保证。

分布式事务的解决方案介绍相关推荐

分布式事务的解决方案
数据库事务在说分布式事务之前,我们先从数据库事务说起. 数据库事务可能大家都很熟悉,在开发过程中也会经常使用到.但是即使如此,可能对于一些细节问题,很多人仍然不清楚.比如很多人都知道数据库事务的几个 ...
分布式事务,EventBus 解决方案:CAP【中文文档】
前言很多同学想对CAP的机制以及用法等想有一个详细的了解,所以花了将近两周时间写了这份中文的CAP文档,对 CAP 还不知道的同学可以先看一下 .NET Core 事件总线,分布式事务解决方案:CA ...
这些分布式事务的解决方案，你都知道吗
转载自这些分布式事务的解决方案,你都知道吗分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构中都会涉及到的一个东西,特别是在微服务架构中,几乎可以说是无法避免. 数据库事务在说分 ...
分布式事务控制解决方案
day1 01-分布式事务专题课程介绍.mp4 03-基础概念-分布式事务.mp4 04-基础概念-分布式事务产生的场景.mp4 05-分布式事务基础理论-理解 ...
springcloud分布式事务解决方案_搞懂分布式技术18：分布式事务常用解决方案
本文转载自 http://linkedkeeper.com 本文内容参考网络,侵删本系列文章将整理到我在GitHub上的<Java面试指南>仓库,更多精彩内容请到我的仓库里查看 http ...
分布式事务及解决方案
分布式事务 1 微服务化带来的分布式事务问题开发当中真实场景: 首先,设想一个传统的单体应用(Monolithic App),通过 3 个 Module,在同一个数据源上更新数据来完成一项业务. 很 ...
cap理论与分布式事务的解决方案
现在很火的微服务架构所设计的系统是分布式系统.分布式系统有一个著名的CAP理论,即一个分布式系统要同时满足一致性(Consistency).可用性(Availablility)和分区容错(Partit ...
分布式事务终极解决方案探讨
2019独角兽企业重金招聘Python工程师标准>>> 分布式事务终极解决方案探讨转载于:https://my.oschina.net/dslcode/blog/1606115
谈谈分布式的场景及分布式事务的解决方案
一.解决java集群的session共享的解决方案: 1.客户端cookie加密.(一般用于内网中企业级的系统中,要求用户浏览器端的cookie不能禁用,禁用的话,该方案会失效). 2.集群中,各个应 ...

分布式事务的解决方案介绍

分布式事务的解决方案介绍相关推荐

最新文章

热门文章