1.Springboot之分布式事务框架Seata实现原理源码分析
2.BoltDB源码解析（二）事务
3.MySQL XA事务源码分析
4.详解rocketMQ事务消息
5.Spring事务注解@Transactional原理解析
6.spring—AOP与事务

Springboot之分布式事务框架Seata实现原理源码分析

       在SpringBoot环境下的事务事务分布式事务框架Seata实现原理涉及到了代理数据源、注册代理Bean以及全局事务拦截器等关键环节。源码源码下面我们将逐步解析其核心逻辑。分析分析

       首先，事务事务Seata通过GlobalTransactionScanner来注册项目中所有带有@GlobalTransactional注解的源码源码方法类。该扫描器是分析分析云检测源码一个实现了BeanPostProcessor接口的类，它能够在Spring容器初始化时进行后置处理，事务事务从而实现全局事务的源码源码管理。

       GlobalTransactionScanner实际上是分析分析一个InstantiationAwareBeanPostProcessor，它在实例化Bean前执行postProcessBeforeInstantiation方法，事务事务在实例化后执行postProcessAfterInstantiation方法，源码源码并在属性填充时执行postProcessProperties方法。分析分析尽管GlobalTransactionScanner类本身并未覆盖这3个方法，事务事务但在父类的源码源码实现中，这些方法用于处理Bean的分析分析实例化和属性设置过程。

       关键在于postProcessAfterInitialization方法中实现的wrapIfNecessary方法，该方法在GlobalTransactionScanner类中被重写。当方法执行到existsAnnotation方法判断类方法是否带有@GlobalTransactional注解时，如果存在则创建一个GlobalTransactionalInterceptor作为拦截器处理全局事务。

       在创建代理数据源时，Seata通过DataSourceProxy对系统默认数据源进行代理处理。通过shouldSkip方法判断当前bean是否需要被代理，如果bean是SeataProxy的子类且不是DataSource的子类且不在excludes集合中，则进行代理，从而代理当前系统的默认数据源对象。

       全局事务拦截器主要负责全局事务的发起、执行和回滚。在执行全局事务的方法被代理时，具体的执行拦截器是GlobalTransactionalInterceptor。该拦截器处理全局事务的逻辑，包括获取全局事务、开始全局事务、执行本地业务、提交本地事务、记录undo log、提交数据更新等步骤。其中，laya游戏源码提交本地事务时会向TC（Transaction Coordinator）注册分支并提交本地事务，整个过程确保了分布式事务的一致性。

       当全局事务中任何一个分支发生异常时，事务将被回滚。参与全局事务的组件在异常发生时执行特定的回滚逻辑，确保事务一致性。在Seata的实现中，异常处理机制确保了事务的回滚能够正确执行。

       Seata还提供了XID（Transaction Identifier）的传递机制，通过RestTemplate和Feign客户端进行服务间的调用，确保分布式系统中各个服务能够共享和处理全局事务。RestTemplate在请求头中放置TX_XID头信息，而Feign客户端通过从调用链中获取Feign.Builder，最终通过SeataHystrixFeignBuilder.builder方法实现XID的传递。

       在被调用端（通过Feign调用服务），Seata自动配置会创建数据源代理，使得事务方法执行时能够获取到连接对象，而这些连接对象已经被代理成DataSourceProxy。SeataHandlerInterceptor拦截器对所有请求进行拦截，从Header中获取TX_XID，参与者的XID绑定到上下文中，通过ConnectionProxy获取代理连接对象。在数据库操作中，XID绑定到ConnectionContext，执行SQL语句时通过StatementProxy或PreparedStatementProxy代理连接，从而完成全局事务的处理。

       综上所述，Seata通过一系列复杂的逻辑和机制，实现了SpringBoot环境下的分布式事务管理，确保了分布式系统中数据的一致性和可靠性。

BoltDB源码解析（二）事务

       最近几天一直在研究BoltDB的代码，现在对它有了更深入的了解。这篇主要介绍BoltDB的事务处理。

       BoltDB的事务主要分为两类：一类是只读事务，另一类是读写事务。只读事务仅允许读取操作，信用网站源码而读写事务则可以同时进行读取和写入操作。在并发控制方面，BoltDB允许任意多个只读事务同时进行，但读写事务只能有一个。

       BoltDB支持一定程度的多版本并发控制（MVCC），这意味着读事务不会阻塞写事务，反之亦然。在程序运行过程中，你可能会发现多个读事务和一个写事务在同时进行。

       只读事务是通过db.View方法执行的，具体代码如下：

       Bolt的注释非常清晰，每一步都标明了具体操作。db.begin是新建一个transaction，而fn参数是用户传递的事务主体函数。

       注意，只读事务不会调用transaction的commit函数，除非发生error，此时需要调用t.Rollback()进行清理工作。

       读写事务是通过db.update执行的，整体上和View的代码类似，但是会创建一个读写事务。

       读写事务如果没有发生错误，最后会调用Commit方法，将事务进行的修改持久化到DB文件里，实现事务ACID特性里的“D"。

       BoltDB使用B-tree作为磁盘数据结构，在事务commit时，所有在内存中的修改都要持久化到磁盘上。在事务commit时，所有修改都需要持久化到多个新page里。

       读事务实现得比较简单，就是在基于mmap的B-tree上搜索到具体的key，返回对应的value。为了提升性能，BoltDB全程尽量避免copy。

       写事务比读事务要复杂，游戏源码赌博BoltDB如果需要修改一个page上的数据，首先会通过B-tree搜索定位到具体的key所在的leaf page，但它不会直接在这个page上修改，而是把这个page的数据copy到一个叫node的内存结构体里，修改是在node结构体里做的。

       在写事务中，所有的修改都暂存在内存里，在事务commit之前不会持久化。在事务commit的时候，所有的修改都要持久化。

       因此，BoltDB的使用建议是，一个事务做的事情不要太多，这样不必耗费太多内存保存中间状态，commit也不至于耗时太多。

MySQL XA事务源码分析

       事务类型外部 XA PREPARE 流程

       省流版：

       详细版：

       外部 XA COMMIT 过程

       省流版：

       详细版：

       外部 XA 2PC 阶段 Log 落盘顺序

       ------------------- XA PREPARE START -------------------------

       ------------------- XA PREPARE END -------------------------

       .

       .

       .

       .

       .

       .

       ------------------- XA COMMIT START -------------------------

       ------------------- XA COMMIT END -------------------------

       本地事务 commit 流程

       省流版

       与外部 XA PREPARE 2PC 的不同

       与外部 XA COMMIT 的不同

       详细版：

       ------------------- PREPARE START -------------------------

       ------------------- PREPARE END -------------------------

       ------------------- COMMIT START -------------------------

       ------------------- COMMIT END -------------------------

       外部 XA ROLLBACK 流程

       省流版（Not Prepared Rollback 和 Prepared Rollback 的不同之处）

       详细版

       Not Prepared Rollback（在 end - prepare 之间 rollback）

       Prepared Rollback（在 prepare 之后 rollback）

       外部 XA RECOVERY 流程

       省流版

       详细版

       本地事务 RECOVERY 流程

       省流版

       详细版

       为什么只遍历最后一个binlog文件：

       rotate 到新的 binlog 文件前，redo log 强制落盘，因此redo commit记录会落盘，保证老的binlog文件没有正在提交的事务

详解rocketMQ事务消息

       RocketMQ，一款分布式消息队列系统，提供高可靠性和高吞吐量的特性，适用于多种分布式场景。其中，事务消息功能是其一大亮点，旨在满足需要保证事务一致性场景的需求。本文将深入解析RocketMQ事务消息的场景、示例、原理及源码实现。

       首先，什么是事务消息？在分布式系统中，事务往往由多个操作组成，这些操作应被视为整体，执行结果要么全部成功，要么全部失败。当消息作为事务的一部分时，事务消息需要确保在消费者端要么全部被消费，源码手机表白要么全部被丢弃，以维持事务的一致性。RocketMQ提供的事务消息正是为满足这一需求而设计的。

       事务消息的应用场景广泛，例如在分布式系统中进行跨服务的事务处理、批量数据处理的可靠性保证以及数据库事务一致性维护。通过将消息发送和本地事务操作合并为一个事务，事务消息确保了消息与本地事务结果的一致性。

       接下来，我们通过一个简单的订单服务示例来了解事务消息的用法。在订单服务中，需要同时更新订单信息并发送订单变更消息，采用事务消息可以保证消息和订单信息的同步更新，确保事务的一致性。

       在实现上，通过RocketMQ的生产者和自定义事务监听器，将消息发送与本地事务执行整合，当本地事务执行成功或失败时，监听器会返回相应的状态，进而影响RocketMQ对消息状态的处理。在源码实现层面，RocketMQ事务消息主要涉及三个关键类：TransactionMQProducer、TransactionListener和TransactionListenerImpl。

       TransactionMQProducer用于设置事务监听器，TransactionListener接口定义了本地事务执行与检查方法，而TransactionListenerImpl实现类则负责根据业务逻辑执行本地事务并返回状态。通过这些类的协作，RocketMQ可以完成事务消息的准备、提交或回滚过程，从而确保消息传递的一致性和可靠性。

       综上所述，RocketMQ事务消息是分布式系统中保证事务一致性的重要工具。通过其原理、示例和源码实现的详细解析，我们可以深入了解事务消息在实际应用中的价值，进而更好地在项目中利用其特性，提升消息传递的可靠性和稳定性。

Spring事务注解@Transactional原理解析

       事务管理是应用系统开发的关键部分，Spring 提供了丰富且方便的事务管理解决方案，显著简化了代码编写并提高了可维护性。

       以原生JDBC事务处理与Spring的事务处理进行对比，原生代码中充斥着复杂且重复的事务管理逻辑，而使用Spring则通过简单的注解即可实现。例如，针对保存三张表数据的需求（country、city、category），若采用原生JDBC，代码会显得冗长且难于维护。而在Spring中，通过设置特定的事务属性，如`Propagation.REQUIRES_NEW`，只需在对应方法上添加`@Transactional`注解，Spring便会自动处理事务，极大简化了代码。

       Spring的声明式事务机制，通过`TransactionAutoConfiguration`类自动配置事务相关组件，并由`TransactionInterceptor`类执行事务处理逻辑，实现了对带有`@Transactional`注解的方法的代理。此单例对象确保了所有事务逻辑的一致性和高效性。

       在使用`@Transactional`注解时，需要关注其属性的含义，包括`propagation`和`isolation`。`propagation`属性定义了事务的传播行为，如是否需要新事务、是否在当前事务中进行等。`isolation`属性则决定了事务的隔离级别，确保不同事务之间数据的一致性。

       进一步深入了解`@Transactional`注解的实现细节，可参阅Spring源码。GitHub和Gitee提供该代码的同步版本，方便开发者深入研究。

spring—AOP与事务

        title: spring——AOP与事务.md

        date: -- ::

        categories: [Spring]

        tags: [AOP,事务]

        toc: true

        先列出源码中比较重点的几个类：

        1、<aop:before method="before" pointcut-ref="myMethods"/>包装成一个advisor

        2、AspectJAwareAdvisorAutoProxyCreator，当实例化所有bean都会执行到AspectJAwareAdvisorAutoProxyCreatorç±»

        它会检测bean是否advisor以及advice存在，如果有就说明这个bean有切面，有切面那么就会生成代理

        3、jdk的代理，bean里面的所有advisor加入到proxyFactory。

        4、jdkDynamicProxy invoke，拿到bean里面的所有Interceptor，会循环proxyFactory里面的所有advisor

        里面有advice，里面的advice有两种类型，要么是advice，要么是MethodInterceptor类型的

        5、当代理对象调用方式，是一个MethodInterceptor类型的类的链式调用过程，直到容器的大小和索引一致的时候调用JoinPoint目标方法

        before：this.advice.before(),invocation.processd();

        装配参数，切面里面before方法的method对象，method.getParamterTypes()[0]

        最终会把advice封装成MethodInterceptor类型的对象

        程序执行的某个特定位置：如类开始初始化前、类初始化后、类某个方法调用前、调用后、方法抛出异常后。一个类或一段程序代码拥有一些具有边界性质的特定点，这些点中的特定点就称为“连接点”。Spring仅支持方法的连接点，即仅能在方法调用前、方法调用后、方法抛出异常时以及方法调用前后这些程序执行点织入增强。连接点由两个信息确定：第一是用方法表示的程序执行点；第二是用相对点表示的方位。

        每个程序类都拥有多个连接点，如一个拥有两个方法的类，这两个方法都是连接点，即连接点是程序类中客观存在的事物。AOP通过“切点”定位特定的连接点。连接点相当于数据库中的记录，而切点相当于查询条件。切点和连接点不是一对一的关系，一个切点可以匹配多个连接点。在Spring中，切点通过org.springframework.aop.Pointcut接口进行描述，它使用类和方法作为连接点的查询条件，Spring AOP的规则解析引擎负责切点所设定的查询条件，找到对应的连接点。其实确切地说，不能称之为查询连接点，因为连接点是方法执行前、执行后等包括方位信息的具体程序执行点，而切点只定位到某个方法上，所以如果希望定位到具体连接点上，还需要提供方位信息。

        增强是织入到目标类连接点上的一段程序代码，在Spring中，增强除用于描述一段程序代码外，还拥有另一个和连接点相关的信息，这便是执行点的方位。结合执行点方位信息和切点信息，我们就可以找到特定的连接点。

        增强逻辑的织入目标类。如果没有AOP，目标业务类需要自己实现所有逻辑，而在AOP的帮助下，目标业务类只实现那些非横切逻辑的程序逻辑，而性能监视和事务管理等这些横切逻辑则可以使用AOP动态织入到特定的连接点上。

        引介是一种特殊的增强，它为类添加一些属性和方法。这样，即使一个业务类原本没有实现某个接口，通过AOP的引介功能，我们可以动态地为该业务类添加接口的实现逻辑，让业务类成为这个接口的实现类。

        织入是将增强添加对目标类具体连接点上的过程。AOP像一台织布机，将目标类、增强或引介通过AOP这台织布机天衣无缝地编织到一起。根据不同的实现技术，AOP有三种织入的方式：

        a、编译期织入，这要求使用特殊的Java编译器。

        b、类装载期织入，这要求使用特殊的类装载器。

        c、动态代理织入，在运行期为目标类添加增强生成子类的方式。

        Spring采用动态代理织入，而AspectJ采用编译期织入和类装载期织入。

        一个类被AOP织入增强后，就产出了一个结果类，它是融合了原类和增强逻辑的代理类。根据不同的代理方式，代理类既可能是和原类具有相同接口的类，也可能就是原类的子类，所以我们可以采用调用原类相同的方式调用代理类。

        切面由切点和增强（引介）组成，它既包括了横切逻辑的定义，也包括了连接点的定义，Spring AOP就是负责实施切面的框架，它将切面所定义的横切逻辑织入到切面所指定的连接点中。

        advisor： pointCut advice

        一类功能的增强

        around方法里面代码切面

        事务切面

        缓存切面

        日志切面

        事务（Transaction），一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元）。

        大致流程形如

        数据库事务拥有几大特性：

        事务的四大特性：

        事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做

        事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。

        一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

        也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

        个人理解，事务在Spring中是借助AOP技术来实现的，可以作为AOP中的一个事务切面。spring源码对事务的处理逻辑，自己研究吧！

        ORM框架中以Mybatis为例，事务处理就是用到了一个类Transaction，部分源码如下

        可以看出Transaction管理的就是一个connection，而connection我们很清楚是与用户会话挂钩的。

        那么关系就是Transaction 管理Connection ，而connection与 用户session一对一存在。

        在springBoot中，只需要加入POM就可以了，配合注解使用即可。

        接下来就是事务的控制了。

        首先事务有几大传播属性：

        其中最常见的，用得最多就 PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、 PROPAGATION_NESTED 这三种。事务的传播属性是 spring 特有的，是 spring 用来控制方法事务的一种手段，说直白点就是用来控制方法是否使用同一事务的一种属性，以及按照什么规则回滚的一种手段。

        下面用代码演示这三种属性的机制：

        事务的默认属性就是required，通过Transactional.java中的Propagation propagation() default Propagation.REQUIRED; 可以看出。

        这种情况就是事务1，事务2 都加入到了事务0中。不管是1，2哪个事务抛出异常，事务0都会回滚。数据添加会失败。

        这种情况就是：

        事务0（required） {

        ​ 事务1 （REQUIRES_NEW）

        ​ 事务2

        }

        此时。

        情况a：

        1、如果只是事务2出现了异常，那么事务1会提交，事务2加入到事务0中会回滚。

        2、如果只是事务1出现了异常，那么事务1会回滚，向上层事务0抛异常，事务2会加入到事务0中，这时都会回滚。

        情况b：

        如果事务1，事务2都是REQUIRES_NEW传播属性。那么结果就是：

        1、如果事务1，抛出了异常，那么事务2是不会执行的，那么事务0必然回滚。

        2、如果事务2，抛出异常，那么事务1会提交，表中会有数据。事务2有异常回滚并抛出，事务0回滚。

        NESTED属性其实就是创建了回滚点，有异常时，会回滚到指定的回滚点。

        在这通过代码测试，出现一种情况是，无论事务1，事务2哪个有异常，数据都不会插入成功，原因是，不论是事务1还是事务2都会向事务0抛出异常，事务0捕获到异常后，执行rollback()方法，这就操作成了，事务的全部回滚。

        如果想要事务1和事务2 想要根据自己的回滚点回滚，那么事务0必须自己处理异常，不让spring捕获到这个异常，那么就满足了。把代码改成这种：

        Jack大佬提供了，伪代码分析法。

        按照Spring源码的事务处理逻辑，伪代码大致为：

分布式事务(Seata)原理 详解篇，建议收藏

       前言：

       本文旨在深入剖析分布式事务处理系统 Seata 的源码实现，特别是通过 AT 模式实现的机制。我们通过俯瞰整体思路，掌握核心点和整体流程，而不是陷入琐碎的细节。我们从 Seata 的客户端启动流程开始，深入分析 AT 模式的执行细节，并探讨如何从官网获取和使用 Seata 的源码。通过分析关键类如 GlobalTransactionAutoConfiguration、GlobalTransactionScanner 和 GlobalTransactionalInterceptor，我们揭示了 Seata 如何实现全局事务的管理。同时，我们探讨了 AT 数据源代理的机制，揭示了 Seata 如何选择数据源并进行代理，使 SQL 解析和 undoLog 的记录在用户无感知的情况下完成。

       Seata AT 模式核心流程：

       Seata AT 模式主要分为两个阶段：一阶段是发起全局事务的提交或回滚请求；二阶段是执行提交操作。在发起请求阶段，Seata 通过与 Seata 服务端（TC）的交互，获取全局事务 XID。之后，Seata 会根据全局事务 XID 进行后续操作，如提交或回滚。

       Seata 全局事务拦截器与代理机制：

       Seata 的全局事务拦截器 GlobalTransactionalInterceptor 通过 @GlobalTransactional 注解判断是否需要执行全局事务管理。当拦截成功时，它会调用 handleGlobalTransaction 方法，执行全局事务的具体流程。关键步骤包括通过 GlobalTransactionScanner 进行全局事务扫描，代理方法并进行增强，最终调用 TC 发起全局事务的开始、提交或回滚。此过程包括执行事务、获取 XID 和与 TC 的交互。

       AT 数据源代理机制：

       在 AT 模式下，Seata 对数据源进行了代理，使得 SQL 的解析和 undoLog 的记录在数据源代理中完成。通过引入的 SeataAutoConfiguration 类和 SeataDataSourceBeanPostProcessor，Seata 能够选择数据源并进行代理，实现数据库操作的自动化管理和事务一致性。

       ConnectionProxy 和 DataSourceProxy 代理解析：

       Seata 对数据库连接（Connection）、预编译语句（PreparedStatement）和 SQL 执行器（Statement）进行了代理。ConnectionProxy 代理了数据库连接方法，实现了自动提交模式的切换、事务的开启、提交和回滚。DataSourceProxy 则对数据源进行了整体代理，包括数据库连接的获取、预编译语句的执行和 SQL 的执行。

       Seata 服务端协调者实现：

       Seata 的服务端启动入口是 Server.java 类，其中包含了协调者（TC）的核心逻辑，如处理全局事务的开始、提交和回滚。Seata 通过 DefaultCoordinator 类处理全局事务的开始过程，涉及读取数据库模式下的 SessionManager 文件，初始化全局事务会话，并最终将全局事务信息记录至数据库中。

       总结：

       本文详细解析了 Seata 的源码实现，从客户端启动到服务端协调，以及核心机制如 AT 模式、全局事务拦截器、数据源代理和连接代理的实现。通过理解这些核心流程，开发者能够更深入地掌握 Seata 的分布式事务处理原理和实践。掌握这些知识对于构建可靠、高性能的分布式系统至关重要。如有疑问，欢迎在下方留言讨论。

openGauss数据库源码解析系列文章——事务机制源码解析（一）

       事务是数据库操作的核心单位，必须满足原子性、一致性、隔离性、持久性（ACID）四大属性，确保数据操作的可靠性与一致性。以下是openGauss数据库中事务机制的详细解析：

       ### 事务整体架构与代码概览

       在openGauss中，事务的实现与存储引擎紧密关联，主要集中在源代码的`gausskernel/storage/access/transam`与`gausskernel/storage/lmgr`目录下。事务系统包含关键组件：

       1. **事务管理器**：事务系统的中枢，基于有限循环状态机，接收外部命令并根据当前事务状态决定下一步执行。

       2. **日志管理器**：记录事务执行状态及数据变化过程，包括事务提交日志（CLOG）、事务提交序列日志（CSNLOG）与事务日志（XLOG）。

       3. **线程管理机制**：通过内存区域记录所有线程的事务信息，支持跨线程事务状态查询。

       4. **MVCC机制**：采用多版本并发控制（MVCC）实现读写隔离，结合事务提交的CSN序列号，确保数据读取的正确性。

       5. **锁管理器**：实现写并发控制，通过锁机制保证事务执行的隔离性。

       ### 事务并发控制

       事务并发控制机制保障并发执行下的数据库ACID属性，主要由以下部分构成：

       - **事务状态机**：分上层与底层两个层次，上层状态机通过分层设计，支持灵活处理客户端事务执行语句（BEGIN/START TRANSACTION/COMMIT/ROLLBACK/END），底层状态机记录事务具体状态，包括事务的开启、执行、结束等状态变化。

       #### 事务状态机分解

       - **事务块状态**：支持多条查询语句的事务块，包含默认、已开始、事务开始、运行中、结束状态。

       - **底层事务状态**：状态包括TRANS_DEFAULT、TRANS_START、TRANS_INPROGRESS、TRANS_COMMIT、TRANS_ABORT、TRANS_DEFAULT，分别对应事务的初始、开启、运行、提交、回滚及结束状态。

       #### 事务状态转换与实例

       通过状态机实例展示事务执行流程，包括BEGIN、SELECT、END语句的执行过程，以及相应的状态转换。

       - **BEGIN**：开始一个事务，状态从默认转为已开始，之后根据语句执行逻辑状态转换。

       - **SELECT**：查询语句执行，状态保持为已开始或运行中，事务状态不发生变化。

       - **END**：结束事务，状态从运行中或已开始转换为默认状态。

       #### 事务ID分配与日志

       事务ID（xid）以uint单调递增序列分配，用于标识每个事务，CLOG与CSNLOG分别记录事务的提交状态与序列号，采用SLRU机制管理日志，确保资源高效利用。

       ### 总结

       事务机制在openGauss数据库中起着核心作用，通过详细的架构设计与状态管理，确保了数据操作的ACID属性，支持高并发环境下的高效、一致的数据处理。MVCC与事务ID的合理使用，进一步提升了数据库的性能与数据一致性。未来，将深入探讨事务并发控制的MVCC可见性判断机制与进程内的多线程管理机制，敬请期待。