微服务架构 - Saga与分布式事务

1. 传统事务微服务架构下面临的挑战

在微服务的架构中，单个服务中的事务仍然可以使用ACID事务。
但是，如果跨多个服务的事务，数据库也跨多个，这样传统的事务就没法解决。

例如，一个下单操作createOrder()将跨越多个服务:
OrderService --> PaymentService --> InventoryService --> LogisticsService

像上述这种跨服务的操作必须使用Saga来维护数据的一致性，而不是传统的ACID事务。

什么是Saga?
Saga是一种消息驱动的本地事务序列。
Saga通过一系列本地事务来更新数据库，发布消息或事件来触发Saga里的下一个本地事务。如果一个本地事务由于违反了业务规则而失败，Saga执行一系列补偿事务以撤回被前面事务产生的更改。

Saga的弱点:
Saga的弱点在于值满足ACD(原子性，一致性和持久性)，而缺乏了ACID中的隔离性。
因此，需要找到办法来防止或减少由于缺乏隔离性而导致的并发异常。

2. 补偿事务

Saga使用补偿事务来回滚所做出的改变。

每一个事务都有对应的补偿事务来进行撤销之前进行的操作。
T1, T2, ... Tn, Tn+1失败 --> Cn, Cn-1, ... C1

Saga按照正常事务的反向顺序来执行补偿事务。

在之前的下单的例子中:
OrderService(下单) --> PaymentService(支付) --> InventoryService(扣减库存) --> LogisticsService(发货)

注意: 不是每个步骤都需要补偿事务，如果是只读的步骤就不需要补偿事务。

3. Saga的协调模式

在Saga模式中，一个本地事务完成了，Saga要协调下一个参与方执行本地事务;如果任何本地事务失败了，Saga必须以相反的顺序执行补偿事务。

Saga的协调逻辑分为两种类型:

• 协同式(Choreography)
  把Saga的决策和执行顺序逻辑分布在Saga的每一个参与方中，它们通过交换事件的方式来进行沟通。

• 编排式(Orchestration)
  把Saga的决策和执行顺序逻辑集中在一个Saga编排器类中。
  Saga编排器发出命令式消息给各个参与方，指示这些参与方服务完成具体的本地事务操作。