云计算的设计模式（三）——补偿交易模式
撤消由一系列的步骤，它们共同限定了终于一致性操作中，假设一个或多个步骤失败运行的工作。依照终于一致性模型，业务实现复杂的业务流程和工作流的云托管的应用程序中非经常见。
背景和问题
在云中运行的应用程序频繁改动数据。
此数据可跨在各种地理位置的所保持的数据源的一个品种传播。
为了避免争用，并提高在分布式环境中，比如这种性能，应用程序不应该试图提供强事务一致性。相反，应用程序应该实现终于一致性。
在该模型中，一个典型的业务操作由一系列的独立的步骤。而正在运行这些步骤的系统状态的总体图可能是不一致的。可是，当操作完毕而且全部步骤都被运行。系统应该又一次变得一致。
注意：
数据的一致性提供了入门为什么分布式事务不能非常好地扩展很多其它的信息，而且巩固了终于一致性模型的原则。
在终于一致性模型的一个显著的挑战是怎样处理失败无可挽回的一步。在这样的情况下，可能须要撤消全部通过的操作中的前面的步骤完毕的工作。然而，数据不能简单地被回滚，由于应用程序的其他并发实例可能已经改变，由于它。即使在数据没有被通过一并发实例变更的情况下。撤消一个步骤可能不是简单地恢复原始状态的问题。可能须要应用不同的业务特定的规则（參见实施例部分中描写叙述的旅行站点）。
假设实现终于一致性操作跨越多个异构数据存储。解开在这种操作中的步骤将须要訪问的每个数据存储区中的转弯。在每个数据存储区运行的工作必须可靠地复原到防止系统其余不一致。
不受实现终于一致性的操作的全部数据可能会在数据库中进行。
在面向服务的架构（SOA）环境中的操作可能会调用一个服务动作，并导致由该服务保持状态的变化。
要撤消的操作，这样的状态的改变也必须是百废待兴。这可能涉及再次调用服务并运行该反转第一的影响还有一个动作。
解决方式
落实补偿事务。在一个补偿事务的步骤必须撤消的原始操作的步骤的影响。
补偿事务可能无法简单地与国家的制度在执行，由于这样的方法可能会覆盖由应用程序的其它并发实例所做的更改開始代替眼下的状态。
相反，它必须是一个聪明的过程中。考虑到并发情况下进行的不论什么工作。这个过程一般是应用程序特定的，由原始操作所执行的工作的性质来驱动。
一种常见的方法来实现的，终于一致的操作。须要补偿的是使用的工作流。因为原来的动作的进行。系统记录每一个步骤，以及怎样通过该步骤完毕的工作能够撤消信息。
假设操作失败，在不论什么时候，在工作流倒卷回通过它已经完毕的步骤。并运行反转每一个步骤的工作。注意。补偿事务可能没有撤消的原始操作的精确镜面相反的顺序工作，而且它可能会运行一些并行撤销步骤。
注意：
这样的方法类似于英雄传奇策略。
这一战略的描写叙述是克莱门斯Vasters的博客在网上提供。
补偿事务本身是一个终于一致的操作。它也可能会失败。该系统应可以恢复补偿事务在故障点并继续。
可能有必要反复发生问题的步骤，所以在补偿事务的步骤应该被定义为幂等的命令。有关幂等的具体信息，请參阅乔纳森·奥利弗的博客幂等模式??。
在某些情况下，可能无法从该已失败，除非通过人工干预的步骤中恢复。
在这样的情况下，系统应发出警报，并提供尽可能多的信息尽可能了解失败的原因。
问题和注意事项
在决定怎样实现这个模式时，请考虑下面几点：
?它可能不easy确定何时在实现终于一致性的动作的步骤已经失败。一个步骤可能不会马上失败，而是它能够阻止。
可能有必要实现某种形式的超时机制。
?补偿逻辑不easy推广。补偿事务是特定于应用程序;它依赖于具有足够的信息。以便可以撤消在一个失败的操作的每一个步骤的效果的应用。
?您应该定义的步骤在补偿事务的幂等命令。这使得，假设补偿事务本身不能被反复的步骤。
?处理中原始操作的步骤。以及所述补偿事务的基础设施。必须是有弹性的。它一定不能失去，以补偿发生问题的步骤所须要的信息，并且它必须可以可靠地监视补偿逻辑的进度。
?一个补偿事务并不一定在系统中返回数据的状态是在原操作的開始。
相反。它补偿了由该成功完毕操作失败之前的步骤中运行的工作。
?在补偿事务中的步骤的顺序并不一定是反射镜相反的，在原来的操作的步骤。比如。一个数据存储能够是不一致比还有一个更敏感，从而撤消更改到该商店中的补偿事务的步骤应首先发生。
?在完毕操作所需的每一个资源放置一个短期的基于超时的锁，并提前获得这些资源，能够帮助添加的可能性。总体活动将取得成功。这项工作应运行的全部资源都被收购之后。
全部操作必须完毕的锁到期之前。
?考虑使用重试逻辑比寻常很多其它的宽容。尽量降低触发补偿事务失败。假设一个操作步骤。实现终于一致性失败，请尝试处理故障为一过性异常，并重复上述步骤。仅仅有放弃操作。假设一个步骤重复或无可挽回地失败，启动补偿事务。
注意：
非常多的挑战和实施补偿事务的问题是一样关心实现终于一致性。请參见注意事项实现了数据的一致性入门终于一致性的很多其它信息。
当使用这个模式
使用此模式仅适用于假设他们失败。必须撤销的操作。
假设可能的话，设计解决方式，避免了须要补偿事务的复杂性（有关具体信息，请參阅数据一致性底漆）。
样例
一个旅游站点。使客户预订行程。
一个单一的行程可包含一系列航班和酒店的。一位顾客旅行从西雅图到伦敦及巴黎能够创建一个行程时，请运行下面步骤：
1.预订一个座位上的F1航班从西雅图飞往伦敦。
2.预订一个座位上的F2航班从伦敦到巴黎。
3.书本占座F3航班从巴黎飞往西雅图。
4.预订的房间在伦敦酒店H1。
5.预订在巴黎一间客房的酒店H2。
这些步骤构成了终于一致的操作，尽管每一步基本上是在自己的权利单独的原子操作。因此，以及在运行这些步骤时，系统还必须记录必要撤消各以防客户决定取消行程步骤计数器的操作。必要运行计数器操作步骤。然后能够作为一个补偿事务如有必要运行。
请注意，在补偿事务中的步骤可能不是原来的步骤全然相反，而且在补偿事务的每一个步骤必须考虑到不论什么特定于业务的逻辑规则。比如。“unbooking取消预订”座位上的飞行可能不是客户有权向支付不论什么款项完毕退款。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveWFuZ3poZW5waW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
图1 - 生成一个补偿事务撤消一个长时间执行的事务预订旅游行程
Note：
它可能会在并行运行的补偿事务的步骤。这取决于你怎样设计每一步的补偿逻辑。
在很多商业解决方式。在单步的故障不总是必要轧制系统背面用补偿事务。比如，具有在旅游站点的情况。客户是无法预订到酒店H1预订航班F1，F2和F3的话。以后。最好是提供客户在同一个城市的房间在不同的酒店而不是取消航班。客户仍然能够选择取消（在这样的情况下，补偿事务执行。并撤消作出关于航班F1，F2和F3中的预订）。但这个决定应该由客户而不是由系统进行。
本文翻译自MSDN：http://msdn.microsoft.com/en-us/library/dn589804.aspx