Saga

Saga和TCC一样，也是最终一致性事务、柔性事务。Saga的实质就是把一个长事务分隔成一个个小的事务，每个事务都蕴含一个执行模块和弥补模块。
Saga的模型如下：

  • 每个Saga由一系列sub-transaction Ti 组成。
  • 每个Ti 都有对应的弥补动作Ci，弥补动作用于撤销Ti造成的后果。


Saga的执行程序：

  • T1, T2, T3, ..., Tn
  • T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n

Saga的复原形式：

  • 向后复原：撤销Ti造成的后果。
  • 向前复原：始终重试Tj前面的事务，直至胜利，这个时候须要保障肯定胜利。然而其实很难保障的，比方扣减库存，曾经库存为0了，你让他怎么减。所以失常用向后复原。

同样用TCC的例子来阐明一下。
失常状况下，订单服务把状态改为已出库，提交事务后，调用库存服务，更改库存值。

如果库存服务出现异常，向后复原的话，就是把已出库的状态改为未出库。

向前复原的话，就是始终调用库存服务，直至库存扣减胜利。

和TCC比照

Saga没有try，间接提交事务，所以也没有预留资源。比方库存，TCC会解冻掉，Saga是间接扣除。
从通信上来说，Saga通信次数少，等于子事务的个数，而TCC是子事务的2倍（try后再commit一次）。
从业务上来说，TCC的侵入性更大，每个业务流程都要Try、Commit、Cancel。Saga只有提供一个中央对事务弥补就好了。