今天咱们来聊聊分布式架构中的分布式事务。只要涉及到交易、涉及到多个库，那必然绕不开分布式事务。在很多场景下，我们要保证数据的一致性，这就意味着要么全部成功，要么全部失败。比如说，不能出现支付成功了，但优惠券没抵扣、积分没加上这种情况，后果不堪设想。
总之，事务在整个系统中起着重要作用，也是分布式相关面试重点考察的对象。分布式事务主流的实践方式主要有两种，一种是基于 XA 协议，另一种是基于 TCC 。
先说 XA 协议，它的原理是两阶段提交，并且依赖数据库本身的事务。事务开始后，事务管理器先询问各个数据库是否准备好，如果都回复 OK ，就正式提交事务在各个数据库上执行操作；要是有任何一个数据库回答不 OK ，那就回滚事务。举个例子，您购买商品，有抵扣券和积分，会先利用数据库事务冻结积分和抵扣券，购买成功后再正常提交，把冻结的积分和优惠券扣掉。这个方案相对简单，但比较依赖数据库事务，效率不高。而且有同学可能会问，XA 协议是不是只能用于单服务内部的多数据库场景？其实跨服务的多资源场景也能用，只是需要额外的事务传递机制。
再来说说 TCC ，它跟 XA 协议有较大区别，不需要依赖数据库的事务，采用的是补偿机制来处理数据一致性问题。它有三个阶段，分别是 Try 、Confirm 、Cancel 。Try 阶段对业务系统进行检测和资源预留，比如在交易系统中要抵扣积分，就先通过业务代码冻结。Confirm 阶段对业务系统做确认提交，真正开始扣减积分、扣优惠券、完成支付。要是遇到错误，就直接回滚，之前冻结的积分直接释放。
TCC 代码的侵入性比较强，每个阶段都需要业务代码来实现，因为不依赖数据库事务，回滚需要通过补偿机制，比如支付失败，要返还之前扣除的积分，可以通过发送消息到积分中心，让积分中心通过业务代码处理积分返还。TCC 在分布式架构下应用更多，不像 XA 那样长时间占用数据库资源，所以在性能上更优秀一些。
当然，除了 XA 和 TCC ，还有利用消息队列做事务的方式，先发送半消息，然后执行主业务，成功之后半消息就转成正常消息进行消费，之前咱们讲消息队列的时候也专门讲过，感兴趣的同学可以去翻一翻。
