最终一致性分布式解决方案 （7）

概述

最终一致性分布式解决方案并不要求参与事务的各个节点数据时刻保持一直，允许存在中间状态，只要一段时间后，能够达到数据的最终一致状态即可。

业界居于Base理论提出了如下方案
1）TCC解决方案
2）可靠消息最终一致性解决方案
3）最大努力通知解决方案

最终一致性分布式解决方案存在4种典型的服务模式：可查操作、幂等操作、TCC操作、可补偿操作。
1）可查操作:具备全局唯一标识
2）幂等操作:相同参数执行同一方法时，无论执行多少次，都能输出相同结果
3）TCC操作：分3各阶段, Try阶段 、confirm阶段、Cancel 阶段。
4）可补偿操作:数据不对时，可通过某种方式进行业务补偿，使数据达到最终一致性。

优缺点

优点

1）性能较高
2）具备可用性
3）适合高并发

缺点

1）短暂数据不一致
2）数据一致性有较高要求的不适用

TCC解决方案

主要解决跨服务调用场景下的分布式问题，适用于强隔离性、严格一致性要求的业务场景，也适用于执行时间比较短的业务。

一个完整的TCC分布式事务需要包含三个部分：主业务服务、从业务服务、TCC管理器

主业务服务是 TCC 分布式事务的发起方，在下单扣减库存的业务场景中，订单服务是 TCC 分布式事务的发起方，就是主业务服务

从业务服务主要负责提供 TCC 业务操作，是整个业务活动的操作方。从业务活动必须实现 TCC 分布式事务 Try、Confirm 和 Cancel 三个阶段的接口，供主业务服务调用。由于在 TCC 分布式事务的执行过程中，Confirm 阶段的操作和 Cancel 阶段的操作可能会被执行多次，因此需要 Confirm 阶段的操作和 Cancel 阶段的操作保证幂等性

TCC 管理器在整个 TCC 分布式事务的执行过程中，管理并控制着整个事务活动，包括记录并维护 TCC 全局事务的事务状态和每个从业务服务的分支事务状态，并在参与分布式事务的所有分支事务的 Try 阶段都执行成功时，自动调用每个分支事务的 Confirm 阶段的操作，完成分布式事务，同时会在参与分布式事务的某些分支事务执行失败时，自动调用分支事务的 Cancel 操作回滚分布式事务

注意：空回滚、幂等、悬挂问题

Try阶段

不会执行任何业务逻辑，仅做业务的一致性检查和预留相应的资源，这些资源能够和其他操作保存隔离。
例如：订单状态设置为待提交、库存表减去订单商品数后，在预扣除存在字段加上订单商品数。

Confirm阶段

如果Try阶段执行成功，则执行Confirm阶段，订单状态执行为已提交、预扣除存在字段减去订单商品数。

Cancel阶段

如果Try阶段执行失败或抛出异常，则执行Cancel阶段。 订单状态标记为已取消， 库存数加上原先得预留扣除数，实现手动回滚。

总结：整体思想就是先预留必要资源（类似mysql锁住），再根据执行成功与否执行Confirm或Cancel，这两部由TCC管理器分布式框架执行。

TCC 关键技术
在 TCC 事务管理器，也就是 TCC 分布式事务框架的实现过程中，有几项关键技术需要注意。本节就以 Dromara 开源社区的 TCC 分布式事务框架 Hmily 为例，简单介绍实现 TCC 分布式事务框架的关键技术

AOP 切面

实现 TC 分布式事务的第一个核心技术就是 AOP 切面。无论是 TCC 分布式事务的发起者，还是参与者，都需要经过 AOP 切面的处理。通过 AOP 切面拦截具体的业务逻辑，在 AOP 切面中执行事务日志的记录、远程调用等逻辑。Hmily 框架中大量使用了 Spring 的 AOP 切面，处理分布式事务问题

反射技术

实现 TCC 分布式事务的第二个核心技术就是反射技术。TCC 分布式事务中 Confirm 阶段的方法和 Cancel 阶段的方法是通过反射技术调用的。这也就是 Hmily 框架在 Try 阶段的方法上使用注解来指定 Confirm 方法和 Cancel 方法的原因。在 Try 阶段的方法上使用注解指定 Confirm 方法和 Cancel 方法，Hmily 框架会在执行完 Try 方法后，使用反射技术自动调用 Confirm 方法或者 Cancel 方法

持久化技术

实现 TCC 分布式事务的第三个核心技术就是持久化技术。在分布式事务的实现中，所有参与事务的服务都存在数据的持久化操作。在分布式环境中，由于网络的不稳定性，随时都有可能出现调用服务方法失败的情况，在 TCC 分布式事务中，需要保证数据的最终一致性。如果只有一部分服务的请求被正常处理，则另一部分的请求最终也需要被处理，对请求数据持久化是必不可少的。Hmily 框架不仅支持使用 Redis、ZooKeeper、文件、缓存、ETCD、MongoDB 等进行持久化操作，还提供了 SPI 扩展接口，使具体业务能够根据实际需求实现自身的持久化技术

序列化技术

实现 TCC 分布式事务的第四个核心技术就是序列化技术。在分布式环境中，数据的持久化和在网络传输中的传输，都需要序列化技术的支持。Hmily 框架支持的序列化技术包括 JDK 自带的序列化技术、Hessiian 序列化技术、Kyro 序列化技术、MsgPack 序列化技术和 ProtoBuf 序列化技术。另外，Hmily 框架还提供了 SPI 扩展接口，使具体的业务能够根据实际需求实现自身的序列化技术

定时任务

实现 TCC 分布式事务的第五个核心技术就是定时任务。在分布式环境中，由于网络的不稳定性，难免会出现方法调用失败的情况，此时，需要利用定时任务来重试方法的调用操作。Hmily 框架实现了当方法调用失败时，使用定时任务进行重试的机制

动态代理

实现 TCC 分布式事务的第六个核心技术就是动态代理。分布式环境中存在很多远程调用框架，在分布式事务的实现过程中，需要通过动态代理的方式支持多种远程调用框架，在分布式事务的实现过程中，需要通过动态代理的方式支持多种远程调用框架。例如，在 Hmily 框架中通过动态代理支持多种远程调用框架，这些远程调用框架包括 Apache Dubbo、Alibaba Dubbo、BRPC、gRPC、Motan、Sofa-RPC、Spring Cloud、Tars 等

多配置源技术

实现 TCC 分布式事务的第七个核心技术就是多配置源技术，在分布式环境中，为了便于管理各业务系统的配置，往往会几种存储各业务系统的配置，并通过相应的技术快速同步到各业务系统的本地缓存中。由于在真正的业务场景中，会存在不同的配置存储技术，因此实现分布式事务时，需要支持多配置源技术。例如，在 Hmily 框架中，就实现了多种配置源技术，这些配置源包括 Apollo、Consul、ETCD、Loader、Nacos、Zookeeper、本地存储等。另外，Hmily 框架还提供了 SPI 扩展接口，使具体的业务能够根据实际需求实现自身的配置源技术

可靠消息最终一致性解决方案

事务发起方将消息发送给事务参与方，事务参与方就一定能够执行成功，事务最终达到一致状态（MQ）。具备解耦、并发、吞吐量搭的优点

需要实现得服务模式有 可查询操作和幂等操作。

执行流程
1）事务发起方将消息发送给可靠消息服务（MQ）
2）事务参与方从可靠消息服务接收消息

实现方式由两种：基于本地消息表、基于RocketMQ事务消息实现

本地消息表

为了防止在使用消息一致性方案处理分布式事务的过程中出现消息丢失的情况，使用本地事务保证数据业务操作和消息的一致性，也就是通过本地事务，将业务数据和消息数据分别保存到本地数据库的业务数据表和本地消息表中，然后通过定时任务读取本地消息表中的消息数据，将消息发送到消息中间件，等到消息消费者成功接收到消息后，再将本地消息表中的消息删除。这种方式实现的分布式事务就是基于本地消息表的可靠消息最终一致性分布式事务

• 实现原理

基于本地消息表实现的可靠消息最终一致性方案的核心思想是将需要通过分布式系统处理的任务，比如同步数据等操作，通过消息或者日志的形式异步执行，这些消息或者日志可以存储到本地文件中，也可以存储到本地数据库的数据表中，还可以存储到消息中间件中，然后通过一定的业务规则进行重试。这种方案要求各个服务的接口具有幂等性，原理如下图所示：

存放消息的本地消息表和存放数据的业务数据表位于同一个数据库中，这种设计能够保证使用本地事务达到消息和业务数据的一致性，并且引入消息中间件实现多个分支事务之间的最终一致性，整体流程如下：
1)事务发起方向业务数据表成功写入数据后，会向本地消息表发送一条消息数据，因为写业务数据和写消息数据在同一个本地事务中，所以本地事务会保证这条消息数据一定能够正确地写入本地消息表

2） 使用专门的定时任务将本地消息表中的消息写入消息中间件，如果写入成功，会将消息从本地消息表中删除。否则，继续根据一定的规则进行重试操作

3)如果消息根据一定的规则写入消息中间件仍然失败，可以将失败的消息数据转储到 “死信” 队列数据表中，后续进行人工干预，以达到事务最终一致性的目的

4）事务参与方，也就是消息消费者会订阅消息中间件的消息，当接收到消息中间件的消息时，完成本地的业务逻辑

5）事务参与方的本地事务执行成功，则整个分布式事务执行成功。否则，会根据一定的规则进行重试。如果仍然不能成功执行本地事务，则会给事务发起方发送一条事务执行失败的消息，以此来通知事务发起方进行事务回滚

独立消息服务

将消息服务独立出来，并将消息数据从本地消息表独立成单独消息数据库为了保证消息可靠，避免网络不稳定引入：消息确认服务和消息恢复服务
消息确认服务：定期检查事务发起方业务得执行状态和消息库中的数据，不一致则同步发起方的数据
消息恢复服务：定期检查 ，这次是参与方、然后恢复数据。

• 实现原理

独立消息服务实现的分布式事务中有几个核心服务，分别为可靠消息服务、消息确认服务、消息恢复服务和消息中间件，具体流程如下：

1)事务发起方向可靠消息服务成功发送消息后，执行本地事务

2)可靠消息服务接收到事务发起方发送的消息后，将消息存储到消息库中，并将消息记录的状态标记为 “待发送”，并不会马上向消息中间件发送消息。同时，向事务发起方响应消息发送 “已就绪” 的状态

3)当事务发起方的事务执行成功时，事务发起方会向可靠消息服务发送确认消息，否则，发送取消消息

4)当可靠消息服务接收到事务发起方发送过来的确认消息时，会直接将消息库中保存的当前消息删除或标记为 “已删除”

5）消息中间件接收到可靠消息服务发送过来的消息时，会将消息投递给业务参与方，业务参与方接收到消息后，执行本地事务，并将执行结果作为确认消息发送到消息中间件

6）消息中间件将确认结果投递到可靠消息服务，可靠消息服务接收到确认消息后，根据结果状态将消息库中的当前消息记录标记为 “已完成”

7）如果事务发起方向可靠消息服务发送消息失败，会触发消息重试机制。如果重试后仍然失败，则会由消息确认服务定时校对事务发起方的事务状态和消息数据库中当前消息的状态，发现状态不一致时，采用一定的校对规则进行校对

8)如果可靠消息服务向消息中间件发送消息失败，会触发消息重试机制。如果重试后仍然失败，则会由消息恢复服务根据一定的规则定时恢复消息库中的消息数据

注意：本地事务与消息发送的原子性问题（消息确认服务）、事务参与方接收消息的可靠性（消息恢复服务）与幂等性问题（版本、主键）

最大努力通知方法

适用于最终一致性时间敏感度低的场景，并且事务被动方的处理结果不会影响主动方的处理结果，允许消息丢失 ，业务主动方需提供查询接口供被动方查询，需实现可查和幂等操作。

总结：被动方不影响结果，允许消息丢失、主动方提供可查接口。