TCC(Try，Confirm，Cancel)
强隔离性的分布式事务模型 —— TCC（Try，Confirm，Cancel，类似2PC）
TCC 是一种对业务侵入性较强的事务方案，要求业务处理过程中必须拆分为「预留业务资源」、「确认/释放消费资源」两个子过程，两个子过程细化为如下三个阶段：
Try 阶段：尝试执行阶段，完成所有业务可执行检查（预留必须业务资源，保障隔离性）。
Confirm 阶段：如果所有分支的 Try 都成功了，则走到 Confirm 阶段。Confirm 真正执行业务，使用 Try 阶段预留的业务资源来完成处理。
Cancel 阶段：如果所有分支的 Try 有一个失败了，则走到 Cancel 阶段，释放 Try 阶段预留的业务资源。
按照 TCC 的协议规定，Confirm 和 Cancel 阶段只返回成功，不会返回失败，如果由于网络问题或者服务器临时故障，那么事务管理器会进行重试直至最终成功，
所以这两个阶段的操作要求具备幂等性。笔者继续以前篇下单为案例，说明 TCC 事务处理流程，不过我们稍微简化下逻辑，案例中去除不那么重要的积分服务，只保留支付、仓库服务。
SAGA 事务模式
SAGA 事务模式（适用于流程长，且需要保证事务最终一致性的业务操作），在 SAGA 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
冲正补偿：冲正补偿指的是在分布式事务出现异常时，通过一系列的操作，尽可能使得分布式事务状态回滚到之前的状态，从而避免分布式事务产生不一致的情况。
SAGA 事务模型由两部分操作组成：
一部分是将大事务 T 拆分成若干小事务，命名为 T1，T2，Tn。每个子事务被应被视为原子行为，如果分布式事务 T 能够正常提交，那么它对数据的影响（最终一致性）就应该与连续按顺序成功提交子事务 Ti 等价。
另一部分是为每个子事务设计对应的补偿动作，命名为 C1，C2，Cn。Ti 与 Ci 满足以下条件：
- Ti 与 Ci 具备幂等性。
- Ti 与 Ci 满足交换律，即无论先执行 Ti 还是先执行 Ci，其效果都是一样的。
- Ci 必须能成功提交，即不考虑 Ci 的失败回滚情况，如果出现失败持续重试直至成功或者被人工介入为止。
- 如果 T1 到 Tn 均执行成功，那么整个事务顺利完成，否则要根据下面两种恢复策略之一进行恢复。
正向操作（Forward Recovery）如果 Ti 提交失败，则一直对 Ti 进行重试，直至成功为止（最大努力交付）。这种恢复方式不需要进行补偿，适用于事务最终都要执行成功的情况，譬如订单服务中银行已经扣款，那么就一定要发货。
逆向回滚（Backward Recovery）如果 Ti 提交失败，则执行对应的补偿 Ci，直至恢复到 Ti 之前的状态，这里要求 Ci 必须成功（持续重试，最大努力交付）。
