彻底搞透分布式一致性( 五 ) _分布式

Seata 提供了多种解决方案来解决分布式事务一致性问题。其中包括 XA 模式、TCC 模式和 SAGA 模式等。

XA 模式是一种基于数据库的事务管理模式，Seata 通过与数据库进行交互来实现分布式事务的一致性。该模式适用于对数据一致性要求比较高的业务场景，如金融、电商等。但是，由于需要与数据库进行交互，因此该模式的性能相对较低;
AT模式（基于应用层的两阶段提交方式）：AT模式实现在应用程序中嵌入事务语义，通过协调维护必要的锁，实现多个业务节点之间跨多个数据库表的事务。适用于关系型数据库的应用场景，如电商下单等。
TCC 模式是一种基于补偿的事务管理模式， Seata 通过预留资源、尝试执行、确认执行和回滚执行四个阶段来实现分布式事务的一致性。该模式适用于对性能要求比较高的业务场景，如游戏、社交等。但是，由于需要进行多次异步通信，因此该模式的复杂度较高;
SAGA 模式是一种基于事件驱动的事务管理模式，Seata 通过将一个大的分布式事务拆分成多个小的本地事务，并通过异步消息传递来实现分布式事务的一致性。该模式适用于对性能和可用性要求比较高的业务场景，如微服务架构下的系统。但是，由于需要进行多次异步通信和状态管理，因此该模式的复杂度也较高。

Seata 还提供了一些重要的功能，如事务日志记录、故障恢复、动态扩展等，使得用户可以更加方便地使用该框架来解决分布式事务一致性问题。同时，Seata 还具有高性能、高可用性和易用性等特点，可以满足各种不同场景下的需求。
【注】感兴趣的话，可以找下 seata 的官方文档。
3.2.2. Context + RollbackSeata 虽好，但中间件的引入将大幅提升系统的复杂性，对于一些不太严谨的场景或者一些运维能力不足的小团队可以自己实现回滚方案。
整体方案如下：

文章插图
图片

创建一个 Context 对象，用于保存整个流程的上下文数据。其中存在一个 List<RollbackEntry> 属性，维护待回滚任务列表；
每操作完一个正向流程，向 Context 中注册一个逆向回调，及 Rollback 任务；
如果

关键事务提交成功， Context 注册的 RollbackEntry 便失去意义；
关键事务提交失败，调用 Context 的 fireFallback 方法进行逆向补偿，fireFallback 方法逆向调用注册的回滚方法，从而恢复业务状态
该方案基于内存实现，存在失灵的情况，不建议使用在严谨的场景。
3.3. 可重试性事务可重试型事务指在业务操作中，如果某些操作由于网络波动等原因导致失败，可以通过重新执行这些操作来达到其预期的结果，例如在发送短信验证码时，由于网络状况不佳而发送失败，可以重新尝试发送，直到发送成功为止。
可重试性事务没有失败，只有成功，哪怕是短暂的失败也会通过不限的重试使其最终达到成功状态。
3.3.1. @Retry@Retry 是 Spring 框架提供的一个注解，用于在方法调用失败时自动进行重试。
通过 @Retry 注解，我们可以定义重试的次数、间隔时间和异常类型等信息，从而实现更可靠的方法调用。
具体来说， @Retry 注解可以通过以下属性来配置：

maxAttempts:最大重试次数；
value:重试间隔时间的数值表示；
fixedDelay:是否固定等待重试间隔时间后再进行下一次尝试；
backoffPolicy:重试间隔时间的退避策略；
allowCoreThreadTimeOut:是否允许在核心线程上进行超时等待；
excludeExceptions:需要排除的异常类型；
excludeClassNames:需要排除的类名列表；
loggerMessage:日志输出格式；
fallbackMethodName:当所有重试都失败后，执行的方法名称；

我们看下具体的使用：