浅谈Saga分布式事务

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只要提供一个地方对事务补偿就好了。