分布式事务，你了解多少？（下）

四、柔性分布式事务

柔性分布式事务是相对刚性分布式事务、是对强一致性的妥协，从而降低对数据库资源的锁定时间，提升系统的性能。柔性分布式事务适合于长事务、高并发，强调最终一致性的场合。常用的实现柔性分布式事务的方式有：TCC模型、Saga模型、基于消息队列的异步模型。

1、TCC（Try-Confirm-Cancel）模型

TCC是一个两阶段提交（2PC）的实现，每一个业务都需要实现Try-Confirm-Cancel三个接口，Try是尝试执行业务，完成所有业务执行前的检查；Confirm是真正执行业务，提交事务，释放资源；Cancel是业务失败的时候回滚业务操作，释放资源。

A账户向B账户转账100元为例，TCC执行步骤如下：

TCC模型的实现是分为2步操作完成一次事务操作，达到最终事务的一致性。

2、Saga模型

起源于1987年Hector Garcia-Molina和Kenneth Salem发表的论文《Sagas》,主要思想是把一个分布式事务拆分为多个本地事务，每一个本地事务都有相应的正常执行方法和异常补偿方法，当任意一个本地事务出错时，都可以通过调用相应的异常补偿方法恢复之前的事务或是继续执行未完成的事务，保证事务的最终一致性。

Saga事务由一系列的sub-transaction Tn及对应的补偿事务Cn组成。

在事务执行过程中，当有任何一个子事务Tj执行失败时，将触发事务补偿，事务的补偿有两种方式。一种是向后补偿，一种是向前补偿。向后补偿指子事务Tj失败后，将把已经执行的子事务Tj-1,Tj-2，……T2，T1的子事务通过执行各自对应的补偿事务Cj-1,Cj-2,……C2，C1（0<j<n）把整个事务回退到执行前的状态。

向前补偿指的是假设每一个子事务最终都会执行成功，则当子事务Tj失败后，将重试保证子事务Tj，Tj+1……Tn-1，Tn都执行成功，达到整个事务的最终一致性。

在实际应用中，并不是所有场景都适合用补偿操作，尤其是向后补偿，比如：发送邮件，这意味着事务补偿后，有可能回不到最初事务开始执行时的状态。

3、基于消息队列的异步模型

基于消息队列的异步模型指的是在核心业务执行完成后，同步的对外发出一个消息，供其他模块消费使用后执行各自的业务。例：电商的下单操作，假如其他的验证都已经完成，满足下单的情况下，给订单表写入订单信息后，系统生成了订单号，订单模块知道把带订单号的订单信息对外发出一个消息（MQ），下单操作就算完成。订单模块发出的MQ供后续的库存扣减，财务收款，仓库生产等业务使用，这里的库存扣减，财务收款和仓库生产属于不同的模块，各自的操作有自己的事务，这就实现了把一个大事务拆分为多个小事务，各自去执行，互不影响，提升系统性能的目的。目前基于消息队列的异步模型，其实现方式有多种，在这里我列出两种进行介绍，一种是业务方提供本地操作成功回查功能，一种是基于本地事务消息表。

1），业务方提供本地操作成功回查功能

整体的流程描述：本地事务执行前，把需要发送的mq消息先发送到MQ服务器上，但该消息属于不能投递的消息，需要有标识标明。当MQ发送方收到MQ服务器返回的收到发送的mq消息的确认后，执行本地事务，根据本地事务的执行结果再向MQ的服务器发送该消息的本地事务执行结果，告诉MQ服务器是把mq消息投递到消费方还是把mq消息回滚丢弃。当MQ服务端超时未收到MQ发送端对mq消息的处理通知（Commit OR Rollback）时，MQ服务端会向MQ发送方进行查询该mq消息的事务状态，以确定该mq消息的处理结果是投递还是丢弃。整体的操作流程图如下：

该方案需要业务方针对每一个事务提供一个回查接口给MQ服务端；同时，MQ服务端还需要有定时任务来检查未投递的消息，并计算消息是否已经超时，如果已经超时需要回查业务方提供的回查事务状态接口以便确认对该消息的处理；该方案对业务的侵入比较大，不利于方案的扩展。目前支持该模式的消息队列有Apache RocketMQ。

2），基于本地事务消息表

该方案指的是主业务数据表和待发送的消息存储表共存于同一个数据库，便于数据写入的时候由一个事务保证，数据写入成功后，事务即成功。此时，需要一个任务来执行对消息表里的消息进行发送到MQ，消息发送MQ成功后，删除消息表里的消息，达到异步处理的目的。比如：还是下单操作，下单完成后，需要通知库存扣减库存，财务进行收款，仓库进行发货等操作，设计时，可以把订单表与订单消息表共同存储到一个数据库里，当订单表写入的时候也同步写订单消息表，2个表同时写成功后，事务才算成功。然后再通过一个任务来查询订单消息表把订单消息表里的消息发送到MQ，当收到MQ的成功回执消息后，再把消息表里的消息进行删除。库存扣减、财务收款、仓库发货等均消费MQ里的该消息来完成各自的业务操作。该方式的操作流程模型如下：

在该方案模型中，当MQ发送方把消息发送后，长时间未收到MQ服务端的结果回执，此时需要再次发送该消息，这导致消息的发送可能会重复多次发送，需要消费方保证处理消息的接口幂等；该方案的优点是对业务的侵入小，核心业务只需要关注把自己业务做完的同时把需要发送的消息写入消息表即可。该方案也是在我们生产中用的比较多的方案之一。

在用消息队列处理的业务场景中，都存在发送方重复多次发送的可能，所以消费方都需要保证业务接口的幂等性，便于重复发送，重复消费时业务的幂等。消息队列在电商、互联网等业务中用的比较广泛，其作用主要体现在业务消峰，解耦业务，异步处理等场合。

至此，把目前学习到的，工作中使用到的分布式事务处理的常用方案及思路总结完毕。如果上述的内容有不正确或不妥之处，欢迎大家留言交流，谢谢！