30_6、业内分布式事务方案介绍—各种分布式事务技术方案如何结合起来运用在流量充值中心内

分布式事务常见的几种方案：

（1）XA分布式事务，一般用于单系统多库的场景，当然要是多系统多库，也可以，但是就很麻烦了，不适用于这个方案了 （2）TCC方案，try-confirm-cancel方案 （3）可靠消息最终一致性方案，都不能叫做分布式事务的方案，事务，分布式一致性的方案 （4）最大努力通知方案 （5）适合长事务（分布式）的sagas方案，之前在分布式事务解决方案的筑基里面，没有提到sagas，不会放在流量充值中心系统里面来实战，会放到后面我们的实际的大电商项目里去实战

在我们这里而言，非常简单

（1）TCC方案，适合于，你的多个服务的操作都比较快

TCC相当于是一堆同步服务调用的操作，包裹在一个事务里面，同步，关键词，人家给你发起一个请求，触发了一个复杂的TCC事务，人家要等你这个事务完成结束了，然后才能接续往下走的

假如你的TCC事务里面涉及了10来个服务的调用，要10来秒才能结束，太不靠谱了

TCC方案应对的其实是大量的同步服务调用的复杂的事务场景，如果要用TCC来保证分布式事务的执行，一般来说尽量确保每个服务的调用都比较快，一般来说确保一个TCC分布式事务的执行，大概需要总共1秒以内的时间

资金转账、创建订单、抽奖机会、积分、流量券相关的服务调用的逻辑，包裹在一个分布式事务内，用TCC来控制这个分布式事务，因为这里的一些操作基本都是在流量充值中心内部的一些服务，都比较快

TCC来控制，try他们一把，锁定一些资源；confirm一把，执行各个服务的业务逻辑；如果任何一个服务出现报错和失败；那么tcc就去cancel掉各个服务的逻辑，各个服务通过补偿来的方法逻辑，去回滚之前做出的数据变动

（2）可靠消息最终一致性的方案

这个方案，适合于那那种比较耗时的操作，通过这个消息中间件做成异步调用，发送一个消息出去，人家服务消费消息来执行业务逻辑，CAP理论，C（最终一致性），也就是说包裹在一个事务中的多个操作，其中有些操作可能在一定时间内是没执行的

可能要等过一段时间之后，然后才能去执行，最终一定会执行的，最终一致性的方案，通过MQ消息中间件保证消息的可靠性，最终来实现最终一致性的方案

调用起来很耗时的操作，比如说流量充值内，调用第三方运营商的系统接口完成流量充值，坑爹了，很可能会出问题，网络调用超时，人家系统代码写的太烂，一个流量充值要耗费个10秒钟才能完成

你就很不适合包裹在TCC里面了，因为这个东西调用第三方的系统接口，如果一旦超时了，很容易影响系统本地其他服务的操作

而且的话呢，一般来说，如果你充值话费，或者是充值流量，肯定不是说你刚付钱充值完毕，人家会通知你充值成功了，发你一个短信，告诉你说，具体是否充值到账，请以运营商那边的信息为准

你付钱之后，其实流量还没充值好，在一段时间内是没充值的，最终过一段时间，几分钟之后，人家一定会保证给你把流量充值到位

调用第三方运营商系统接口的操作，很适合用可靠消息最终一致性的方案

（3）最大努力通知方案

跟可靠消息最终一致性方案是类似的，可靠消息最终一致性方案，会保证最终必须要让那个执行成功的，但是最大努力通知方案，不一定保证最终一定会成功，可能会失败，但是他会尽力给你去给你通知那个服务的执行

比较适合那种不太核心一些服务调用的操作，比如说消息服务，充值好了以后发送短信，一般来说肯定是要发出去短信的，但是如果真的不小心发送失败了，发送短信失败了也无所谓的。。。

可以一共最大努力通知方案