但是这么一个支付过程调用多个子服务，我们不能保证所有服务都能成功，比如我们在调用红包系统扣减红包系统失败。这个时候我们就碰到尴尬的场景，由于红包服务失败，导致方法异常退出，这个时候订单状态为初始状态，但是用户余额已经扣减。这对用户体验非常不友好。所以这次支付过程，我们必须存在机制将这次过程当成一次整体的行为，必须保证这其中服务调用，要么都成功，要么都失败，成为一个整体的事务。
这时我们可以引入 TCC 事务，将整个下单过程作为一个整体。引入后，由于余额系统扣减是失败，这个时候我们回滚订单系统与红包系统。整个过程如下图。
由于余额系统的失败，我们需要撤销这次过程中所有更改，所以我们向订单系统发送撤销通知，向红包系统发出撤销通知。
因此系统引入 TCC 事务后，我们需要改造我们的调用过程。
系统如何引入 TCC 事务根据 TCC 事务三步，这个时候我们必须将各个服务改造成 Try Confirm Cancle 三步、
TCC TRY:
根据上面的业务，订单系统增加 try 方法将订单状态修改成 PAYING。余额系统增加一个 try 方法，先检查用于余额是否充足，然后先将余额扣减，然后将扣减的余额增加到冻结金额。红包系统同余额系统。从改造过程可以看出，TCC try 方法需检查各业务资源，且这过程需要引入中间状态。我们根据下图来看整个过程。
TCC Confirm:
TCC 第一步 TRY 如果所有子服务调用都成功，这个时候我们就需要确认各服务。各个服务增加 confirm 方法。如余额系统 confirm 方法用来将冻结金额置为0，红包系统如上。订单系统将订单状态修改为 SUCCESS。confirm 方法需要注意实现幂等。如订单系统更新前，一定要先判断该笔订单状态处于 PAYING，才能更新订单。整个过程如下图。
讲到这里，必须用到 TCC 事务框架推动各服务。TCC 事务管理器感知到 TRY 方法结束后，自动调用各服务提供的 confirm 方法，将各服务状态修改为终态。
TCC Cancle：
如若 TCC Try 过程中，冻结红包方法失败，这时我们就需要将之前修改都撤销，修改成其初始状态。cancle 方法也需要实现幂等如 confirm 方法 如下图：
看到这，我们我们可以看出 TCC Try 成功，confirm 必定要成功，try 失败，cancle 必定要成功。因为 confirm 是系统更新为终态的关键。但是现实这么无情，生产系统 confirm 或 cancle 肯定会有几率失败，这个时候就需要 TCC 框架记录调用 confirm 结果。如果 confirm 调用失败，TCC 框架需要记录下来，然后间隔一定时间再次去调用。
总结与思考看完全文，基本上对分布式事务又一定了解了吧。
我们基于此对此总结下。使用分布式事务，我们需要结合我们实际场景应用。
如果业务还处于开始阶段，我们其实可以选择数据库事务来保证快速上线迭代。
等到业务一定阶段，系统开始拆分，数据库也拆分，这时如果业务需要保证一致性，这时必须使用分布式事务。这时候使用分布式事务，我们需要基于业务考虑使用哪种。
使用 2PC 或 3PC 实现的分布式框架，业务应用层无需改动，接入较简单。但是相对应能较低，数据资源锁定较长。不太适合互联网等高并发业务场景。