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 只有提供一个中央对事务弥补就好了。