zoukankan      html  css  js  c++  java
  • 事务隔离级别、脏读、不可重复读、幻读

    事务隔离级别、脏读、不可重复读、幻读

    网络上关于这方面的博文有些偏理论,有些通篇代码,都不能深入浅出。本文用图文并茂的方式,配上行云流水般的代码,非要摆清楚这个问题。相关代码已提交至码云(点击这里下载)。

    事务是现代关系型数据库的核心之一。在多个事务并发操作数据库(多线程、网络并发等)的时候,如果没有有效的避免机制,就会出现以下几种问题:

    第一类丢失更新(Lost Update)

    在完全未隔离事务的情况下,两个事务更新同一条数据资源,某一事务完成,另一事务异常终止,回滚造成第一个完成的更新也同时丢失 。这个问题现代关系型数据库已经不会发生,就不在这里占用篇幅,有兴趣的可以自行百度。

    脏读(Dirty Read)

    A事务执行过程中,B事务读取了A事务的修改。但是由于某些原因,A事务可能没有完成提交,发生RollBack了操作,则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读(Dirty Read)。脏读产生的流程如下:

    微信截图_20190223000611

    可以用EF Core模拟此过程:

     脏读示例

    对应的执行结果:

    捕获

    不可重复读(Nonrepeatable Read)

    B事务读取了两次数据,在这两次的读取过程中A事务修改了数据,B事务的这两次读取出来的数据不一样。B事务这种读取的结果,即为不可重复读(Nonrepeatable Read)。不可重复读的产生的流程如下:

    微信截图_20190223004632

    模拟代码如下:

     不可重复读示例

    对应的执行结果:

    捕获

    不可重复读有一种特殊情况,两个事务更新同一条数据资源,后完成的事务会造成先完成的事务更新丢失。这种情况就是大名鼎鼎的第二类丢失更新。主流的数据库已经默认屏蔽了第一类丢失更新问题(即:后做的事务撤销,发生回滚造成已完成事务的更新丢失),但我们编程的时候仍需要特别注意第二类丢失更新。它产生的流程如下:

    微信截图_20190223114546

    模拟代码如下:

     第二类更新丢失示例

    对应的执行结果如下图:

    捕获2

    可以明显看出事务A的更新被事务B所覆盖,更新丢失。

    幻读(Phantom Read)

    B事务读取了两次数据,在这两次的读取过程中A事务添加了数据,B事务的这两次读取出来的集合不一样。幻读产生的流程如下:

    微信截图_20190223102400

    这个流程看起来和不可重复读差不多,但幻读强调的集合的增减,而不是单独一条数据的修改。

    模拟代码如下:

     幻读示例

    执行结果:

    捕获3

    数据库隔离级别

    为了解决上面提及的并发问题,主流关系型数据库都会提供四种事务隔离级别。

    读未提交(Read Uncommitted)

    在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。本隔离级别是最低的隔离级别,虽然拥有超高的并发处理能力及很低的系统开销,但很少用于实际应用。因为采用这种隔离级别只能防止第一类更新丢失问题,不能解决脏读,不可重复读及幻读问题。

    读已提交(Read Committed)

    这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这种隔离级别可以防止脏读问题,但会出现不可重复读及幻读问题。

    可重复读(Repeatable Read)

    这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。这种隔离级别可以防止除幻读外的其他问题。

    可串行化(Serializable)

    这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读、第二类更新丢失问题。在这个级别,可以解决上面提到的所有并发问题,但可能导致大量的超时现象和锁竞争,通常数据库不会用这个隔离级别,我们需要其他的机制来解决这些问题:乐观锁和悲观锁。

    这四种隔离级别会产生的问题如下(网上到处都有,懒得画了):

    20160319184334938

    如何使用数据库的隔离级别

    很多文章博客在介绍完这些隔离级别以后,就没有以后了。读的人一般会觉得,嗯,是这么回事,我知道了!

    学习一个知识点,是需要实践的。比如下面这个常见而又异常严重的情况:

    clipboard

    图中是典型的第二类丢失更新问题,后果异常严重。我们这里就以读已提交(Read Committed)及以下隔离级别中会出现不可重复读现象为例。从上面的表格可以看出,当事务隔离级别为可重复读(Repeatable Read)时可以避免。把TestReadCommitted中的Read线程事务级别调整一下:

    复制代码
    ////////////////////////////////////////////////////////////////////////////////////////////////////
    // file:	TestTestReadCommitted.cs
    //
    // summary:	读已提交会出现“不可重复读”现象
    //              把读线程(事务B)的隔离级别调整到RepeatableRead,即可杜绝
    ////////////////////////////////////////////////////////////////////////////////////////////////////
    
    using System;
    using System.Linq;
    using System.Threading;
    using System.Transactions;
    using Microsoft.EntityFrameworkCore;
    using Microsoft.Extensions.DependencyInjection;
    using NUnit.Framework;
    using TestTransaction.Domain;
    
    namespace TestTransaction.Test
    {
        public class TestReadCommitted : TestBase
        {
            private AutoResetEvent _toWriteEvent = new AutoResetEvent(false);
            private AutoResetEvent _toReadEvent = new AutoResetEvent(false);
    
            [Test]
            public void ReadCommitted()
            {
                ThreadPool.QueueUserWorkItem(data => {
                    Read();  //启动线程读
                });
                ThreadPool.QueueUserWorkItem(data => {
                    Write();  //启动线程写
                });
    
                Thread.Sleep(60000);
    
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"最终用户状态:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }
    
            }
    
            private void Read()
            {
                //读线程(事务B)的隔离级别调整到RepeatableRead
                using (var transactionScope = new TransactionScope(TransactionScopeOption.Required,
                    new TransactionOptions { IsolationLevel = IsolationLevel.RepeatableRead, Timeout = TimeSpan.FromSeconds(40) }))
                {
                    using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                    {
                        var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                        Console.WriteLine($"事务B:第一次读取:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    }
    
                    _toWriteEvent.Set();  //模拟多线程切换,这时切换到写线程,复现不可重复读
                    _toReadEvent.WaitOne();
    
                    using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                    {
                        var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                        Console.WriteLine($"事务B:第二次读取:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    }
                }
    
            }
    
            private void Write()
            {
                _toWriteEvent.WaitOne();
    
                using (var scope = new TransactionScope(TransactionScopeOption.Required,
                    new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted, Timeout = TimeSpan.FromSeconds(5) }))
                {
                    User user = null;
                    using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                    {
                        user = context.Users.SingleOrDefault(u => u.Account == "admin");
                        Console.WriteLine($"事务A:读取为【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                        user.Status = 1 - user.Status;
                        try
                        {
                            context.SaveChanges();
                            scope.Complete();
    
                            Console.WriteLine($"事务A:已被更改为【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                        }
                        catch (DbUpdateException e)
                        {
                            Console.WriteLine($"事务A:异常,为了保证可重复读,你的修改提交失败,请稍后重试--{DateTime.Now.ToString("HH:mm:ss fff")}");
                        }
                    }
                    _toReadEvent.Set();
                }
            }
        }
    }
    
    复制代码

    这时执行效果如下:

    捕获3

    实际项目中,通过提示客户端重做的方式,完美解决了不可重复读的问题。其他并发问题,也可以通过类似的方式解决。

    最后,文中提到可串行化解决幻读的问题,会在下篇文章详细介绍,包含各种酷炫的乐观锁操作,敬请期待!本文唯一访问地址:https://www.cnblogs.com/yubaolee/p/10398633.html

    作者:李玉宝(李玉宝的代码人生)
  • 相关阅读:
    Effective Java 第三版——26. 不要使用原始类型
    Effective Java 第三版——25. 将源文件限制为单个顶级类
    Effective Java 第三版——24. 优先考虑静态成员类
    Effective Java 第三版——23. 优先使用类层次而不是标签类
    Effective Java 第三版——22. 接口仅用来定义类型
    Effective Java 第三版——21. 为后代设计接口
    Effective Java 第三版——20. 接口优于抽象类
    Effective Java 第三版——19. 如果使用继承则设计,并文档说明,否则不该使用
    Effective Java 第三版——18. 组合优于继承
    Effective Java 第三版——17. 最小化可变性
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/10436289.html
Copyright © 2011-2022 走看看