补偿交易模式

最新推荐文章于 2022-05-15 12:06:15 发布

Wang-Junchao

最新推荐文章于 2022-05-15 12:06:15 发布

阅读量1k

点赞数

分类专栏：设计模式文章标签：分布式云服务项目架构

原文链接：https://docs.microsoft.com/en-us/previous-versions/msp-n-p/dn589804%28v%3dpandp.10%29

版权

设计模式专栏收录该内容

37 篇文章 1 订阅

订阅专栏

【博文目录>>>】

补偿交易模式

如果一个或多个步骤失败，则撤消由一系列执行的工作的步骤组成，这些步骤一起定义最终一致的操作。遵循最终一致性模型的操作通常可在实现复杂业务流程和工作流的云托管应用程序中找到。

背景与问题

运行在云中的应用程序经常修改数据。这些数据可以分布在各种地理位置的各种数据源上。为了在这样的分布式环境中避免争用和提高性能，应用程序不应该试图提供强大的事务一致性。相反，应用程序应该实现最终一致性。在该模型中，典型的业务操作由一系列自治步骤组成。在执行这些步骤时，系统状态的总体视图可能是不一致的，但是当操作完成并且所有步骤都已经执行时，系统应该再次变得一致。

注
这个数据一致性入门提供有关分布式事务不能很好地扩展的更多信息，以及支持最终一致性模型的原则。

在最终一致性模型中，一个重大的挑战是如何处理一个已经无法恢复的步骤。在这种情况下，可能需要撤消操作中前面步骤完成的所有工作。但是，不能简单地回滚数据，因为应用程序的其他并发实例可能已经更改了它。即使在数据未被并发实例更改的情况下，取消步骤也不可能只是恢复原始状态的问题。可能有必要应用各种特定于业务的规则(参见示例部分中描述的旅游网站)。

如果实现最终一致性的操作跨越多个异构数据存储，则取消此操作中的步骤将需要依次访问每个数据存储。必须可靠地撤消在每个数据存储中执行的工作，以防止系统保持不一致。

并非所有受实现最终一致性的操作影响的数据都可能保存在数据库中。在面向服务的体系结构(ServiceOrientedArchitecture，SOA)环境中，操作可能会调用服务中的操作，并导致该服务保持的状态发生变化。若要撤消操作，还必须撤消此状态更改。这可能涉及再次调用服务，并执行另一个逆转第一个服务效果的操作。

解决方案

实现补偿事务。补偿事务中的步骤必须撤消原始操作中步骤的效果。补偿事务可能无法简单地将当前状态替换为系统在操作开始时所处的状态，因为这种方法可能会覆盖应用程序的其他并发实例所做的更改。相反，它必须是一个考虑到并发实例所做的任何工作的智能过程。这个过程通常是特定于应用程序的，由原始操作所执行的工作性质驱动。

实现需要补偿的最终一致操作的一种常见方法是使用工作流。随着原始操作的进行，系统记录关于每个步骤的信息，以及如何撤消该步骤所执行的工作。如果操作在任何时候失败，工作流将在它完成的步骤中回滚，并执行逆转每个步骤的工作。请注意，补偿事务可能不必按照与原始操作完全相反的顺序撤消工作，并且可能并行执行一些撤消步骤。

注
这种方法类似于Sagas战略。有关此策略的说明可在克莱门斯·维斯特斯的博客上找到.

补偿事务本身就是一个最终一致的操作，它也可能失败。系统应该能够在故障点恢复补偿事务并继续进行。可能需要重复一个失败的步骤，因此补偿事务中的步骤应该定义为幂等命令。有关幂等性的详细信息，请参阅幂等模式乔纳森·奥利弗的博客上。

在某些情况下，除非通过人工干预，否则可能无法从失败的步骤中恢复。在这种情况下，系统应该发出警报，并尽可能多地提供有关故障原因的信息。

问题和思考

在决定如何实现此模式时，请考虑以下几点：

要确定实现最终一致性的操作中的步骤何时失败，可能并不容易。一个步骤可能不会立即失败，但它可能会阻止。可能有必要实施某种形式的超时机制。
补偿逻辑不易推广。补偿事务是特定于应用程序的；它依赖于具有足够信息的应用程序能够撤消失败操作中每个步骤的影响。
您应该将补偿事务中的步骤定义为幂等命令。如果补偿事务本身失败，则可以重复这些步骤。
处理原始操作中的步骤和补偿事务的基础结构必须具有弹性。它不能丢失补偿失败步骤所需的信息，并且必须能够可靠地监视补偿逻辑的进展。
补偿事务不一定将系统中的数据返回到原始操作开始时所处的状态。相反，它补偿操作失败前成功完成的步骤所执行的工作。
补偿事务中步骤的顺序不一定是与原始操作中的步骤相反的镜像。例如，一个数据存储可能比另一个数据存储更敏感，因此应该首先执行补偿事务中撤消对此存储的更改的步骤。
在每个完成操作所需的资源上放置一个基于短期超时的锁，并提前获得这些资源，可以帮助增加整个活动成功的可能性。只有在获得所有资源之后才能完成这项工作。所有操作必须在锁过期前完成。
考虑使用比通常更宽容的重试逻辑来最小化触发补偿事务的失败。如果操作中实现最终一致性的步骤失败，请尝试将故障作为瞬态异常处理并重复该步骤。只有在步骤重复失败或无法恢复时，才中止操作并启动补偿事务。

注
实施补偿交易的许多挑战和问题与实现最终一致性的挑战和问题相同。有关实现最终一致性的考虑事项，请参见数据一致性入门了解更多信息。

何时使用此模式

此模式仅用于如果操作失败必须撤消的操作。如果可能，设计解决方案以避免需要补偿事务的复杂性(有关更多信息，请参见数据一致性入门).

例子

旅游网站使客户能够预订行程。一个单一的行程可以包括一系列的航班和酒店。客户从西雅图到伦敦，然后再到巴黎，在创建行程时可以执行以下步骤：

预订从西雅图到伦敦的F1航班的座位。
预订从伦敦到巴黎的F2次航班的座位。
预订从巴黎到西雅图的F3航班的座位。
在伦敦H1酒店预订房间。
预订巴黎H2酒店的房间。

这些步骤构成了最终一致的操作，尽管每个步骤本身本质上都是一个单独的原子操作。因此，在执行这些步骤的同时，系统还必须记录撤销每个步骤所需的计数器操作，以防客户决定取消行程。如果有必要，执行计数器操作所需的步骤可以作为补偿事务运行。

注意，补偿事务中的步骤可能不是与原始步骤完全相反的步骤，补偿事务中每个步骤中的逻辑必须考虑到任何特定于业务的规则。例如，“取消预订”航班上的座位可能不能使顾客获得全额退款。

在这里插入图片描述
图1-生成补偿事务以撤消长期运行的事务以预订旅行日程

注
补偿事务中的步骤可能并行执行，这取决于您如何为每个步骤设计补偿逻辑。

在许多业务解决方案中，单个步骤的失败并不总是需要使用补偿事务来回滚系统。例如，如果在旅行网站场景中预订了F1、F2和F3航班后，客户无法预订H1酒店的房间，则最好在同一城市的另一家酒店为客户提供房间，而不是取消航班。客户仍然可以选择取消(在这种情况下，补偿事务将运行并取消对F1、F2和F3航班的预订)，但此决定应由客户而不是由系统作出。