一次面试阿里之后的感慨：TCC分布式事务原理真的得搞明白！

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

目录

• 一、写在前面
• 二、业务场景介绍
• 三、进一步思考
• 四、落地实现TCC分布式事务
• 五、总结与思考

一、写在前面

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了不少文章，还是不知道分布式事务到底怎么回事，在项目里到底如何使用。

所以咱们这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是TCC分布式事务。

首先说一下，这里可能会牵扯到一些Spring Cloud的原理，如果有不太清楚的同学，可以参考之前的文章：《用SpringCloud的时候胡乱写配置的兄弟们，事故加班一定很多！》。

---

二、业务场景介绍

咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。

那对一个订单支付之后，我们需要做下面的步骤：

• 更改订单的状态为“已支付”
• 扣减商品库存
• 给会员增加积分
• 创建销售出库单通知仓库发货

这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。

三、进一步思考

好，业务场景有了，现在我们要更进一步，实现一个TCC分布式事务的效果。

什么意思呢？也就是说，订单服务-修改订单状态，库存服务-扣减库存，积分服务-增加积分，仓储服务-创建销售出库单。

上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。

举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是100件，现在卖掉了2件，本来应该是98件了。

结果呢？由于库存服务操作数据库异常，导致库存数量还是100。这不是在坑人么，当然不能允许这种情况发生了！

但是如果你不用TCC分布式事务方案的话，就用个Spring Cloud开发这么一个微服务系统，很有可能会干出这种事儿来。

我们来看看下面的这个图，直观的表达了上述的过程。

所以说，我们有必要使用TCC分布式事务机制来保证各个服务形成一个整体性的事务。

上面那几个步骤，要么全部成功，如果任何一个服务的操作失败了，就全部一起回滚，撤销已经完成的操作。

比如说库存服务要是扣减库存失败了，那么订单服务就得撤销那个修改订单状态的操作，然后得停止执行增加积分和通知出库两个操作。

说了那么多，老规矩，给大家上一张图，大伙儿顺着图来直观的感受一下。