我悟了！Mysql事务隔离级别其实是这样！

绝地灬酷狼 2023-10-03 21:43 40阅读 0赞

![format_png][]

### 问题描述 ###

最近几天在忙项目，有个项目是将业务收集到的数据变动，异步同步到一张数据表中。在测试的过程时，收到QA的反馈，说有订单的数据同步时好时坏。我怀着疑惑的表情打开了那段代码，它的逻辑大概是这样的：

![format_png 1][]

如果用简单的代码实现的话，会是这样的：

public void updateAndQuery(Example example, int diff){
            List<ProductPO> productPOS = productMapper.selectByExample(example);
            ProductPO productPO =  productPOS.get(0);
            System.out.println("一次查询内容" + JSONObject.toJSONString(productPO));
    
            //二次插入并查询
            Integer oldNumber = productPO.getNumber();
            productPO.setNumber(oldNumber + diff);
    
            //首先先更新，再进行查询
            System.out.println("更新内容:"+ JSONObject.toJSONString(productPO));
            productMapper.updateByPrimaryKey(productPO);
    
            //异步执行
            CompletableFuture.runAsync(() -> {
                Example example1 = new Example(ProductPO.class);
                example1.createCriteria().andEqualTo("skuId", productPO.getSkuId());
                List<ProductPO> select = productMapper.selectByExample(example1);
                System.out.println("二次查询结果："+JSONObject.toJSONString(select));
                if (oldNumber != select.get(0).getNumber() - diff) {
                    throw new NrsBusinessException("查询出错");
                }
            });
        }
    复制代码

起初我左看看，右看看，也没有想到这个是什么原因造成的。直到我看到了这个........

@Transactional(rollbackFor = Exception.class)
    复制代码

### 事务执行原理 ###

在了解的问题原因前，我们需要了解事务是如何实现的。首先假设现在我们要设计一个mysql事务，最简单的方案其实是这样：**每执行一次SQL，写一次数据库**。大致流程图如下所示：

![format_png 2][]

但是这个方案好么？显然不是。因为我们如果采用这样的方式，存在两个显著的问题：

*  **数据库写入为磁盘读写，速度很慢。**
 *  **数据库存在锁机制，难支持高并发。**

对于问题一，了解到存储器读写速度如下所示（图源网络）：

![format_png 3][]

可以看到内存的存储速度是纳秒级别（10^-9次方），而硬盘的存储速度是毫秒级别（10^-3次方）。由此，为加快读写速度，**可以将修改的内容写入内存，而后再异步写入磁盘**。

同时，由于内存本身并没对不同线程做锁控制机制，可以支持多个线程同时访问。对于高并发的问题也能更好支持。由此，上述的实现方案就改为了下面的流程：

![format_png 4][]

### 事务隔离级别 ###

在修改为优先写内存后续再异步同步的情况后，又带来了新的问题：**在一个事务尚未确认提交时，新事务从缓存中应该读取什么数据呢？**

![format_png 5][]

对于这种不同事务间数据读取的策略就被称为**事务隔离级别**。根据读取策略的不同，事务隔离级别被划分为四种：**读未提交、读已经提交、可重复读、序列化**。

读未提交（Read Uncommitted）

读未提交的策略比较简单，即默认读取内存中的内容，而不必管这个数据是否已经写入到了数据。但是这个策略会带来一些问题：

![format_png 6][]

**存在问题：**

如图所示，若设置为读未提交，那么此时事务可能读到尚未提交的数据，即**脏读**。因此会造成数据A在前一时刻尚且可以读取到，但想二次更新的时候，mysql数据库却因为回滚导致数据A被回退了。这种错误会导致系统的无法正常运行，是不可容忍的。

读已提交（Read Committed）

既然读未提交的事务带来的错误是不可容忍的，那么我只读已提交的数据就可以避免读到脏数据了呀！那么应如何实现只读已提交数据呢？对问题进行分析，要获取到最新已提交的数据，必然要将数据的版本关系体现出来。为此，InnoDB设计了一个**版本链**的概念。对每行记录会新增两个隐藏列：**trx\_id、roll\_pointer**。

![format_png 7][]

1.  trx\_id：用于保存每次对该记录进行修改的事务id。
2.  roll\_pointer：存储一个指针，指向这条数据记录上一个版本的地址，可以通过它获取到该记录上一个版本的数据信息。

由此一来，就可以通过**最新记录（可能未提交）进行回溯，直到找到已提交的记录**。

当然，仅有版本链的概念明显不够，**我们还无法判断哪个数据是已提交的**。为此InnoDB又新增了一个**ReadView**的解决方案，ReadView保存了一个**写入了但未提交的事务ID**列表。依据这个列表，我们就可以判断哪些事务还未写入。

![format_png 8][]

以上图为例，由于此时trx\_id=20、trx\_id=40的事务均未提交，InnoDB会生成一个ReadView：\{20，40\}。由此可能出现三种情况的事务访问：

*  若预期访问事务ID=10的记录，由于其小于最小的事务Id20，证明事务已提交，允许访问。
 *  若预期访问事务ID=30的记录，由于其介于最大最小的事务ID之间，就需要逐一判断ReadView中是否包含事务ID=30的记录
 *  若预期访问事务ID=50的记录，由于其大于ReadView最大的事务Id，必然是在生成ReadView后生成的，也必然没有提交，不允许访问。

结合版本链和ReadView，基本就可以实现只读取已经提交的内容。

**存在问题：**

由于ReadView是每次查询才新生成的，因此不免存在以下情况：

![format_png 9][]

在事务中首先读了一次数据A，期间事务发生了提交，导致二次查询出来的数据A同第一次出现了差异。由此难免让人发问：“两次相同的条件，查询到的结果却不一致，我是出现了幻觉了嘛？” 因此，这种情况也被形象称做：**幻读**。

幻读同脏读不同，幻读造成的问题是会**破坏数据一致性**。假设我们有一张表 user(id, name, age)，已经有两条数据 (1, "Jack", 20), (2, "Tom", 18)，同时我们执行以下流程：

![format_png 10][]

三个事务执行完成后，主库数据库内的数据应该是：(1, "Jack", 10), **(2, "Jack", 18)，(3, "Jack", 18)**。然而，此时binlog内的写入的SQL语句却是：

//事务二
    update user set name = "Jack" where id = 2
    update user set age = "40" where id = 2
    
    //事务三
    insert into user values(3, "Jack", 30) /*(3, Jack, 30)*/
    
    //事务一
    update user set name = "Tom" where name = "Jack"
    复制代码

那么此时，从库收到了主库同步的binLog数据，并按照顺序执行。得到的结果却是：(1, "Jack", 10), **(2, "Jack", 10)，(3, "Jack", 10)**。不难发现，数据行2和3发生了主从不一致，这个是无法容忍的。

可重复读（Repeatable Read）

要解决幻读，主要是解决两个问题：**1、确保一次事务内看到的数据一致；2、确保生成的binLog数据顺序正确。**

对于问题1，其实相对比较简单。同一次事务内看到的数据不一致是由于每次ReadView都实时生成（也被称为实时读）。因此，只要确保**同一次事务内只生成一次ReadView**（也被称为快照读），就可以避免多次查询会出现不一致数据的情况。

然而，仅保持自己看不到是不够的，如果无法解决binLog的SQL写入顺序问题，数据不一致的问题就无法得到解决。那其实对上述现象进行分析，导致SQL写入顺序混乱的原因，其实是因为违背了事务一对于"where name = "Jack" 的原子性。即**事务操作期间还有别的符合条件数据能被修改**。

那么，很朴素的一个思想就是，只要对这些都符合条件的数据都加锁不就可以了嘛？为此，mysql提出了**间隙锁**的概念。假设当前我们的数据对name字段配置了一个索引，那么此时事务一运行的时候，我们需要将其索引临近的一行及其间隙都锁上，不允许其余事务进行更新插入的操作。由此一来，索引被锁上，没法插入新的数据，也就不会出现SQL语句混乱的情况了。

![format_png 11][]

那么这个时候肯定有人会说：“你没索引的字段咋办啊？”，对于没有索引的字段，mysql会做全表的扫描。由此一来，相当于会把整张表的数据都给锁上。从而避免无索引的情况出现数据不一致的问题。

序列化（Serializable）

对于可序列化来说，实现就相对粗暴些。本着“爷才不考虑那么多，直接将表锁了，肯定不会有问题”的思想出发进行设计：

1、首先针对每次事务读操作的时候加表级共享锁，确保多个事务可以读。

2、事务写操作的时候则加表级别的排它锁，只允许自己事务操作。

这些锁都维持到事务结束再释放，从而完美避免了上述问题的出现。然而，粗暴的方法一般性能都不太好，在高并发的情况下，常常只有一个线程可以操作数据，因此不建议使用。

### 总结 ###

介绍了这么多有关事务隔离的内容，我们终于可以回归到我们的问题上来了。那么其实对于开头提到的问题，原因就是在异步线程中，会新开一个事务，这两个事务是并行的。由于mysql默认的事务隔离级别是可重复读，会导致事务A异步的情况下，数据可能未提交，事务B执行较快而获取到了旧数据，造成了同步数据错误的问题。

![format_png 12][]

知道了问题，那么解决方案就比较简单了，可以不通过异步的方式发送，而是采用kafka消息的机制。这样就给事务A留足了事务提交的时间，从而确保数据的准确同步。

[format_png]: https://img-blog.csdnimg.cn/img_convert/3538bd13338a445775469521a4093e9c.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/93d24b088e294616d2da124e55b61195.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/4ae9b2fa2543089265a00a12a06c84ad.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/149246dffbef9bd53fa9f295ae91a208.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/c7d7e0676b765a100cc454616573639c.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/a3fe4ad1707ffacf67135cfc41b07ff3.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/6db88e389bad08d5b73e2c552769cc0f.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/6e2cba1bb795e5423bdc0a1832e51b50.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/3f3353e6200f3424381f4f7ddeae127f.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/f438dbc8af97495ea98de16a396315f6.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/16c78d4f0a80f13bc7a93416e2ebb6d1.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/b78c7cba6b7ddea154ae2c52421b8218.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/73476dd09b283d2377124c826550ab06.webp?x-oss-process=image/format,png