云计算设计模式(三)——补偿交易模式

云计算设计模式(三)——补偿交易模式


撤消一系列步骤,它们共同限定了最终一致性操作中,如果一个或多个步骤失败执行的工作。按照最终一致性模型,业务实现复杂的业务流程和工作流的云托管的应用程序中很常见


背景和问题



在云中运行的应用程序频繁修改数据数据可跨在各种地理位置的所保持的数据一个品种传播。为了避免争用,并提高在分布式环境中,例如这样的性能,应用程序不应该试图提供事务一致性。相反,应用程序应该实现最终一致性该模型中,一个典型的业务操作由一系列独立的步骤。正在执行这些步骤系统状态整体图可能是不一致的,但是,当操作完成并且所有步骤都被执行,系统应该重新变得一致。



注意:

数据的一致性提供了入门为什么分布式事务不能很好地扩展更多的信息并且巩固最终一致性模型的原则



最终一致性模型的一个显著的挑战是如何处理失败无可挽回的一步。这种情况下,可能需要撤消所有通过的操作中的前面的步骤完成的工作然而,数据不能简单地被回滚,因为应用程序其它并发实例可能已经改变,因为即使在数据没有被通过并发实例变更的情况下,撤消一个步骤可能不是简单地恢复原始状态的问题。可能需要应用不同的业务特定的规则参见实施例部分中描述的旅行网站)。

如果实现最终一致性操作跨越多个异构数据存储,解开这样的操作中的步骤将需要访问的每个数据存储区中的转弯。在每一个数据存储区执行的工作必须可靠地复原防止系统其余不一致。

不受实现最终一致性的操作的所有数据可能会在数据库中进行。面向服务的架构SOA)环境中的操作可能会调用一个服务动作导致由该服务保持状态的变化要撤消操作,这种状态的改变也必须是百废待兴这可能涉及再次调用服务执行该反转第一的影响另一个动作

 

解决方案



落实补偿事务一个补偿事务的步骤必须撤消原始操作的步骤的影响。补偿事务可能无法简单地与国家制度运行,因为这种方法可能会覆盖应用程序的其他并发实例所做的更改开始取代目前的状态。相反,它必须是一个聪明的过程中,考虑到并发情况下进行的任何工作这个过程通常是应用程序特定的原始操作所执行的工作的性质来驱动。

一种常见的方法实现,最终一致的操作,需要补偿的是使用的工作流。由于原来的动作的进行,系统记录每个步骤,以及如何通过步骤完成的工作可以撤消信息如果操作失败,在任何时候在工作流倒卷回通过它已经完成的步骤,并执行反转每个步骤的工作。注意,补偿事务可能没有撤消原始操作的精确镜面相反的顺序工作并且它可能会执行一些并行撤销步骤



注意:

这种方法类似于英雄传奇策略。这一战略的描述克莱门斯Vasters的博客在网上提供。



补偿事务本身是一个最终一致的操作,它也可能会失败该系统应能够恢复补偿事务故障点并继续。可能有必要重复发生故障的步骤,所以在补偿事务的步骤应该被定义为幂等的命令。有关幂等的详细信息,请参阅乔纳森·奥利弗的博客幂等模式​​。

某些情况下,可能无法从该已失败,除非通过人工干预的步骤中恢复。在这种情况下,系统应发出警报,并提供尽可能多的信息尽可能了解失败的原因。

 

问题和注意事项



在决定如何实现这个模式时,请考虑以下几点
•它可能不容易确定何时在实现最终一致性的动作的步骤已经失败。一个步骤可能不会立即失败而是它可以阻止可能有必要实现某种形式超时机制
补偿逻辑不容易推广补偿事务特定于应用程序;它依赖于具有足够的信息,以便能够撤消一个失败的操作的每个步骤的效果应用
•您应该定义的步骤补偿事务幂等命令。这使得,如果补偿事务本身不能被重复的步骤。
处理原始操作的步骤,以及所述补偿事务基础设施必须是有弹性的。一定不能失去,以补偿发生故障的步骤所需要的信息,而且它必须能够可靠地监视补偿逻辑的进度。
•一个补偿事务并不一定在系统中返回数据的状态操作的开始相反,它补偿了成功完成操作失败之前步骤中执行的工作。
补偿事务中的步骤的顺序并不一定是反射镜相反,在原来的操作的步骤。例如一个数据存储可以是不一致比另一个更敏感,从而撤消更改该商店中的补偿事务的步骤应首先发生
完成操作所需的每个资源放置一个短期的基于超时的锁,并提前获得这些资源可以帮助增加的可能性,整体活动将取得成功。这项工作应执行的所有资源被收购之后。所有操作必须完成的锁到期之前
•考虑使用重试逻辑平常更多的宽容,尽量减少触发补偿事务失败如果一个操作步骤,实现最终一致性失败,请尝试处理故障为一过性异常,并重复上述步骤只有放弃操作,如果一个步骤反复无可挽回地失败,启动补偿事务



 注意:

很多挑战和实施补偿事务问题是一样关心实现最终一致性请参见注意事项实现数据的一致性入门最终一致性的更多信息。


使用这个模式



使用此模式仅适用于如果他们失败,必须撤销的操作如果可能的话设计解决方案,避免了需要补偿事务的复杂性(有关详细信息,请参阅数据一致性底漆
  
例子

一个旅游网站,使客户预订行程。一个单一的行程可包括一系列航班和酒店一位顾客旅行从西雅图到伦敦及巴黎可以创建一个行程时,请执行以下步骤
1.预订一个座位上的F1航班从西雅图飞往伦敦
2.预订一个座位上的F2航班从伦敦到巴黎
3.书本占座F3航班从巴黎飞往西雅图
4.预订的房间伦敦酒店H1
5.预订在巴黎间客房的酒店H2

这些步骤构成了最终一致的操作,虽然每一步基本上是在自己的权利单独的原子操作因此以及在执行这些步骤时,系统还必须记录必要撤消以防客户决定取消行程步骤计数器的操作。必要执行计数器操作步骤,然后可以作为一个补偿事务如有必要运行。

请注意,在补偿事务中的步骤可能不是原来的步骤完全相反并且在补偿事务的每个步骤必须考虑到任何特定于业务的逻辑规则例如unbooking取消预订座位上的飞行可能不是客户有权支付任何款项完成退款

云计算设计模式(三)——补偿交易模式_第1张图片

图1 - 生成一个补偿事务撤消一个长时间运行的事务预订旅游行程

Note

它可能会并行执行补偿事务的步骤这取决于你如何设计每一步补偿逻辑。



许多商业解决方案在单步的故障不总是必要轧制系统背面补偿事务例如,具有旅游网站的情况客户是无法预订到酒店H1预订航班F1F2和F3的话以后最好是提供客户在同一个城市的房间不同的酒店而不是取消航班。客户仍然可以选择取消这种情况下,补偿事务运行,并撤消作出关于航班F1,F2F3中的预订),但这个决定应该由客户而不是由系统进行。

本文翻译自MSDN:http://msdn.microsoft.com/en-us/library/dn589804.aspx

你可能感兴趣的:(云计算,设计,设计模式,云计算设计模式)