微服务分布式事务
一般每个微服务都有自己的数据库，当有跨几个微服务的业务时要保证数据库的一致性就需要考虑到分布式事务，典型的涉及库存、订单、账户 3 个微服务的商品订购业务。
严格的事务需要保证原子性，要么一个请求的所有操作全部成功，要么全部失败。分布式事务更多强调柔性事务，遵循BASE原则，有几种流行的机制或模式：
- AT 自动补偿
- Saga（long live transaction）
- TCC（Try Confirm Cancel）
- XA/2PC（Two-Phase Commit）
- 可靠消息，基于消息队列的最终一致性事务
- EventSourcing + CQRS(Command Query Responsibility Segregation)
AT
基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性。
根据 SQL 解析结果，记录回滚日志，回滚日志和业务 SQL 在同一个本地事务中提交到数据库。如果分支提交，异步删除回滚日志记录。如果分支回滚，依据回滚日志进行反向补偿更新。
Saga
Saga属于补偿的一种，当事务失败的时候，Saga对已经提交的事务做补偿，也就是undo操作。可以看做一个异步的、利用队列实现的补偿事务。
Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。
Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。参与者可以采用事务驱动异步执行，高吞吐。
目前 Saga 的实现一般也两种，一种是通过事件驱动架构实现，一种是基于注解加拦截器拦截业务的正向服务实现。
TCC
Saga这种方式并不能保证隔离性，于是出现了TCC，在实际交易逻辑前先做业务检查、对涉及到的业务资源进行“预留”。例如有如下场景：某笔订单完成时，同时扣掉用户的现金，但交易未完成，也未被取消时，不能让客户看到钱变少了。
对于这种场景TCC的流程如下：
- 订单服务创建订单
- 订单服务发送远程调用到现金服务，冻结客户的现金
- 提交订单服务数据
- 订单服务发送远程调用到现金服务，扣除客户冻结的现金
以上是正常完成的流程，若为异常流程，则需要发送远程调用请求到现金服务，撤销冻结的金额。
XA
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。
XA 规范 描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范 的目的是允许的多个资源（如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。
XA 规范 使用两阶段提交（2PC，Two-Phase Commit）来保证所有资源同时提交或回滚任何特定的事务。
- 业务无侵入：和 AT 一样，XA 模式将是业务无侵入的。
- 数据库的支持广泛：XA 协议被主流关系型数据库广泛支持。
- 多语言支持容易：因为不涉及 SQL 解析。
比较
AT、Saga、TCC都是 补偿型 的。
补偿型 事务处理机制构建在 事务资源 之上（要么在中间件层面，要么在应用层面），事务资源 本身对分布式事务是无感知的。事务资源 对分布式事务的无感知存在一个根本性的问题：无法做到真正的 全局一致性 。
与 补偿型 不同，XA 协议 要求 事务资源 本身提供对规范和协议的支持。因为 事务资源 感知并参与分布式事务处理过程，所以 事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。但是有数据锁定和协议阻塞的问题，甚至可能会发生死锁。
不存在一种事务模式能解决所有的问题，我们需要根据特定的业务场景选择合适的事务模式。
分布式事务框架
流行的分布式框架主要有Spring的EasyTransaction和阿里的Seata。
EasyTransaction
基于Spring的分布式事务框架，实现了上述除2PC以外的所有事务形态，并提供了统一的使用接口。
Seata（阿里GTS开源版本）
Seata定义了全局事务的框架，有独立部署的集中式的TC，这样其可以 更容易 实现对分布式事务的监管控，如关于APM、Metrics、统一限流 等等功能。Seata 已经支持补偿型的 3 大事务模式：AT、TCC、Saga，最新也已经开始支持非补偿型的XA事务模式，预计2020年内可以面向生产。
Reference
Pattern: Saga
如何选择分布式事务形态
讲清楚分布式事务选型
分布式事务框架Seata及EasyTransaction架构深度分析
分布式事务如何实现？深入解读 Seata 的 XA 模式
