在分布式事务一文中我们说到了分布式事务的强一致性解决方案，那么最终一致性解决方案呢？这里我就再说一下最终一致性解决方案，而分布式事务最终一致性解决方案的典型方案就是--TCC 解决方案。

最终一致性解决方案

最终一致性解决方案就是说并不要求参与事务的各个节点的数据时刻保持一致，而是允许有一个中间状态，在一段时间后，能够达到数据的最终一致状态就可以。

优点：性能比较高，适合高并发场景，具备可用性。

缺点：某一时刻查询到的数据可能会不一致，对于事务一致性要求高的场景不适用。

典型的最终一致性方案有：TCC 解决方案；可靠消息最终一致解决方案；最大努力通知型解决方案。下面主要讲述一下 TCC 解决方案

TCC 解决方案

TCC 模式主要分为三个阶段：

1.Try 阶段：完成所有业务的一致性检查及预留业务资源

2.Confirm 阶段：此阶段会真正执行业务操作，不再进行业务检查，此阶段操作需要满足幂等性

3.Cancel 阶段：取消执行业务操作，释放业务资源

TCC 方案执行流程

流程图如下

在使用 TCC 解决方案时需要考虑到幂等问题，比如在服务器宕机或网络异常等情况时，为了保证方法正常执行，通常会加入超时重试机制，而一旦触发重试机制就有可能导致数据不一致，这时候就需要保证 TCC 方案的 Confirm 阶段和 Cancel 阶段的幂等性。

TCC 方案举例

日常生活中不管是京东还是淘宝，大家总是都在线购物过吧，这也就是常说的电商业务场景了，电商业务场景中最有代表意义的场景就是支付订单场景，这个场景包括修改订单状态、扣减库存、增加积分、创建出库单、物流单等业务，那么这些业务要么全部执行成功，要么全部执行失败，必须是一个完整的事务整体。

那么问题来了，如果没有分布式事务，问题就来了：

1.【订单服务】修改订单状态成功，调用远程【库存服务】扣减库存异常，库存扣减失败，而【积分服务】【仓储服务】都执行成功，则此时就是修改订单状态成功，库存未扣减，可能超卖

2.【订单服务】修改订单状态失败，【库存服务】扣减库存成功，此时会出现库存异常扣减情况。

因此，为了保证数据最终一致性，对于订单服务，不能简单的将订单状态直接修改为‘支付成功’，将库存直接修改为‘已扣减’，而是应该有一个中间状态，因此对于支付订单场景，

Try 阶段主要业务流程

1.【订单服务】修改订单状态为‘支付中’

2.【库存服务】冻结下单的库存数量，而不是直接扣减库存数量

3.【积分服务】不是直接增加积分，而是预增加积分

4.【仓储服务】不在直接生成出库单，而是将出库单标记为‘未知’

Try 阶段整体流程图就是

Confirm 阶段主要业务流程

1.【订单服务】修改订单状态为‘支付成功’

2.TCC 分布式事务框架调用【库存服务】中 Confirm 阶段的方法真正扣减库存

3.TCC 分布式事务框架调用【积分服务】中 Confirm 阶段的方法真正增加积分

4.TCC 分布式事务框架调用【仓储服务】中 Confirm 阶段的方法将出库单的状态更新为‘已创建’

Confirm 阶段流程图就是

Cancel 阶段主要流程

1.【订单服务】修改订单状态为‘已取消’

2.TCC 分布式事务框架调用【库存服务】中 Cancel 阶段的方法进行事务回滚

3.TCC 分布式事务框架调用【积分服务】中 Cancel 阶段的方法进行事务回滚

4.TCC 分布式事务框架调用【仓储服务】中 Cancel 阶段的方法进行事务回滚，同时将出库单的状态更新为‘已取消’

Cancel 阶段流程图就是

这样两篇文章对整个 TCC 分布式解决方案的基本原理和流程图到这里就讲述完了，希望对大家有帮助。