分布式事务系列--是选TCC还是SAGA

byteTCC框架，支持两种模式，一种是TCC模式，一种是SAGA模式，二者如何选择，是一个取舍问题，没有完美方案。

1.TCC模式

这种模式下，我们需要操作的目标字段，都要添加一个相关的冻结字段，try操作是操作冻结字段，cc操作时，将冻结的数值更新到目标字段。 示例如下：

  <!--try逻辑-->
  <update id="increaseMoney">
    UPDATE company SET frozen = frozen + #{money}
    WHERE id = #{id}
  </update>

  <!--confirm逻辑-->
  <update id="confirmIncreaseMoney">
    UPDATE company SET money = money + #{money},frozen = frozen - #{money}
    WHERE id = #{id}
  </update>

  <!--cancel逻辑-->
  <update id="cancelIncreaseMoney">
    UPDATE company SET frozen = frozen - #{money}
    WHERE id = #{id}
  </update>

2.SAGA模式

这种模式，是使用一个反向的业务操作，来撤销之前的业务操作。SAGA模式，try阶段直接操作目标字段，不需要使用冻结字段，和TCC模式相比，saga不需要confirm操作。

3.对比

设想一种场景：A->B,C,D。这种场景下，如果发生如下情况：

• 1.B，C的try成功了，但是D的try失败了；
• 2.此时另外的用户来读取BCD的值；
• 3.ABCD进行回滚；

显然，不管是TCC还是SAGA模式，try出问题了，都会进入cancel阶段，但是，恰巧，在BC刚try成功D失败了，但是还未来得及回滚的情况下，有用户来读取BCD的值。

那么，这种情况下，使用TCC和SAGA，结果是不一样的。

在TCC中，由于try操作的是冻结字段，所以，其他用户在try和cancel的间隙来读数据，那么读的数据也是正确的，因为目标字段并没有发生改变。

在SAGA中，由于直接操作的目标字段，所以，try阶段，由于数据已经提交了，那么其他用户在try和cancel的间隙来读取数据，读到的数据，就是有问题的“脏数据”。

4.结论

1.TCC模式下

• 缺点：开发麻烦，因为每个目标字段都需要一个冻结字段来支撑事务操作；
• 优点：不存在上述脏数据的问题；

2.SAGA模式下

• 缺点：数据没有很好的隔离，有脏数据的风险；
• 优点：开发简单，不需要预留冻结字段；

当然，看起来只有在2PC模型下，才不存在这个“脏读风险”。

关于这个问题，推荐几篇文章看看： mysql的四种隔离级别 fescar锁设计和隔离级别的理解