1.前言

上一篇我们讲到了云计算设计模式之断路器模式  今天我们来聊聊云计算设计模式之Compensating Transaction Pattern（事务修正模式）.关于这个模式的中文翻译，网上有很多，有的翻译成补偿模式，个人认为也没有什么不妥,个人在阅读了官方材料后，结合模式的特点，翻译成事务修正模式.个人认为这个模式是云计算设计模式中，与云环境结合最紧密的模式,也是构建大型分布式应用最佳实践的模式.然而，官方文档中在讨论何时使用这种模式时却说:

Use this pattern only for operations that must be undone if they fail. If possible, design solutions to avoid the complexity of requiring compensating transactions.

仅仅在操作失败时必须回滚的情形下才使用这种模式,否则,就设计一种解决方案来避免使用这种设计模式带来的复杂度.

翻译可能比较生硬，但大致的意思还是很明白的,那就是:不到万不得已,否则不要用这种模式.言外之意,这种模式的复杂度可能带来更为复杂而难以解决的问题.真是如著名的Martin Flower所说的那句名言，使用设计模式最好的方式就是不要使用任何设计模式.这也道出了设计模式使用的原则,不要为了使用模式而使用模式，必须是业务上确实有需要再使用,否则引起的问题比带来的好处还多，那就得不偿失了.

2.背景

事务的概念相信大家都十分清楚了,事务最重要的特性就是:要么不做，要么全做!.在传统的应用中,如果一个操作涉及多个数据表,那么在代码或者数据库层次都可以很好地做事务的控制,.NET和JAVA开发语言都提供了这种机制，数据库也可以使用try/catch结合Trsaction的机制做控制.那么在云环境中有什么不同呢?在云环境中,通常服务都是分布在不同服务器，甚至是不同的地理区域,数据也分布在不同的数据源中,一个操作可能设计到调用多个服务,如果一旦某个步骤调用失败,回滚就非常麻烦了.

回滚不仅仅只是把原来的数据或者服务器状态置为开始状态这么简单，因为这条数据很可能被另外一个进程给修改掉了,如果考虑这种并发的情形，那么数据回滚就变得几乎不可能了;如果你觉得这种情形下事务回滚最麻烦的地方仅此而已，那就大错特错了,最麻烦的是，回滚的时候必须按照任务执行的反方向进行撤销操作，那么回滚的过程也可能会失败,这才是最可怕的地方。考虑到上面所述的情形,我们就很有必要解释事务修正模式了.

3.事务修正模式

官方对于事务修正模式是如何解决这个问题的是这样说的:

A common approach to implementing an eventually consistent operation that requires compensation is to use a workflow. As the original operation proceeds, the system records information about each step and how the work performed by that step can be undone. If the operation fails at any point, the workflow rewinds back through the steps it has completed and performs the work that reverses each step. Note that a compensating transaction might not have to undo the work in the exact mirror-opposite order of the original operation, and it may be possible to perform some of the undo steps in parallel.

实现事务修正模式的通常做法是使用工作流.在原始操作执行时,系统会记录每个执行步骤的信息及该步骤如何回滚的信息.如果事务在任何一步执行失败,工作流将根据这些记录的信息来回滚已经执行的操作。值得注意的是，在回滚的过程中,回滚的步骤不必与原始操作一一镜像对应（与原始步骤相反）,每个回滚步骤都可以并行执行。

官方的说法已经可以非常清除地解释了事务修正模式的基本原理和做法.每一个执行步骤自己负责自己的回滚.并且这些"自治"的回滚是幂等的,也就是说这些单个的回滚是可以retry的,回滚操作无论执行多少次,结果和执行一次都是一样的,这就最大程度地保证了回滚操作失败的可能性。不过万一某个步骤回滚retry也不行呢?那么这时候就需要应用发出警告或者错误给应用管理员,管理员可以根据失败步骤所记录的信息及回滚的操作命令,很轻松地定位问题及手动执行回滚。

4.示例

A travel website enables customers to book itineraries. A single itinerary may comprise a series of flights and hotels. A customer traveling from Seattle to London and then on to Paris could perform the following steps when creating an itinerary:

1. Book a seat on flight F1 from Seattle to London.
2. Book a seat on flight F2 from London to Paris.
3. Book a seat on flight F3 from Paris to Seattle.
4. Reserve a room at hotel H1 in London.
5. Reserve a room at hotel H2 in Paris.

These steps constitute an eventually consistent operation, although each step is essentially a separate atomic action in its own right. Therefore, as well as performing these steps,the system must also record the counter operations necessary to undo each step in case the customer decides to cancel the itinerary.The steps necessary to perform the counter operations can then run as a compensating transaction if necessary.

Notice that the steps in the compensating transaction might not be the exact opposite of the original steps, and the logic in each step in the compensating transaction must take into account any business-specific rules. For example, “unbooking” a seat on a flight might not entitle the customer to a complete refund of any money paid.

在这个例子中也并非所有时候都需要执行回滚.因为事务修正能不用则不用。

In many business solutions, failure of a single step does not always necessitate rolling the system back by using a compensating transaction. For example, if—after having booked flights F1, F2, and F3 in the travel website scenario—the customer is unable to reserve a room at hotel H1, it is preferable to offer the customer a room at a different hotel in the same city rather than cancelling the flights. The customer may still elect to cancel (in which case the compensating transaction runs and undoes the bookings made on flights F1, F2, and F3), but this decision should be made by the customer rather than by the system.

5.相关阅读

The following patterns and guidance may also be relevant when implementing this pattern:

• Data Consistency Primer. The Compensating Transaction pattern is frequently used to undo operations that implement the eventual consistency model. This primer provides more information on the benefits and tradeoffs of eventual consistency.
• Scheduler-Agent-Supervisor Pattern. This pattern describes how to implement resilient systems that perform business operations that utilize distributed services and resources. In some circumstances, it may be necessary to undo the work performed by an operation by using a compensating transaction.
• Retry Pattern. Compensating transactions can be expensive to perform, and it may be possible to minimize their use by implementing an effective policy of retrying failing operations by following the Retry pattern.