撤消由一系列步骤，它们共同限定了最终一致性操作中，如果一个或多个步骤失败执行的工作。按照最终一致性模型，业务实现复杂的业务流程和工作流的云托管的应用程序中很常见。
在云中运行的应用程序频繁修改数据。此数据可跨在各种地理位置的所保持的数据源的一个品种传播。为了避免争用，并提高在分布式环境中，例如这样的性能，应用程序不应该试图提供强事务一致性。相反，应用程序应该实现最终一致性。在该模型中，一个典型的业务操作由一系列的独立的步骤。而正在执行这些步骤的系统状态的整体图可能是不一致的，但是，当操作完成并且所有步骤都被执行，系统应该重新变得一致。
注意
数据的一致性提供了入门为什么分布式事务不能很好地扩展更多的信息，并且巩固了最终一致性模型的原则。
在最终一致性模型的一个显著的挑战是如何处理失败无可挽回的一步。在这种情况下，可能需要撤消所有通过的操作中的前面的步骤完成的工作。然而，数据不能简单地被回滚，因为应用程序的其它并发实例可能已经改变，因为它。即使在数据没有被通过一并发实例变更的情况下，撤消一个步骤可能不是简单地恢复原始状态的问题。可能需要应用不同的业务特定的规则（参见实施例部分中描述的旅行网站）。
如果实现最终一致性操作跨越多个异构数据存储，解开在这样的操作中的步骤将需要访问的每个数据存储区中的转弯。在每一个数据存储区执行的工作必须可靠地复原到防止系统其余不一致。
不受实现最终一致性的操作的所有数据可能会在数据库中进行。在面向服务的架构（SOA）环境中的操作可能会调用一个服务动作，并导致由该服务保持状态的变化。要撤消的操作，这种状态的改变也必须是百废待兴。这可能涉及再次调用服务并执行该反转第一的影响另一个动作。
落实补偿事务。在一个补偿事务的步骤必须撤消的原始操作的步骤的影响。补偿事务可能无法简单地与国家的制度在运行，因为这种方法可能会覆盖由应用程序的其他并发实例所做的更改开始取代目前的状态。相反，它必须是一个聪明的过程中，考虑到并发情况下进行的任何工作。这个过程通常是应用程序特定的，由原始操作所执行的工作的性质来驱动。
一种常见的方法来实现的，最终一致的操作，需要补偿的是使用的工作流。由于原来的动作的进行，系统记录每个步骤，以及如何通过该步骤完成的工作可以撤消信息。如果操作失败，在任何时候，在工作流倒卷回通过它已经完成的步骤，并执行反转每个步骤的工作。注意，补偿事务可能没有撤消的原始操作的精确镜面相反的顺序工作，并且它可能会执行一些并行撤销步骤。
注意
这种方法类似于英雄传奇策略。这一战略的描述是克莱门斯 Vasters 的博客在网上提供。
补偿事务本身是一个最终一致的操作，它也可能会失败。该系统应能够恢复补偿事务在故障点并继续。可能有必要重复发生故障的步骤，所以在补偿事务的步骤应该被定义为幂等的命令。有关幂等的详细信息，请参阅乔纳森·奥利弗的博客幂等模式。
在某些情况下，可能无法从该已失败，除非通过人工干预的步骤中恢复。在这种情况下，系统应发出警报，并提供尽可能多的信息尽可能了解失败的原因。
在决定如何实现这个模式时，请考虑以下几点：
注意： 很多的挑战和实施补偿事务的问题是一样关心实现最终一致性。请参见注意事项实现了数据的一致性入门最终一致性的更多信息。
使用此模式仅适用于如果他们失败，必须撤销的操作。如果可能的话，设计解决方案，避免了需要补偿事务的复杂性（有关详细信息，请参阅数据一致性底漆）。
一个旅游网站，使客户预订行程。一个单一的行程可包括一系列航班和酒店的。一位顾客旅行从西雅图到伦敦及巴黎可以创建一个行程时，请执行以下步骤：
1.预订一个座位上的 F1 航班从西雅图飞往伦敦。
2.预订一个座位上的 F2 航班从伦敦到巴黎。
3.书本占座 F3 航班从巴黎飞往西雅图。
4.预订的房间在伦敦酒店 H1。
5.预订在巴黎一间客房的酒店 H2。
这些步骤构成了最终一致的操作，虽然每一步基本上是在自己的权利单独的原子操作。因此，以及在执行这些步骤时，系统还必须记录必要撤消各以防客户决定取消行程步骤计数器的操作。必要执行计数器操作步骤，然后可以作为一个补偿事务如有必要运行。
请注意，在补偿事务中的步骤可能不是原来的步骤完全相反，并且在补偿事务的每个步骤必须考虑到任何特定于业务的逻辑规则。例如，“unbooking 取消预订”座位上的飞行可能不是客户有权向支付任何款项完成退款。
它可能会在并行执行的补偿事务的步骤，这取决于你如何设计每一步的补偿逻辑。
在许多商业解决方案，在单步的故障不总是必要轧制系统背面用补偿事务。例如，具有在旅游网站的情况，客户是无法预订到酒店H1预订航班 F1，F2 和 F3 的话，以后，最好是提供客户在同一个城市的房间在不同的酒店而不是取消航班。客户仍然可以选择取消（在这种情况下，补偿事务运行，并撤消作出关于航班 F1，F2 和 F3中的预订），但这个决定应该由客户而不是由系统进行。
