12.30 Day 15 - 弹力设计篇之“补偿事务”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 15 天，也是我第 15 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《弹力设计篇之“补偿事务”》的文章。

关键词总结：ACID、BASE、原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）、基本可用性（Basic Availability）、Soft-state（软状态）、Eventual Consistency（最终一致性）、业务补偿、靠谱的业务补偿机制、业务补偿的设计重点。

 

所学总结：

 

ACID（强一致性）

资金交易的过程就是不可拆分的源自操作，因此才能保证数据库中的金额不会出现差错。分布式系统的 CAP 理论无法满足 ACID 的要求。

原子性 / Atomicity

在事务的执行过程中如果发生错误，那么事务之内的所有操作都将不会成立，任何在执行过程中对数据库所做的改变都将被还原至事务开始之前。

一致性 / Consistency

数据库数据的一致性完整约束在事务开始之前到结束之后都没有被破坏。

隔离性 / Isolation

多个事务之间的操作不会被任何一方所看到，也不会被任何一方所干扰。两个事务从产生到开始执行直至结束的过程是完全独立的。

持久性 / Durability

事务过程中对数据所做的改动在事务结束之后将被永久保存至存储中，不会被回滚至事务之前没有该数据的状态。

 

BASE（最终一致性）

由于 ACID 的要求过于严格，无法在高性能的分布式系统中应用该理论。所以，一个比较宽松的适合在高并发环境下应用的 BASE 理论就应运而生了。BASE 不要求系统能做到强一致性，它只要求系统能做到最终一致性即可。BASE 理论所实现的系统允许出现短暂的问题。它所实现的系统也允许操作过程中数据不一致的情况，只要最终看到的数据是一致的即可。

基本可用性 / Basic Availability

服务偶尔出现不可用的状态是可以接受的，只要能以最快的速度让其恢复即可。

软状态 / Soft-state

为了提高服务的性能，我们有时候会让其保存一些临时的状态和数据，只要能保证这些状态和数据有在更新就行了，不需要它们每时每刻都处在最新的状态。这个状态是处在有状态和无状态服务中间的一个状态。

最终一致性 / Eventual Consistency

系统间的数据不会每时每刻都保持一致，但它们总会变成一致的。
 

CAP 中的 ACID（酸）和 BASE（碱）

• ACID：代表了 CAP 理论中的 C（Consistency）；
• BASE：代表了 CAP 理论中的 A（Availability）。
   

业务补偿

我们在很多情况下都没办法做到 ACID，例如调用第三方系统的操作。业务的事务补偿处理过程一般是通过工作流引擎来完成的。需要将服务做成幂等性（无论怎么操作，其都不会产生意想不到的结果），可以进行无数次的尝试，直至服务完成工作。如果只能完成部分工作，那么就需要将服务操作过程中所做的改变恢复至操作开始之前，重新开始尝试。

靠谱的业务补偿机制

1. 清晰地描述服务要达到的目标，如果达不到目标，那要回退至哪一个步骤上；
2. 可以在业务流程开始之后串行或并行的进行所有的操作，只要最终的结果和我们想的一样就可以，如果结果不一样，那就需要将所有操作产生的改动做还原操作。
    

业务补偿的设计重点

两个最重要的事情

• 将业务流程执行完毕；
• 过程出错的话就要将所做操作产生的任何东西还原至操作之前的状态。

其余设计重点

• 服务需要支持幂等性，其上游服务或系统可以对其进行重试操作；
• 让工作流引擎来管理操作过程的状态及步骤，它必须是健壮稳定的以及能够保证高可用性；
• 设计业务正常流程的时候，也需要考虑到业务的反向补偿流程；
• 业务补偿的逻辑是与业务相关的，基本做不到可以通用的程度；
• 提供临时的资源预留机制，当一个流程没有在一定时间内执行完毕时，就释放这个流程，并将整个操作和其所产生的变动回滚至开始之前。
   

末了

重新总结了一下文中提到的内容：ACID、BASE、一致性、强一致性、最终一致性、业务补偿逻辑、业务补偿设计重点。