微服务分布式事务与Saga

微服务分布式事务

一般每个微服务都有自己的数据库，当有跨几个微服务的业务时要保证数据库的一致性就需要考虑到分布式事务，典型的涉及库存、订单、账户 3 个微服务的商品订购业务。

严格的事务需要保证原子性，要么一个请求的所有操作全部成功，要么全部失败。分布式事务更多强调柔性事务，遵循BASE原则，有几种流行的机制或模式：

基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性。

根据 SQL 解析结果，记录回滚日志，回滚日志和业务 SQL 在同一个本地事务中提交到数据库。如果分支提交，异步删除回滚日志记录。如果分支回滚，依据回滚日志进行反向补偿更新。

Saga属于补偿的一种，当事务失败的时候，Saga对已经提交的事务做补偿，也就是undo操作。可以看做一个异步的、利用队列实现的补偿事务。
Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。参与者可以采用事务驱动异步执行，高吞吐。

目前 Saga 的实现一般也两种，一种是通过事件驱动架构实现，一种是基于注解加拦截器拦截业务的正向服务实现。

Saga这种方式并不能保证隔离性，于是出现了TCC，在实际交易逻辑前先做业务检查、对涉及到的业务资源进行“预留”。例如有如下场景：某笔订单完成时，同时扣掉用户的现金，但交易未完成，也未被取消时，不能让客户看到钱变少了。

对于这种场景TCC的流程如下：

以上是正常完成的流程，若为异常流程，则需要发送远程调用请求到现金服务，撤销冻结的金额。

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。

XA 规范描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范的目的是允许的多个资源（如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。

XA 规范使用两阶段提交（2PC，Two-Phase Commit）来保证所有资源同时提交或回滚任何特定的事务。

AT、Saga、TCC都是补偿型的。

补偿型事务处理机制构建在事务资源之上（要么在中间件层面，要么在应用层面），事务资源本身对分布式事务是无感知的。事务资源对分布式事务的无感知存在一个根本性的问题：无法做到真正的全局一致性。

与补偿型不同，XA 协议要求事务资源本身提供对规范和协议的支持。因为事务资源感知并参与分布式事务处理过程，所以事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。但是有数据锁定和协议阻塞的问题，甚至可能会发生死锁。

不存在一种事务模式能解决所有的问题，我们需要根据特定的业务场景选择合适的事务模式。

流行的分布式框架主要有Spring的EasyTransaction和阿里的Seata。

基于Spring的分布式事务框架，实现了上述除2PC以外的所有事务形态，并提供了统一的使用接口。

Seata定义了全局事务的框架，有独立部署的集中式的TC，这样其可以更容易实现对分布式事务的监管控，如关于APM、Metrics、统一限流等等功能。Seata 已经支持补偿型的 3 大事务模式：AT、TCC、Saga，最新也已经开始支持非补偿型的XA事务模式，预计2020年内可以面向生产。

Seata全局事务框架

Pattern: Saga
如何选择分布式事务形态
讲清楚分布式事务选型
分布式事务框架Seata及EasyTransaction架构深度分析
分布式事务如何实现？深入解读 Seata 的 XA 模式