微服务分布式事务的几种解决方案及应用场景

分布式事务的几种方案

1. 2pc模式
2. TCC模式：柔性事务——TCC事务补偿型
3. 柔性事务-最大努力通知型方案
4. 柔性事务-可靠消息+最终一致性方案（异步确保型）

1. 2pc

2pc就是 2 phase commit 二阶段提交，又叫XA Transactions，这是2pc的一种实现协议，基于数据库层面的。

MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。

其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是 否可以提交.

第二阶段：事务协调器要求每个数据库提交数据。 其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。

• XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。
• XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景。因为会一直锁住资源，在整个分布式事务中都一直锁住，直到提交或回滚事务，才释放锁住的资源，所以高并发场景下性能不足。
• XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。
• 许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。
• 也有 3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间 未收到回应则做出相应处理）

seata的AT

Seata是由TM，RM，TC。 其中TM和RM是在客户端，TC是事务协调者是需要单独部署的服务端。

• TC (Transaction Coordinator) - 事务协调者 维护全局和分支事务的状态，驱动全局事务提交或回滚。
• TM (Transaction Manager) - 事务管理器（发起者，同时也是RM的一种） 定义全局事务的范围：开始全局事务、提交或回滚全局事务。
• RM (Resource Manager) - 资源管理器（每个参与事务的微服务） 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

AT是2pc的变种，不过不是在数据库层面实现的分布式事务一致性，而是通过保存日志，通过日志来回滚

是两阶段提交协议的演变，比XA协议快一点：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：
  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

写隔离性质：

• 一阶段本地事务提交前，需要确保先拿到 全局锁 。
• 拿不到 全局锁 ，不能提交本地事务。
• 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁

读隔离：

在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted） 。

如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

具体点过程：

一阶段

过程（具体看官网）：

1. 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
2. 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。
3. 执行业务 SQL：更新这条记录的 name 为 ‘GTS’。
4. 查询后镜像：根据前镜像的结果，通过 主键 定位数据。
5. 插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
6. 提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。
7. 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
8. 将本地事务提交的结果上报给 TC（事务协调者）。

注意！seata的at模式下讲的undolog是指seata服务器保存的实现事务的undolog，并不是要操作的数据库自身事务的undolog！

二阶段-回滚

1. 收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。

2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。

3. 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。

4. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：

5. 提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

二阶段-提交

1. 收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

适用场景：对性能要求不太苛刻，需要代码无侵入、易维护

seata也支持XA模式，XA和AT的区别是，XA是基于数据库提供的一致性协议，而AT是seata通过额外的数据源来维护undolog表来保证一致性。

2. 柔性事务——TCC事务补偿型

刚性事务：遵循 ACID 原则，强一致性。

柔性事务：遵循 BASE 理论，最终一致性；

与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致

3. 柔性事务-最大努力通知型方案

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种 方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通 知次数后即不再通知。

适用场景：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对 账文件），支付宝的支付成功异步回调

4. 柔性事务-可靠消息+最终一致性方案（异步确保型）

实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。

防止消息丢失：

1、做好消息确认机制（pulisher，consumer【手动 ack】）

2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍

适用场景：高并发的订单创建与确认、支付

以谷粒商城的下订单与确认订单、支付为例

为了防止订单创建的时候，远程锁定库存服务锁定成功，订单其他方法失败，导致订单回滚，而库存不回滚。远程锁定库存服务在锁定库存之后会自动触发库存检查解锁逻辑——即发送消息给延迟队列（stock.locked）,50min后检查订单状态，确定是否解锁，就解决了“库存服务锁定成功，订单服务失败订单回滚”的问题