分布式事务解决方案

2PC

两阶段提交,如果将每一个服务涉及的事务看作一个分支事务,那么一条调用链上涉及的所有分支事务之和就是一个全局事务(TM),我们需要一个事务管理器去管理全局的事务(TM)。

2PC的工作流程: 有A、B两个服务和一个全局事务管理器(TM),A服务需要调用B服务。当用户请求A服务时,A服务向TM注册一个全局事务XID,和一个分支事务id,A服务执行自己的事务,然后又调用了B服务,B服务使用A服务传递的XID也向TM注册了一个分支事务id,然后执行自己的事务,A、B执行完事务后会分别给TM一个执行结果。如果都成功了,TM会给每个分支事务发送commit命令去提交各自的分支事务。如果有任何一个分支事务失败了,那么TM会向其他所有分支事务发送rollback命令进行事务回滚。
Seata框架就是一个2PC解决方案

TCC

TCC是try、confirm、cancel的简称，TCC要求每个分支事务实现三个操作：预处理Try、确认 Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的 操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所 有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel 操作若执行失败，TM会进行重试。

TCC有三个主要的异常:空回滚、幂等、悬挂
空回滚: 没有执行try方法就执行了cancel,这必须要识别出来进行特殊处理
幂等: 资源被重复消费或者事务重复调用了(比如重复支付了),这可以用数据库表来记录执行状态来识别出来
悬挂: 由于网络原因导致cancel比try先调用了,所以try需要识别cancel是否调用过来进行特殊处理
Hmily框架是一个TCC解决方案

可靠性消息最终一致性

从名字可以看出这种解决方案它是用到消息中间件了。

工作流程: 有A、B两个服务,A需要调用B，客户端请求A服务,A服务先执行本地事务并且往本地数据库的消息表 插入一条调用B服务的消息，然后A服务开启一个独立线程去定期扫描消息表,然后发送消息去MQ中,发送成功后再删除这条记录,B服务作为MQ的消费方去接受消息执行本地事务。通过MQ来保证消息的可靠性,这种方案适合周期长对实时性要求不高的事务。
RocketMQ是比较好的分布式事务消息中间件

最大努力通知

这种解决方案的目的是服务提供方尽力将处理结果通知给服务调用方,如果还是没通知到,那么服务调用方主动去查询处理结果。

简单总结

最大努力通知与可靠消息一致性有什么不同？
1、解决方案思想不同
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知 方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接 收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
2、两者的业务应用场景不同
可靠消息一致性 关注的是交易过程的事务一致，以异步的方式完成交易。
最大努力通知 关注的是交易后的通知事务，即将交易结果可靠的通知出去。
3、技术解决方向不同
可靠消息一致性 要解决消息从发出到接收的一致性，即消息发出并且被接收到。
最大努力通知 无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消 息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）

2PC 最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资源。由于其 阻塞机制和最差时间复杂度高， 因此，这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并 发较高以及子事务生命周期较长 (long-running transactions) 的分布式服务中。

如果拿TCC事务的处理流程与2PC两阶段提交做比较，2PC通常都是在跨库的DB层面，而TCC则在应用层面的处 理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使 得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现 try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实 现不同的回滚策略。典型的使用场景：满，登录送优惠券等。

可靠消息最终一致性事务 适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消 息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。典型的使用场景：注 册送积分，登录送优惠券等。

最大努力通知是分布式事务 中要求最低的一种,适用于一些最终一致性时间敏感度低的业务；允许发起通知方处理业 务失败，在接收通知方收到通知后积极进行失败处理，无论发起通知方如何处理结果都会不影响到接收通知方的后 续处理；发起通知方需提供查询执行情况接口，用于接收通知方校对结果。典型的使用场景：银行通知、支付结果 通知等。

2PC、TCC方案适用于对一致性和实时性要求高的场景,可靠性消息最终一致性、最大努力通知方案适用于对一致性和实时性要不高的场景