2）读隔离（若有全局事务在改/写/删记录，另一个全局事务对同一记录的读取要被隔离起来，即读写互斥）：在数据库本地事务的隔离级别为读已提交、可重复读、串行化时（读未提交不起什么隔离作用，一般不使用），Seata AT 全局事务模型产生的隔离级别是读未提交，也就是说一个全局事务会看到另一个全局事务未全局提交的数据，产生脏读，从前文的第一阶段和第二阶段的流程图中也可以看出这一点。这在最终一致性的分布式事务模型中是可以接受的。
如果要求 AT 模型一定要实现读已提交的事务隔离级别，可以利用 Seata 的 SelectForUpdateExecutor 执行器对 SELECT FOR UPDATE 语句进行代理。SELECT FOR UPDATE 语句在执行时会申请全局锁，如果全局锁已经被其他全局事务占有，则回滚 SELECT FOR UPDATE 语句的执行，释放本地锁，并且重试 SELECT FOR UPDATE 语句。在这个过程中，查询请求会被阻塞，直到拿到全局锁（也就是要读取的记录被其他全局事务提交），读到已被全局事务提交的数据才返回。这个过程如下图所示：
XA 协议是 X/Open 提出的分布式事务处理标准。文中提到的 2PC、3PC、TCC、本地事务表、Seata in AT mode，无论哪一种，本质都是事务协调者协调各个事务参与者的本地事务的进度，使使所有本地事务共同提交或回滚，最终达成一种全局的 ACID 特性。在协调的过程中，协调者需要收集各个本地事务的当前状态，并根据这些状态发出下一阶段的操作指令。这个思想就是 XA 协议的要义，我们可以说这些事务模型遵守或大致遵守了 XA 协议。
基于消息中间件的最终一致性事务方案是互联网公司在高并发场景中探索出的一种创新型应用模式，利用 MQ 实现微服务之间的异步调用、解耦合和流量削峰，保证分布式数据记录的最终一致性。它显然不遵守 XA 协议。
对于某项技术，可能存在业界标准或协议，但实践者针对具体应用场景的需求或者出于简便的考虑，给出与标准不完全相符的实现，甚至完全不相符的实现，这在工程领域是一种常见的现象。TCC 方案如此、基于消息中间件的最终一致性事务方案如此、Seata in AT mode 模式也如此。而新的标准往往就在这些创新中产生。
你难道真的没有发现 2.6 节（基于消息中间件的最终一致性事务方案）给出的正确方案中存在的业务漏洞吗？请各位重新看下这张图，仔细品一品两个微服务的调用方向，把你的想法留在评论区吧