结合电商模式打造校园交易平台之分布式事务篇（全文总共13万字，超详细）

天选的爪哇

已于 2023-08-30 11:02:47 修改

阅读量450

点赞数 5

文章标签：分布式数据库 mysql

于 2023-03-13 15:49:24 首次发布

本文链接：https://blog.csdn.net/xjx666666/article/details/129496249

版权

分布式事务

本地事务

事务的基本性质

数据库事务的几个特性：原子性(Atomicity)、一致性(Consistency)、隔离性或独立性(Isolation) 和持久性(Durabilily)，简称就是 ACID。

原子性：一系列的操作整体不可拆分，要么同时成功，要么同时失败
一致性：数据在事务的前后，业务整体一致。
隔离性：事务之间互相隔离。
持久性：一旦事务成功，数据一定会落盘在数据库。

在以往的单体应用中，我们多个业务操作使用同一条连接操作不同的数据表，一旦有异常，我们可以很容易的整体回滚。

在这里插入图片描述

Business：我们具体的业务代码
Storage：库存业务代码；扣库存
Order：订单业务代码；保存订单
Account：账号业务代码；减账户余额

比如买东西业务，扣库存，下订单，账户扣款，是一个整体；必须同时成功或者失败。

一个事务开始，代表以下的所有操作都在同一个连接里面。

事务的隔离级别

READ UNCOMMITTED（读未提交）

该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为脏读。

READ COMMITTED（读已提交）

一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为不可重复读问题，Oracle 和 SQL Server 的默认隔离级别。

REPEATABLE READ（可重复读）

该隔离级别是 MySQL 默认的隔离级别，在同一个事务里，select 的结果是事务开始时时间点的状态，因此，同样的select操作读到的结果会是一致的，但是会有幻读现象。MySQL 的 InnoDB 引擎可以通过 next-key locks 机制（参考下文"行锁的算法"一节）来避免幻读。

在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

当隔离级别设置为REPEATABLE READ 时，可以避免不可重复读。当A拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），A的老婆就不可能对该记录进行修改，也就是A的老婆不能在此时转账。

幻读（前后多次读取，数据总量不一致）：

事务A在执行读取操作，需要两次统计数据的总量，前一次查询数据总量后，此时事务B执行了新增数据的操作并提交后，这个时候事务A读取的数据总量和之前统计的不一样，就像产生了幻觉一样，平白无故的多了几条数据，成为幻读。

SERIALIZABLE（序列化）

在该隔离级别下事务都是串行顺序执行的，MySQL 数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。

不可重复读和脏读的区别是：脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

事务的传播行为

1、PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

2、PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。

3、PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。

4、PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

5、PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

6、PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

7、PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

下面是两个事务传播行为的案例：

案例一：

方法B()和方法A()共用一个事务，方法C则创建一个新事务，若出现异常则方法B()和方法A()会回滚，方法C()则不会（因为它自己是一个单独的事务）

案例二：

方法B()设置了事务的超时时间，但是方法B()和方法A()共用方法A()的事务，因此，以方法A设置的超时时间为准。

在这里插入图片描述

本地事务在分布式下的问题

在这里插入图片描述

问题：

远程服务假失败：
远程服务其实成功了，由于网络故障等没有返回。比如锁库存假失败，由于网络原因导致连接超时，但是锁库存已经操作成功。此时，会导致订单数据回滚而锁库存数据没有回滚即库存扣减了。
先调用的远程服务调用成功，但是后面调用的远程服务失败，导致订单数据回滚，但已经执行成功的远程服务调用的数据库数据无法回滚。比如扣减库存成功，但是扣减之后确认订单失败，那么订单回滚但是库存服务的扣减库存是回滚不了的。

SpringBoot事务的坑（事务失效原因）

①未开启事务的自动配置

@TransactionAutoConfiguration，这个注解用来启用spring事务自动管理事务的功能，如果没写则SpringBoot不会开启自动管理事务的功能。

② 方法不是public类型的

@Transaction 可以用在类上、接口上、public方法上，如果将@Trasaction用在了非public方法上，事务将无效

③数据源未配置事务管理器

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

④自身调用问题

spring是通过aop的方式，对需要spring管理事务的bean生成了代理对象，然后通过代理对象拦截了目标方法的执行，在方法前后添加了事务的功能，所以必须通过代理对象调用目标方法的时候，事务才会起效。

看下面代码，大家思考一个问题：当外部直接调用m1的时候，m2方法的事务会生效么？

@Component
public class UserService {
    public void m1(){
        this.m2();
    }
    @Transactional
    public void m2(){
        //执行db操作
    }
}

显然不会生效，因为m1中通过this的方式调用了m2方法，而this并不是代理对象，this.m2()不会被事务拦截器拦截，所以事务是无效的，如果外部直接调用通过UserService这个bean来调用m2方法，事务是有效的，上面代码可以做一下调整，如下，@1在UserService中注入了自己，此时会产生更为严重的问题：循环依赖

@Component
public class UserService {
    @Autowired //@1
    private UserService userService;

    public void m1() {
        this.userService.m2();
    }
    @Transactional
    public void m2() {
        //执行db操作
    }
}

⑤ 异常类型错误

spring事务回滚的机制：对业务方法进行try catch，当捕获到有指定的异常时，spring自动对事务进行回滚，那么问题来了，哪些异常spring会回滚事务呢？

**并不是任何异常情况下，spring都会回滚事务，默认情况下，**RuntimeException**和*Error*的情况下，spring事务才会回滚。

也可以自定义回滚的异常类型(需继承*RuntimeException*)：

@Transactional(rollbackFor = {异常类型列表})

⑥异常被吞了

当业务方法抛出异常，spring感知到异常的时候，才会做事务回滚的操作，若方法内部将异常给吞了，那么事务无法感知到异常了，事务就不会回滚了。

如下代码，事务操作2发生了异常，但是被捕获了，此时事务并不会被回滚

@Transactional
public void m1(){
    事务操作1
    try{
        事务操作2，内部抛出了异常
    }catch(Exception e){
    }
}

⑦业务和spring事务代码必须在一个线程中

spring事务实现中使用了ThreadLocal，ThreadLocal大家应该知道吧，可以实现同一个线程中数据共享，必须是同一个线程的时候，数据才可以共享，这就要求业务代码必须和spring事务的源码执行过程必须在一个线程中，才会受spring事务的控制，比如下面代码，方法内部的子线程内部执行的事务操作将不受m1方法上spring事务的控制，这个大家一定要注意

@Transactional
public void m1() {
    new Thread() {
        一系列事务操作
    }.start();
}

最后一个是本项目中老师提到的在同一个类里面，编写两个方法，内部调用的时候，会导致事务设置失效问题。原因是没有用到代理对象的缘故。

概括：同一个对象内事务方法互调默认失效(事务是加上的，但是事务的设置失效。比如说：设置超时时间)，原因：绕过了代理对象，因为Spring使用事务是利用了AOP，加事务是通过代理对象加的事务，而相同对象直接调用内部方法时不会重新生成代理对象（默认是this调用），也就不会为方法加上事务。

解决方案： 使用代理对象来调用事务方法

① 引入spring-boot-starter-aop(帮我们引入了aspectj)

② 开启@EnableTransactionManagement(proxyTargetClass = true)对外暴露代理对象

③ 开启@EnableAspectJAutoProxy(exposeProxy=true)开启 aspectj 动态代理功能。

④ 在使用方法时使用AopContext.currentProxy()调用方法

public void a() {
    //可以直接强制类型转换，因为AopContext.currentProxy获取的就是当前类的代理对象
    XxxServiceImpl o = (XxxServiceImpl)AopContext.currentProxy();
    o.b();
    o.c();//这里使用了o这个代理对象，其实只要我们不是直接调用c()方法都可以加上事务，因为直接调用默认是this
}
public void b() {
    System.out.println("b...");
}
public void c() {
    System.out.println("c...");
}

分布式事务背景

分布式系统经常出现以下异常：
- 机器宕机、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失……

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免，因为微服务架构中，各个服务之间互相调用难免会出现一些问题（尤其网络问题），那么如果没有实现分布式事务，就会出现数据一致性问题。

分布式cap定理和BASE理论

cap定理

CAP 原则又称 CAP 定理：指的是在一个分布式系统中以下三种性质最多只能同时实现两点，不可能三者兼顾（CP/AP）

一致性(Consistency)：
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性(Availability)：
在集群中一部分节点故障后，集群整体是否还能享用客户端的读写请求。（对数据更新具备高可用性）
分区容错性(Partition tolerance)：
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition)。
分区容错的意思是：区间通信可能失败。
比如：一台服务器放在中国，另一台服务器放在美国，这就是两个区，他们之间可能无法通信。

一般来说分区容错无法避免。因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

分布式系统中实现一致性的 raft 、paxos的raft动画演示传送门：Raft (thesecretlivesofdata.com)

Raft算法的原理说明：

首先，在Raft中一个节点有三种角色：①*追随者**(Follower)*②*候选人**(Candidate)*③*领导者**(Leader)*

一开始，所有节点都是追随者状态，如果没有领导者给他们发信息，他们可以变成候选人，候选人将会给追随者发起选举，追随者们将会投票给候选人，如果候选人得到了大多数票则它将会成为领导者。这个过程被成为：*领导选举*。

追随者是如何成为候选人的呢？首先，节点有一个*自旋超时时间*(150ms-300ms**),谁自旋结束的快谁就是候选者，候选人发起选举，如果节点在此轮选举中还没有投票，那么节点将会投票给它，一旦候选人收到大多数投票那么它将成为领导者。成为领导者之后则开始*心跳联络*，定期向节点发出我还在的消息，节点回复收到，这种状态直到领导者挂掉为止。**

所有改变将需要听从领导者，假设客户端发来一条 SET 5 命令，首先，领导者会将这条命令保存到log中，然后会将 SET 5 命令发送给它的追随者，追随者们也是将命令保存至log中，领导者接收到大多数节点的回复–已经将这条命令写入log中了，此时，所有节点日志中的这条命令都是uncommited的。然后，领导会将这条命令commit并通知它的追随者让它们也去提交。这个过程被成为：*日志复制*。

日志复制过程在分区中的体现：由于网络原因，A、B被划分为1区，C、D、E被划分为2区，1区和2区之间不能通信，A原来是领导者所以在1区它还是领导者，2区经过多轮选举选出了新的领导者，现在有Client1给1区发 SET 10 的命令，A保存命令至日志然后通知B也保存日志，但是通知没有得到大多数节点的回复因此是uncommited的状态，Client2给2区发 SET 100 命令，2区领导者保存命令至日志，同时通知其它节点页保存命令至日志并且收到大多数节点的回复，2区领导者将会commit并会通知其它节点也去commit的。最终，1区和2区的通信回复了，由于2区的领导者是经过多轮选举选出的所以它成为了所以节点的领导者，原来1区的领导者就变成了追随者，1区A、B节点发现跟领导者的日志不一致，马上回滚日志并更新新的日志和提交，至此所有节点的数据是一致的。

CP面临的问题

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 99.99999%（N 个 9），即保证 P 和 A，舍弃 C。

BASE理论

它是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以适当的采取弱一致性即最终一致性。

BASE 是指：

基本可用(Basically Available)
- 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性(例如：响应时间、功能上的可用性)，允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。
  - 响应时间上的损失：正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1～2秒。
  - 功能上的损失：购物网站在购物高峰（如双十一时），为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态(Soft State)
- 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。
最终一致性(Nventual Consistency)
- 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

对于关系型数据库，要求更新过的数据能够被后续的访问都能看到，这是强一致性。
如果能容忍后续的部分或者全部访问不到，则是弱一致性。
如果经过一段时间后要求能够访问到更新后的数据，则是最终一致性。

分布式事务常见解决方案

1、2PC 模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。 MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

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

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

在这里插入图片描述

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

2、柔性事务-TCC事务补偿型方案

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

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

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

在这里插入图片描述

Try代码模块中需要Coder自己编写业务逻辑，Confirm代码块中会提交数据(例如：加2)，那么在Cancel中则需要Coder编写回滚逻辑(例如：减2)

一阶段 prepare 行为：调用自定义的 prepare 逻辑。

二阶段 commit 行为：调用自定义的 commit 逻辑。

二阶段 rollback 行为：调用自定义的 rollback 逻辑

所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中。

在这里插入图片描述

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

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

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

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

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

Seata

谷粒商城使用Seata作为分布式事务的解决方案。Seata默认使用的是2PC的模式

Seata概述:

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

TC (Transaction Coordinator) - 事务协调者
- 维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
- 定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
- 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

我们只需要使用一个 @GlobalTransactional 注解在业务方法上:

    @GlobalTransactional
    public void purchase(String userId, String commodityCode, int orderCount) {
        ......
    }

Seata的工作模式：首先，TM会告诉TC全局事务开始了，由各个事务分支向TC汇报事务的状态，是成功还是回滚。如果有一个事务分支汇报回滚，则之前提交的事务都会回滚，回滚的依赖于Seata中的Magic表，用于记录提交之前的版本和数据。

Seata大致使用流程如下：

 *  6、Seata控制分布式事务
 *      1）、每一个微服务先必须创建ubdo_log回滚日志表；
 *      2）、安装事务协调器：seata-server: https://github.com/seata/seata/releases
 *      3）、整合
 *          1、导入依赖 :spring-cloud-starter-alibaba-seata seata-all-0.7.1
 *          2、解压启动seata-server;
 *              registry.conf ：注册中心配置 修改它： registry type = "nacos"
 *              file.conf：
 *          3、所有想用到分布式事务的微服务 使用 seata DataSourceProxy代理自己的数据源
 *          4、每个微服务都必须要导入
 *                  registry.conf
 *                  file.conf   vgroup_mapping.{application.name}-fescar-service-group = "default"
 *          5、给分布式大事务的入口标注： @GlobalTransactional
 *          6、每一个小事务标注： @Transactional

Seata 环境准备

1、在每个微服务数据库里创建一个叫做undo_log（回滚日志表）的表：

CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

2、安装事务协调器：seata-server: https://github.com/seata/seata/releases

解压启动seata-server
修改 registry.conf ：注册中心配置

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa 指定注册中心
  type = "nacos"

  nacos {
    serverAddr = "localhost:8848"
    namespace = "public"
    cluster = "default"
  }

启动 seata-server

hgw@HGWdeMacBook-Air bin # sh seata-server.sh

在这里插入图片描述

项目整合Seata

1、导入依赖 :spring-cloud-starter-alibaba-seata seata-all-0.7.1

<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>

2、给分布式大事务的方法上标注@GlobalTransactional; 每一个远程的小事务用@Transactional

在 gulimall-order服务中com/atguigu/gulimall/order/service/impl/OrderServiceImpl.java 的 SubmitOrderResponseVo方法加上@GlobalTransactional 注解

@GlobalTransactional
@Transactional  // 本地事务，在分布式系统，只能控制住自己的回滚，控制不了其他服务的回滚。
@Override
public SubmitOrderResponseVo submitOrder(OrderSubmitVo vo) {
  //.....
}

3、配置代理数据源，所有想要用到分布式事务的微服务都需要使用 seata的DataSourceProxy代理自己的数据源。因为 Seata 通过代理数据源实现分支事务，如果没有注入，事务无法回滚（但是高版本之后无需配置数据源，这步可忽略）。添加“com.atguigu.gulimall.order.config.MySeataConfig”类，代码如下：

package com.atguigu.gulimall.order.config;

@Configuration
public class MySeataConfig {
    @Autowired
    DataSourceProperties dataSourceProperties;

    @Bean
    public DataSource dataSource(DataSourceProperties dataSourceProperties){
        //得到原来的数据源
        HikariDataSource dataSource = dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
        if (StringUtils.hasText(dataSourceProperties.getName())){
            dataSource.setPoolName(dataSourceProperties.getName());
        }
        //创建Seata的数据源，把老数据源传入进行包装
        return new DataSourceProxy(dataSource);
    }
}

4、每个微服务都必须要导入registry.conf（是配置Seata信息的配置文件，这里我们需要将registry.conf中的type修改为nacos并修改serverAddr为本机注册中心地址）和file.conf这两个文件，这两个文件在Seata-server中。

分别给gulimall-order和gulimall-ware加上file.conf和registry.conf这两个配置，并修改file.conf（命名规则：服务名-fescar-service-group，这里file.conf中的服务名要和yml文件中的配置的服务名一致）

在这里插入图片描述

5、给所有还不使用seata的服务排除掉，修改其pom.xml文件

<exclusion>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</exclusion>

最终一致性库存解锁逻辑

seata的AT（2PC）模式并不适合于高并发场景，原因在于：AT模式的实现是通过加锁实现的，那么并发环境下就会导致导致整个线程变成串行化执行，那么并发效率就太低下了

**seata的TCC模式、SAGA模式可以自行学习：**传送门：https://github.com/seata/seata-samples

谷粒商城采用的是消息队列解锁库存，保证最终一致性而非seata 的AT的模式，前面的AT模式只是带大家体验一下。

但是前面的AT模式在我们的项目中也是有适用场景的，比如我们保存商品信息时，也会调用很多远程服务（库存，积分等），但是增加商品并不是高并发的，这里就可以使用AT模式。所有模式没有好坏，具体使用要看应用场景。

但是下订单解锁库存是属于高并发的，因此我们需要选择一个柔性事务，最终选择了第四种解决方案：可靠消息+最终一致性方案。因为这种方案引入了消息队列，哪怕任务执行失败，只需要向队列中发送一个失败消息即可，并不怎么影响并发下的其他下单请求的执行。其具体实现使用了消息队列中的延时队列（TTL+死信进行实现），因为我们订单有过期时间（一般半小时），过了过期时间还不支付就会取消订单。即未付款订单，超过一定时间后，系统自动取消订单并解锁库存；

感谢耐心看到这里的同学，觉得文章对您有帮助的话希望同学们不要吝啬您手中的赞，动动您智慧的小手，您的认可就是我创作的动力！
之后还会勤更自己的学习笔记，感兴趣的朋友点点关注哦。