分布式事务 - 三种常见的解决方案

基于CAP理论我们可以知道，对于数据一致性问题有AP和CP两种方案，但是在电商领域等互联网场景下，基于CP的强一致性方案在数据库性能和系统处理能力上会存在一定的瓶颈。所以在互联网场景中更多采用柔性事务，所谓的柔性事务是遵循BASE理论来实现的事务模型，它有两个特性：基本可用、柔性状态，下面我们主要基于柔性事务模型来分析互联网产品中分布式事务的常见解决方案。

TCC补偿型方案

TCC (Try-Confirm-Cancel)是一种比较成熟的分布式数据一致性解决方案，它实际上是把一个完整的业务拆分为如下三个步骤。

• Try：这个阶段主要是对数据的校验或者资源的预留。

• Confirm：确认真正执行的任务，只操作Try阶段预留的资源。

• Cancel：取消执行，释放Try阶段预留的资源。

其实TCC是一种两阶段提交的思想，第一阶段通过Try进行准备工作，第二阶段Confirm/Cancel表示Try阶段操作的确认和回滚。在分布式事务场景中，每个服务实现TCC之后，就作为其中的一个资源，参与到整个分布式事务中。然后主业务服务在第一阶段中分别调用所有TCC服务的Try方法。最后根据第一阶段的执行情况来决定对第二阶段的Confirm或者Cancel。

TCC执行流程如下图所示：





对于TCC的工作机制，我们举一个比较简单的例子。在一个理财App中，用户通过账户余额购买一个理财产品，这里涉及两个事务操作：

• 在账户服务中，对用户账户余额进行扣减。

• 在理财产品服务中，对指定理财产品可申购金额进行扣减。

这两个事务操作在微服务架构下分别对应的是两个不同的微服务，以及独立的数据库操作，在TCC的工作机制中，首先针对账户服务和理财产品服务分别提供Try、Confirm和Cancel三个方法。

• 在账户服务的Try方法中对实际申购金额进行冻结，Confirm方法把Try方法冻结的资金进行实际的扣减，Cancel方法把Try方法冻结的资金进行解冻。

• 理财产品服务的Try方法中将本次申购的部分额度进行冻结，Confirm方法把Try方法冻结的额度进行实际扣减，Cancel方法把Try方法中冻结的额度进行释放。

在一个主业务方法中，分别调用这两个服务对外提供的处理方法（资金扣减、理财产品可申购额度扣减），这两个服务处理实际业务时，会先调用Try方法来做资源预留，如果这两个方法处理都正常，TCC事务协调器就会调用Confirm方法对预留资源进行实际应用。否则TCC事务协调器一旦感知到任何一个服务的Try方法处理失败，就会调用各个服务的Cancel方法进行回滚，从而保证数据的一致性。

在一些特殊情况下，比如理财产品服务宕机或者出现异常，导致该服务并没有收到TCC事务协调器的Cancel或者Confirm请求，怎么办呢？没关系，TCC事务框架会记录一些分布式事务的操作日志，保存分布式事务运行的各个阶段和状态。TCC事务协调器会根据操作日志来进行重试，以达到数据的最终一致性。

需要注意的是，TCC服务支持接口调用失败发起重试，所以TCC暴露的接口都需要满足幂等性。

基于可靠性消息的最终一致性方案

基于可靠性消息的最终一致性是互联网公司比较常用的分布式数据一致性解决方案，它主要利用消息中间件（Kafka、RocketMQ或者RabbitMQ）的可靠性机制来实现数据一致性的投递。

以电商平台的支付场景为例，用户完成订单的支付后不需要同步等待支付结果，可以继续做其他事情。但对于系统来说，大部分是在发起支付之后，等到第三方支付平台提供异步支付结果通知，再根据结果来设置该订单的支付状态。并且如果是支付成功的状态，大部分电商平台基于营销策略还会给账户增加一定的积分奖励。所以，当系统接收到第三方返回的支付结果时，需要更新支付服务的支付状态，以及更新账户服务的积分余额，这里就涉及两个服务的数据一致性问题。从这个场景中可以发现这里的数据一致性并不要求实时性，所以可以采用基于可靠性消息的最终一致性方案来保证支付服务和账户服务的数据一致性。

如下图所示，支付服务收到支付结果通知后，先更新支付订单的状态，再发送一条消息到分布式消息队列中，账户服务会监听到指定队列的消息，并进行相应的处理，完成数据的同步。





在上图的解决方案中，我们可以发现一些问题，就是支付服务的本地事务与发送消息这个操作的原子性问题，具体描述如下：

• 先发送消息，再执行数据库事务，这种情况下可能出现消息发送成功但是本地事务更新失败的情况，仍然会导致数据不一致的问题。

• 先执行数据库事务操作，再发送消息，在这种情况下可能会出现MQ响应时间超时导致异常，从而将本地事务回滚，但消息可能已经发送成功了，也会存在数据不一致的问题。

以上问题也有很多成熟的解决方案，以RocketMQ为例，它提供了事务消息模型，如下图所示，具体的执行逻辑如下：

• 生产者发送一个事务消息到消息队列上，消息队列只记录这条消息的数据，此时消费者无法消费这条消息。

• 生产者执行具体的业务逻辑，完成本地事务的操作。

• 接着生产者根据本地事务的执行结果发送一条确认消息给消息队列服务器，如果本地事务执行成功，则发送一个Commit消息，表示在第一步中发送的消息可以被消费；否则，消息队列服务器会把第一步存储的消息删除。

• 如果生产者在执行本地事务的过程中因为某些情况一直未给消息队列服务器发送确认，那么消息队列服务器会定时主动回查生产者获取本地事务的执行结果，然后根据回查结果来决定这条消息是否需要投递给消费者。

• 消息队列服务器上存储的消息被生产者确认之后，消费者就可以消费这条消息，消息消费完成之后，发送一个确认标识给消息队列服务器，表示该消息投递成功。





在RocketMQ事务消息模型中，事务是由生产者来完成的，消费者不需要考虑，因为消息队列可靠性投递机制的存在，如果消费者没有签收该消息，那么消息队列服务器会重复投递，从而实现生产者的本地数据和消费者的本地数据在消息队列的机制下达到最终一致。

不难发现，在RocketMQ的事务消息模型中最核心的机制应该是事务回查，实际上查询模式在很多类似的场景中都可以应用。在分布式系统中，由于网络通信的存在，服务之间的远程通信除成功和失败两种结果外，还存在一种未知状态，比如网络超时。服务提供者可以提供一个查询接口向外部输出操作的执行状态，服务调用方可以通过调用该接口得知之前操作的结果并进行相应处理。

最大努力通知型

最大努力通知型和基于可靠性消息的最终一致性方案的实现是类似的，它是一种比较简单得到柔性事务解决方案，也比较适用于对数据一致性要求不高的场景，最经典的使用场景是支付宝支付结果通知，实现流程如下图所示：





下面站在商户的角度来分析最大努力通知型的处理过程：

• 商户先创建一个支付订单，然后调用支付宝发起支付请求。

• 支付宝唤醒支付页面完成支付操作，支付宝同样会针对该商户创建一个支付交易，并且根据用户的支付结果记录支付状态。

• 支付完成后触发一个回调通知给商户，商户收到该通知后，根据结果修改本地支付订单的状态，并且返回一个处理状态给支付宝。

• 针对这个订单，在理想状态下支付宝的交易状态和商户的交易状态会通知完成后达到最终一致。但是由于网络的不确定性，支付结果通知可能会失败或者丢失，导致商户端的支付订单的状态是未知的。所以最大努力通知型的作用就体现了，如果商户端在收到支付结果通知后没有返回一个"SUCCESS"状态码，那么这个支付结果回调请求会以衰减重试机制（逐步拉大通知的间隔）继续触发，比如1min、5min、10min、30min…直到达到最大通知次数。如果达到指定次数后商户还没有返回确定状态，怎么处理呢？

• 支付宝提供了一个交易结果查询接口，可以根据这个支付订单号去支付宝查询支付状态，然后根据返回的结果来更新商户的支付订单状态，这个过程可以通过定时器来触发，也可以通过人工对账来触发。

从上面的分析可以发现，所谓的最大努力通知，就是在商户端如果没有返回一个消息确认时，支付宝会不断地进行重试，直到收到一个消息确认或者达到最大重试次数。

不难发现它的实现机制和事务消息模型的消费者消费模型类似，在消费者没有向消息中间件服务器发送确认之前，这个消息会被重复投递，确保消息的可靠性消费。