• 分布式事务Seata

    目录

    一、分布式事务的认识

    事务的ACID原则

    CAP定理

     BASE理论

    二、Seata简介、安装和部署

    1.初识Seata

     2.下载Seata（1.4.2版本，其他版本可能与本章教程冲突）

    3.修改配置文件 

    4.在nacos添加配置

    5.创建配置文件中的数据库表

    6.启动TC服务

     三、微服务集成seata

      1.首先，我们需要在微服务中引入seata依赖：

       2.修改配置文件

    四、Seata中的四种不同的事务模式

    1.XA模式

    XA模式的优点是什么？

    XA模式的缺点是什么？

    XA模式实现步骤如下：

    2.AT模式

    AT与XA的区别

    AT模式的优点：

    AT模式的缺点：

    AT模式实现步骤如下： 

    3.TCC模式

    TCC模式的每个阶段是做什么的？

    TCC的优点是什么？

    TCC的缺点是什么？

    TCC模式的实现步骤如下：

    4.SAGA模式

    Saga也分为两个阶段：

    SAGA模式优点：

    SAGA模式缺点：

    5.四种模式对比

    五、TC服务的高可用和异地容灾

    高可用实现步骤：

    1.模拟异地容灾的TC集群

    2.将事务组映射配置到nacos

    3.微服务读取nacos配置

    一、分布式事务的认识

    分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

    事务的ACID原则

     在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。例：

    CAP定理

    1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：

    • Consistency(一致性): 用户访问分布式系统中的任意节点，得到的数据必须一致；
    • Availability(可用性): 用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝;
    • Partition tolerance(分区容错性): 因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区，在集群出现分区时，整个系统也要持续对外提供服务。

     Eric Brewer 说，分布式系统无法同时满足这三个指标。 这个结论就叫做 CAP 定理。

     BASE理论

    BASE理论是对CAP的一种解决思路，包含三个思想：

    • Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
    • Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
    • Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

    而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：

    1. AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
    2. CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

    二、Seata简介、安装和部署

    1.初识Seata

    Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。 官网地址：http://seata.io/其中的文档、播客中提供了大量的使用说明、源码分析。

     Seata事务管理中有三个重要的角色：

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

     Seata提供了四种不同的分布式事务解决方案：

    • XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
    • TCC模式：最终一致的分阶段事务模式，有业务侵入
    • AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
    • SAGA模式：长事务模式，有业务侵入

     2.下载Seata（1.4.2版本，其他版本可能与本章教程冲突）

    下载地址：https://github.com/seata/seata/releases

     下载解压后：

    3.修改配置文件 

    修改conf目录下的 registry.conf 文件(直接复制替换)

    1. registry {
    2.   # tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
    3.   type = "nacos"
    4.  
    5.   nacos {
    6.     # seata tc 服务注册到 nacos的服务名称，可以自定义
    7.     application = "seata-tc-server"
    8.     serverAddr = "127.0.0.1:8848"
    9.     group = "DEFAULT_GROUP"
    10.     namespace = ""
    11.     cluster = "SH"
    12.     username = "nacos"
    13.     password = "nacos"
    14.   }
    15. }
    16.  
    17. config {
    18.   # 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
    19.   type = "nacos"
    20.   # 配置nacos地址等信息
    21.   nacos {
    22.     serverAddr = "127.0.0.1:8848"
    23.     namespace = ""
    24.     group = "SEATA_GROUP"
    25.     username = "nacos"
    26.     password = "nacos"
    27.     dataId = "seataServer.properties"
    28.   }
    29. }

    4.在nacos添加配置

    特别注意，为了让tc服务的集群可以共享配置，我们选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。

     配置内容是(其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。)：

    1. # 数据存储方式，db代表数据库
    2. store.mode=db
    3. store.db.datasource=druid
    4. store.db.dbType=mysql
    5. store.db.driverClassName=com.mysql.jdbc.Driver
    6. store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
    7. store.db.user=root
    8. store.db.password=123
    9. store.db.minConn=5
    10. store.db.maxConn=30
    11. store.db.globalTable=global_table
    12. store.db.branchTable=branch_table
    13. store.db.queryLimit=100
    14. store.db.lockTable=lock_table
    15. store.db.maxWait=5000
    16. # 事务、日志等配置
    17. server.recovery.committingRetryPeriod=1000
    18. server.recovery.asynCommittingRetryPeriod=1000
    19. server.recovery.rollbackingRetryPeriod=1000
    20. server.recovery.timeoutRetryPeriod=1000
    21. server.maxCommitRetryTimeout=-1
    22. server.maxRollbackRetryTimeout=-1
    23. server.rollbackRetryTimeoutUnlockEnable=false
    24. server.undo.logSaveDays=7
    25. server.undo.logDeletePeriod=86400000
    26.  
    27. # 客户端与服务端传输方式
    28. transport.serialization=seata
    29. transport.compressor=none
    30. # 关闭metrics功能，提高性能
    31. metrics.enabled=false
    32. metrics.registryType=compact
    33. metrics.exporterList=prometheus
    34. metrics.exporterPrometheusPort=9898

    5.创建配置文件中的数据库表

    特别注意：tc服务在管理分布式事务时，需要记录事务相关数据到数据库中，你需要提前创建好这些表。

    1. -- ----------------------------
    2. -- 分支事务表
    3. -- ----------------------------
    4. DROP TABLE IF EXISTS `branch_table`;
    5. CREATE TABLE `branch_table`  (
    6.   `branch_id` bigint(20) NOT NULL,
    7.   `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    8.   `transaction_id` bigint(20) NULL DEFAULT NULL,
    9.   `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    10.   `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    11.   `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    12.   `status` tinyint(4) NULL DEFAULT NULL,
    13.   `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    14.   `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    15.   `gmt_create` datetime(6) NULL DEFAULT NULL,
    16.   `gmt_modified` datetime(6) NULL DEFAULT NULL,
    17.   PRIMARY KEY (`branch_id`) USING BTREE,
    18.   INDEX `idx_xid`(`xid`) USING BTREE
    19. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
    20.  
    21. -- ----------------------------
    22. -- 全局事务表
    23. -- ----------------------------
    24. DROP TABLE IF EXISTS `global_table`;
    25. CREATE TABLE `global_table`  (
    26.   `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    27.   `transaction_id` bigint(20) NULL DEFAULT NULL,
    28.   `status` tinyint(4) NOT NULL,
    29.   `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    30.   `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    31.   `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    32.   `timeout` int(11) NULL DEFAULT NULL,
    33.   `begin_time` bigint(20) NULL DEFAULT NULL,
    34.   `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
    35.   `gmt_create` datetime NULL DEFAULT NULL,
    36.   `gmt_modified` datetime NULL DEFAULT NULL,
    37.   PRIMARY KEY (`xid`) USING BTREE,
    38.   INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
    39.   INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
    40. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

    6.启动TC服务

    进入bin目录，运行其中的seata-server.bat即可（默认的端口是8091）：

    如需修改端口可以使用以下命令运行：

    seata-server.bat -p 8091

    启动成功后，seata-server应该已经注册到nacos注册中心了。

    打开浏览器，访问nacos地址：http://localhost:8848，然后进入服务列表页面，可以看到seata-tc-server的信息：

    ​​​​​​​

     三、微服务集成seata

      1.首先，我们需要在微服务中引入seata依赖：

    1. <dependency>
    2.     <groupId>com.alibaba.cloudgroupId>
    3.     <artifactId>spring-cloud-starter-alibaba-seataartifactId>
    4.     <exclusions>
    5.         
    6.         <exclusion>
    7.             <artifactId>seata-spring-boot-starterartifactId>
    8.             <groupId>io.seatagroupId>
    9.         exclusion>
    10.     exclusions>
    11. dependency>
    13. <dependency>
    14.     <groupId>io.seatagroupId>
    15.     <artifactId>seata-spring-boot-starterartifactId>
    16.     <version>${seata.version}version>
    17. dependency>

    2.修改配置文件

    需要修改application.yml文件，添加一些配置：

    1. seata:
    2.   registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    3.     # 参考tc服务自己的registry.conf中的配置
    4.     type: nacos
    5.     nacos: # tc
    6.       server-addr: 127.0.0.1:8848
    7.       namespace: ""
    8.       group: DEFAULT_GROUP
    9.       application: seata-tc-server # tc服务在nacos中的服务名称
    10.       cluster: SH
    11.   tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
    12.   service:
    13.     vgroup-mapping: # 事务组与TC服务cluster的映射关系
    14.       seata-demo: SH

    微服务如何根据这些配置寻找TC的地址呢？

    我们知道注册到Nacos中的微服务，确定一个具体实例需要四个信息：

    • namespace：命名空间
    • group：分组
    • application：服务名
    • cluster：集群名

    namespace为空，就是默认的public，结合起来，TC服务的信息就是：public@DEFAULT_GROUP@seata-tc-server@SH，这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。

    四、Seata中的四种不同的事务模式

    1.XA模式

    XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

    XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

    正常情况：

    异常情况： 

     

    一阶段：

    • 事务协调者通知每个事物参与者执行本地事务

    • 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

    二阶段：

    • 事务协调者基于一阶段的报告来判断下一步操作

      • 如果一阶段都成功，则通知所有事务参与者，提交事务

      • 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

     Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

    RM一阶段的工作：

         ① 注册分支事务到TC

         ② 执行分支业务sql但不提交

         ③ 报告执行状态到TC

    TC二阶段的工作：

    • TC检测各分支事务执行状态

      a.如果都成功，通知所有RM提交事务

      b.如果有失败，通知所有RM回滚事务

    RM二阶段的工作：

    • 接收TC指令，提交或回滚事务

    XA模式的优点是什么？

    • 事务的强一致性，满足ACID原则。

    • 常用数据库都支持，实现简单，并且没有代码侵入

    XA模式的缺点是什么？

    • 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差

    • 依赖关系型数据库实现事务

    XA模式实现步骤如下：

    1）修改application.yml文件（每个参与事务的微服务），开启XA模式：

    1. seata:
    2.   data-source-proxy-mode: XA

    2）给发起全局事务的入口方法添加@GlobalTransactional注解:

    2.AT模式

    AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

    ​​​​​​​

    阶段一RM的工作：

    • 注册分支事务
    • 记录undo-log（数据快照）
    • 执行业务sql并提交
    • 报告事务状态

    阶段二提交时RM的工作：删除undo-log即可

    阶段二回滚时RM的工作：根据undo-log恢复数据到更新前

    AT与XA的区别

    简述AT模式与XA模式最大的区别是什么？

    • XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。

    • XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。

    • XA模式强一致；AT模式最终一致。

    AT模式的优点：

    • 一阶段完成直接提交事务，释放数据库资源，性能比较好

    • 利用全局锁实现读写隔离

    • 没有代码侵入，框架自动完成回滚和提交

    AT模式的缺点：

    • 两阶段之间属于软状态，属于最终一致

    • 框架的快照功能会影响性能，但比XA模式要好很多

    AT模式实现步骤如下： 

    1）导入数据库表，记录全局锁

    2）修改application.yml文件，将事务模式修改为AT模式即可：

    1. seata:
    2.   data-source-proxy-mode: AT # 默认就是AT

    3.TCC模式

    TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

    • Try：资源的检测和预留；

    • Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。

    • Cancel：预留资源释放，可以理解为try的反向操作。

    TCC模式的每个阶段是做什么的？

    • Try：资源检查和预留

    • Confirm：业务执行和提交

    • Cancel：预留资源的释放

    TCC的优点是什么？

    • 一阶段完成直接提交事务，释放数据库资源，性能好

    • 相比AT模型，无需生成快照，无需使用全局锁，性能最强

    • 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

    TCC的缺点是什么？

    • 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦

    • 软状态，事务是最终一致

    • 需要考虑Confirm和Cancel的失败情况，做好幂等处理

    TCC模式的实现步骤如下：

    1）TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明

    1. @LocalTCC
    2. public interface AccountTCCService {
    3.  
    4.     @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    5.     void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
    6.                 @BusinessActionContextParameter(paramName = "money")int money);
    7.  
    8.     boolean confirm(BusinessActionContext ctx);
    9.  
    10.     boolean cancel(BusinessActionContext ctx);
    11. }

    2）编写实现类

    4.SAGA模式

    Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。

    其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。

    Seata官网对于Saga的指南：https://seata.io/zh-cn/docs/user/saga.html

    在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

    分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

    Saga也分为两个阶段：

    • 一阶段：直接提交本地事务

    • 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

    SAGA模式优点：

    • 事务参与者可以基于事件驱动实现异步调用，吞吐高

    • 一阶段直接提交事务，无锁，性能好

    • 实现简单

    SAGA模式缺点：

    • 软状态持续时间不确定，时效性差

    • 没有锁，没有事务隔离，会有脏写

    5.四种模式对比

    我们从以下几个方面来对比四种实现：

    1. 一致性：能否保证事务的一致性？强一致还是最终一致？
    2. 隔离性：事务之间的隔离性如何？
    3. 代码侵入：是否需要对业务代码改造？
    4. 性能：有无性能损耗？
    5. 场景：常见的业务场景

    五、TC服务的高可用和异地容灾

    搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。但集群并不能确保100%安全，万一集群所在机房故障怎么办？所以如果要求较高，一般都会做异地多机房容灾。

    比如一个TC集群在上海，另一个TC集群在杭州：

    微服务基于事务组（tx-service-group)与TC集群的映射关系，来查找当前应该使用哪个TC集群。当SH集群故障时，只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。

    高可用实现步骤：

    1.模拟异地容灾的TC集群

    计划启动两台seata的tc服务节点：

    将seata目录复制一份，起名为seata2，修改seata2/conf/registry.conf内容如下：

    1. registry {
    2.   # tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
    3.   type = "nacos"
    4.  
    5.   nacos {
    6.     # seata tc 服务注册到 nacos的服务名称，可以自定义
    7.     application = "seata-tc-server"
    8.     serverAddr = "127.0.0.1:8848"
    9.     group = "DEFAULT_GROUP"
    10.     namespace = ""
    11.     cluster = "HZ"
    12.     username = "nacos"
    13.     password = "nacos"
    14.   }
    15. }
    16.  
    17. config {
    18.   # 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
    19.   type = "nacos"
    20.   # 配置nacos地址等信息
    21.   nacos {
    22.     serverAddr = "127.0.0.1:8848"
    23.     namespace = ""
    24.     group = "SEATA_GROUP"
    25.     username = "nacos"
    26.     password = "nacos"
    27.     dataId = "seataServer.properties"
    28.   }
    29. }

     进入bin目录启动：

    .\seata-server.bat -p 8092

    2.将事务组映射配置到nacos

    接下来，需要将tx-service-group与cluster的映射关系都配置到nacos配置中心。

    新建一个配置：

    1. # 事务组映射关系
    2. service.vgroupMapping.seata-demo=SH
    3.  
    4. service.enableDegrade=false
    5. service.disableGlobalTransaction=false
    6. # 与TC服务的通信配置
    7. transport.type=TCP
    8. transport.server=NIO
    9. transport.heartbeat=true
    10. transport.enableClientBatchSendRequest=false
    11. transport.threadFactory.bossThreadPrefix=NettyBoss
    12. transport.threadFactory.workerThreadPrefix=NettyServerNIOWorker
    13. transport.threadFactory.serverExecutorThreadPrefix=NettyServerBizHandler
    14. transport.threadFactory.shareBossWorker=false
    15. transport.threadFactory.clientSelectorThreadPrefix=NettyClientSelector
    16. transport.threadFactory.clientSelectorThreadSize=1
    17. transport.threadFactory.clientWorkerThreadPrefix=NettyClientWorkerThread
    18. transport.threadFactory.bossThreadSize=1
    19. transport.threadFactory.workerThreadSize=default
    20. transport.shutdown.wait=3
    21. # RM配置
    22. client.rm.asyncCommitBufferLimit=10000
    23. client.rm.lock.retryInterval=10
    24. client.rm.lock.retryTimes=30
    25. client.rm.lock.retryPolicyBranchRollbackOnConflict=true
    26. client.rm.reportRetryCount=5
    27. client.rm.tableMetaCheckEnable=false
    28. client.rm.tableMetaCheckerInterval=60000
    29. client.rm.sqlParserType=druid
    30. client.rm.reportSuccessEnable=false
    31. client.rm.sagaBranchRegisterEnable=false
    32. # TM配置
    33. client.tm.commitRetryCount=5
    34. client.tm.rollbackRetryCount=5
    35. client.tm.defaultGlobalTransactionTimeout=60000
    36. client.tm.degradeCheck=false
    37. client.tm.degradeCheckAllowTimes=10
    38. client.tm.degradeCheckPeriod=2000
    39.  
    40. # undo日志配置
    41. client.undo.dataValidation=true
    42. client.undo.logSerialization=jackson
    43. client.undo.onlyCareUpdateColumns=true
    44. client.undo.logTable=undo_log
    45. client.undo.compress.enable=true
    46. client.undo.compress.type=zip
    47. client.undo.compress.threshold=64k
    48. client.log.exceptionRate=100

     3.微服务读取nacos配置

    1. seata:
    2.   config:
    3.     type: nacos
    4.     nacos:
    5.       server-addr: 127.0.0.1:8848
    6.       username: nacos
    7.       password: nacos
    8.       group: SEATA_GROUP
    9.       data-id: client.properties

    重启微服务，现在微服务到底是连接tc的SH集群，还是tc的HZ集群，都统一由nacos的client.properties来决定了。

    ​​​​​​​

  • 相关阅读:
    Java面试之数据库面试题
    CCAA 认证通用基础卷之（一）合格评定基础 第二章合格评定与国家质量基础设施 NQI （National Quality Infrastructure）
    电路的基本定律——基尔霍夫定律
    使用Piwigo管理您的照片
    Dockerfile文件解释
    torch.optim.Adam() 函数用法
    Extended Choice Parameter拓展参数化构建
    【LeetCode】《LeetCode 101》第十三章：链表
    Learning from Unlabeled 3D Environments forVision-and-Language Navigation
    红黑树刷题（上）
  • 原文地址：https://blog.csdn.net/yueyue763184/article/details/128044674