分布式事务讲解 - 可靠消息服务、最大努力通知

分布式事务系列博客：

【分布式事务讲解 - 2PC、3PC】
【分布式事务讲解 - TX-LNC分布式事务框架（含LCN、TCC、TXC三种模式）】
【分布式事务讲解 - Seata分布式事务框架（AT、TCC两种模式）】
【分布式事务讲解 -消息队列+本地事件表】

可靠消息服务

对于这种分布式事务方案，原理就像是【分布式事务讲解 -消息队列+本地事件表】相似，就是在MQ的前面加了一个【可靠消息服务】，这是一个消息中转服务，作用就像一个中台，对两个不同服务有承上启下的作用。

工作流程图

主要特点

可以说就是在【消息队列+本地事件表】的分布式事务解决方案中加了一个核心服务【可靠消息服务】，在流程图中可以看出，【可靠消息服务分布式事务解决方案】有以下特点：

1. 以【可靠消息服务】为核心服务，对分布式系统之间有承上启下的作用，就像2PC的事务协调者，所以这个服务质量要求很高，如果出现问题一定要有好的应对方案。
2. 提高了吞吐量和并发量，并且响应快，因为这种方案把整条调用链路变成了调用单体的单个功能，这个地方有一个名词叫【软状态】，当一个服务调用支付服务的时候服务直接返回一个软状态【支付中】，后面的逻辑交给后面执行即可，执行完后，状态自然改成【支付成功】最终状态。
3. 比较适合不追求响应速度的系统，因为，整体的步骤还是很多的，数据不能保证时效性，但是最终数据一致性还是没问题的。
4. 4-1和4-2的消息回查操作，主要应对的是2-3失败的情况，2-3失败后，可靠消息服务的本地数据库的消息状态还是【待确认】，这时，需要加一个定时任务，如果这个消息插入时间过了指定时间，状态还是【待确认】，那就执行定时任务执行消息回查操作，避免消息的遗漏。

最大努力通知

对于这种方案，这只是一一种思想，主要应用场景是：我方调用第三方的服务接口，第三方会有这种【最大努力通知】的方案。

例子

大家可以看支付宝的api（各种api里面应该都有这种体现），在调用App支付的接口中，支付宝执行完所有流程会进行多次回调来通知商户，在25小时时间内会通知8次，这就是第三方接口尽最大努力来通知调用者结果，当然支付宝也有8次回调都失败的补偿方案，就是另外开放一个查询接口来查询这个操作的结果。

总结

这两种分布式事务虽然都是文字描述，只是思想类的方案，但是就正式这些能给我们提供更多的灵感。
今后对于分布式事务，从这两种方案我们就能学到很多：

1. 调用分布式服务，使用【软状态】，不仅在系统方面能提高响应速度和并发量，也能带来更好的用户体验。
2. 在开发堆外开放接口时，要想到各种情况的发生，对各种不利情况要有相应的补偿方案，在补偿方案的基础之上，不断完善系统的易用性和智能化。
3. 对于分布式事务来说，补偿机制 和 超时机制 尤为重要：
   1）补偿机制能避免消息漏消费的情况，更能保证数据的最终一致性。
   2）超时机制能避免系统资源的过度消耗，更能保证系统的可用性。
   3）对于分布式事务，【系统的可用性】和【数据的最终一致性】不正是我们所一直追求的A和P吗？