补偿事务

含义：

为了保证业务上一致性（或者说努力将业务流程执行完成，达到最终状态）。如果业务流中某个步骤失败了（即执行不下去的时候），那么需要启动业务补偿。要么回滚到以前的服务调用（revert/cancel），要么不断重试保证所有的步骤都成功（retry）。

ACID(酸) 和 BASE(碱)

ACID:

• 原子性：整个事务中的所有操作，要么全部完成，要么全部失败，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

• 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

• 隔离性：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时中间某一时刻的数据。两个事务不会发生交互。

• 持久性：在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。

• 强调 C BASE:

• Basic Availability：基本可用。这意味着，系统可以出现暂时不可用的状态，而后面会快速恢复。

• Soft-state：软状态。它是我们前面的“有状态”和“无状态”的服务的一种中间状态。也就是说，为了提高性能，我们可以让服务暂时保存一些状态或数据，这些状态和数据不是强一致性的。

• Eventual Consistency：最终一致性，系统在一个短暂的时间段内是不一致的，但最终整个系统看到的数据是一致的。

• 强调 A

BASE 系统是允许或是容忍系统出现暂时性问题的，使得系统就能更有弹力。在分布式系统的世界里，故障是不可避免的，将故障处理当成'功能写入代码中，这就是 Design for Failure。

BASE 系统保证在短时间内，就算是有数据不同步的风险，也应该允许新的交易可以发生，而后在业务上将可能出现问题的事务给处理掉，以保证最终的一致性。

业务的补偿：

业务的事务补偿通常需要一个工作流引擎。e.g. Airflow。 该引擎可以把把各式各样的服务给串联在一起，通过在工作流上做相应的业务补偿，整个过程设计成为最终一致性的。

补偿设计要点：

• 起始状态定义。描述最终需要达到什么状态，如果不满足，需要回退到哪个状态。
• 状态拟合。系统可以通过一系列操作达到最终状态，如果不能达到，则通过回滚方式的补偿机制。
• 对于已经完成的事务进行整体修改，可以考虑成一个修改事务
• 服务方支持幂等性，并且在上游有重试机制。
• 通过高可用、稳定的工作流引擎来集中管理各个流程的状态。
• 设计好业务的反向补偿流程。即undo
• 补偿流程和业务强相关，基本无法通用。