制作营销网站模板免费下载个人网站的设计的现状

写隔离

• 一阶段本地事务提交前，需要确保先拿到 全局锁

• 拿不到 全局锁 ，不能提交本地事务。

• 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

以一个示例来说明:

两个全局事务 tx1 和 tx2，分别对 a表的 m 字段进行更新操作，m 的初始值 1000

• tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000-100=900，本地事务提交前，先拿到该记录的全局锁 ，本地提交释放本地锁

• tx2 后开始，开启本地事务，拿到本地锁，更新操作m= 900-100=800。本地事务提交前，尝试拿该记录的全局锁，t1 全局提交前，该记录的全局锁被 t1 持有，tx2 需要重试等待全局锁。

tx1 二阶段全局提交，释放 全局锁。tx2 拿到 全局锁 提交本地事务。

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚

此时，如果 t2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1的分支回滚会失败。分支的回滚会一直重试，直到 t2 的全局锁等锁超时，放弃 全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。

读隔离

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

这里的读未提交是从全局事务的视角来看的。我们知道，在一阶段后，RM 的分支事务其实已经提交了，这时候在数据库层面来说就是读已提交，但是站在整个全局视角来说，只要二阶段还没执行提交或者回滚，整个全局事务都是处于未提交的阶段。

举个例子，有两个全局事务 tx1、tx2。tx1 读库存为 100，tx1 扣减库存 1，此时 before imgge 为 100，此时 tx2 也同时进来读取库存也为 100 那么问题了就来了，如果 tx1 二阶段回滚，不管 tx2 扣减多少库存，都会覆盖掉 tx2 扣减的库存，出现脏写的情况

目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理，Seata 会对 SELECT FOR UPDATE 语句进行拦截，会先去查询全局锁， 如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是 已提交 的，才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

2. 如果其中一个事务分支超时未提交

Seata的全局事务超时时间，默认是1分钟。当 TC 检测到有超市的全局事务时，会向所有已提交分支事务的 RM 发起回滚