读 | SA : The Hard Parts 之事务

• 读 | Software Architecture：The Hard Parts 之耦合
• 读 | Software Architecture：The Hard Parts 之代码复用
• 读 | Software Architecture：The Hard Parts 之数据所有权
• 读 | Software Architecture：The Hard Parts 之数据访问
• 🍗读 | Software Architecture：The Hard Parts 之事务
• 读 | Software Architecture：The Hard Parts 之约定

事务，即由一组操作组成的、独立的逻辑工作单元，在传统的数据库中，定义事务必须具有 ACID 特性

• Atomicity，原子在哲学里是不可再分的意思，这里即指一个事务必须被当作一个不可分割的最小单元，要么全部成功，要么全部失败。
• Consistency，数据库总是从满足自身一致性约束的一个状态转换到另一个状态。
• Isolation，一个事务所作的修改，在 commit 之前，对其他事务是不可见的。
• Durability，事务提交成功后，即使遭遇硬件故障或数据库系统崩溃，修改也不会丢失。

在实际设计中，我们设计的是业务事务，对应到数据库层面是由数据库事务进行保障。在单体系统中，两者是统一的，而在拆分后的分布式架构中，两者不再协调统一，存在跨服务、跨库的业务事务（业务事务不关心技术是如何实现事务的，它需要达到如此的业务效果），这时候事务的 ACID 定义就面临挑战，以下图为例：

• Atomicity，Customer、Support commit 成功了，而 Billing 失败了，没有全部成功或全部失败。
• Consistency，三张表中的数据不一致。
• Isolation，Customer、Support commit 成功后，数据可以被其他业务事务获取到。
• Durability，Customer、Support 的修改 commit 成功了，但无法保障 Billing 的修改也能持久化到数据库。

主要原因在于传统事务的 ACID 特性绑定的是各个服务，而不是绑定到全局。因此需要针对分布式事务的、新的事务定义—— BASE 理论。

• BAsic availability，参与分布式事务的所有服务都要可用。
• Soft state，允许存在软状态，即分布式事务已经提交，在处理中，但尚未完成。
• Eventual consistency，在时间充足的情况下，分布式事务的所有部分都会完成，数据也达到一致。

遗憾的是分布式事务非常复杂，其事实标准为 XA，要求参与方都要支持 XA，但很多新技术并不支持 XA ，如 mongodb、kafka。同时为了完成事务提交，要求所有参与方都要可用，也会降低系统整体的可用性。所以在微服务中，通常不采用分布式事务，而采用另一种较简单的 Saga 机制来维护数据一致性。

在 Chris Richardson 的描述中，Saga 由一连串的本地事务组成，每一个本地事务负责更新它所在服务的私有数据库（这些操作仍然依赖 ACID 事务特性），每一个更新都触发一个事件，该事件又触发事务链条中的下一个更新，任意更新失败了，都会促使 Saga 发出一连串补偿更新，以回滚之前执行的更新操作。

为了对外表现为一个整体，在分布式系统中，有 3 种固有因素会促使系统耦合：

• Communication，分布式系统各部分之间总要通信，通信方式有两种
  • 同步
  • 异步
• Consistency，分布式系统内部的状态需要保持一致，一致性有两种
  • 原子性
  • 最终一致性，一般有三种具体方案可以选择：
    • Background Synchronization pattern，用单独后台进程来同步数据
    • Orchestrated Request-Based pattern，用集中编排器，在请求到来时就处理好分布式事务
    • Event-Based pattern，使用基于异步方式的发布-订阅模型来推送事件或命令消息
• Coordination，分布式系统各部分需要协调各自的行为，协调方式有两种
  • 集中编排
  • 分散协调

3 种因素有 8 种组合方式，列举了 8 个（比较随意的）名称 ：

• 000 Epic Saga
• 001 Phone Tag Saga
• 010 Fairy Tale Saga
• 011 Time Travel Saga
• 100 Fantasy Fiction Saga
• 101 Horror Story
• 110 Parallel Saga
• 111 Anthology Saga

000 Epic Saga

模仿了单体系统的行为模式，耦合程度最高，响应性/可用性较低，弹性差。

001 Phone Tag Saga

将协调方式从集中编排更换为分散协调，没有统一的编排者，在整理处理流程中每个部分都只知道自己的内容，当发生错误时，也是调用自己内置的错误处理机制发送补偿请求。这种组合较少采用，如果选择了分散协调，一般会接着选择异步方式通信。

耦合性依然高，复杂性高，响应性/可用性低，弹性差。

010 Fairy Tale Saga

放松了对一致性的要求，这种模式下仍然存在集中编排者协调请求/响应/错误处理，但不管理事务（没有整体性的事务存在），各个服务管理好自己的事务。

耦合性高，复杂度低，响应/可用性一般，弹性好。

011 Time Travel Saga

耦合性一般，复杂度低，响应/可用性一般，弹性好。

100 Fantasy Fiction Saga

耦合性高，复杂度高，响应/可用性低，弹性差。

101 Horror Story

因为没有中介，为了保持原子性，服务间通信量会很大。

耦合性一般，复杂度巨高，响应/可用性差，弹性一般。

110 Parallel Saga

耦合性低，复杂度低，响应/可用性高，弹性好。

111 Anthology Saga

使用消息队列发送异步消息来通信。耦合性非常低，复杂度高，响应/可用性高，弹性非常好。