欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

事务的隔离级别和幻读问题

程序员文章站 2022-06-14 17:16:43
...

 

事务的隔离级别,是一个很基本的概念,从自己的角度整理一下.

 

分为两部分,一个是事务.一个是隔离级别.

 

第一个:事务

ACID是指在可靠数据库管理系统(DBMS)中,事务(transaction)所应该具有的四个特性:

原子性(Atomicity)

一致性(Consistency)

隔离性(Isolation)

持久性(Durability)

 

一个用户的操作可能要修改两张数据表,这个操作对应程序中的方法.以下是示例代码,没有真实意义,只是为了说明.

 

  /**
     * 更新项目的站点,示例代码没有意义
     * @param pid 项目ID
     * @param lid 站点ID
     * @return
     */
    public String updateProject(Integer projectId,Integer siteId){
        projectDAO.updateProjectLogicSite(projectId, siteId);
        siteDAO.addProject(projectId, siteId);
    }

 如果下面的站点加入项目失败

siteDAO.addProject(projectId, siteId);   //失败,DB中没有生效

但是下面的代码生效了

projectDAO.updateProjectLogicSite(projectId, siteId);//这个DB中生效了

 

因为上面的两句代码是两个事务了.使这个方法整体作为一个事务,(spring事务管理,使用注释方式)

/**
     * 更新项目的站点
     * @param pid 项目ID
     * @param lid 站点ID
     * @return
     */
    @Transactional(isolation=Isolation.REPEATABLE_READ)
    public String updateProject(Integer pid,Integer lid){
        projectDAO.updateProjectLogicSite(pid, lid);
        siteDAO.addProject(pid, lid);
    }

 那么,第二个更新站点失败,第一个更新项目也会一起回滚.

具体可以参考spring,和db的事务概率.

 

第二个 隔离级别

那么使用哪个隔离级别呢?

Spring提供了五个可选参数,对应了事务的四个隔离级别(怎么5个对应4个呢?看了就知道)

@Transactional(isolation=Isolation.DEFAULT)  //默认使用DB的隔离级别,如果是mysql的innodb默认是REPEATABLE_READ
@Transactional(isolation=Isolation.READ_UNCOMMITTED)
@Transactional(isolation=Isolation.READ_COMMITTED)
@Transactional(isolation=Isolation.REPEATABLE_READ)
@Transactional(isolation=Isolation.SERIALIZABLE)

 每个隔离级别的意思和介绍很多书和文章都讲解的很好,我就不重复了,下面按我自己的思路理一下

 

假设有TA和TB两个方法.都假设一个方法中有两个或者多个DB操作.

从两方面来说明.

A.是否阻塞其他事务往下执行

 

   1.TA是读操作先执行   TB是读操作后执行  无论两个方法的隔离级别是什么都不影响.

   2.TA是读操作先执行   TB是写操作后执行 只有TA是SERIALIZABLE才会被阻塞.其他时候都不会被阻塞.

   3.TA是写操作先执行   TB是读操作后执行  只有TB是SERIALIZABLE才会被阻塞.其他时候都不会被阻塞.

   4.TA是写操作先执行   TB是写操作后执行  只有TA没有事务,TB不会被阻塞,其他时候都要等TA操作完成.

 

注意(第4点,这里更严格的表示应该是TA的这个方法没有执行完,TB会被阻塞,方法没有声明为一个事务的时候TA一个DB操作就是一个事务,这个DB操作的时候,是会阻塞TA的写操作的)

 

B.读到的数据

首先假设一个场景是,TA是读操作先执行  然后TB是写操作,TA再次读取读到的是什么.其实只有这一个场景有问题,其他时候都是正常的操作.或者说TA先写,TB读,这个时候其实是第一个场景的后半部分.下面来列出什么情况读到什么.

TA1和TA2是TA这个方法中的两个读方法

1.TA没有事务   无论TB这个事务是否提交 TA2读到的都是TB写的数据.(更新丢失)

2.TA有事务,隔离级别READ_UNCOMMITTED  无论TB是否提交 TA2读到的都是TB写的数据  (和上面的区别是没有第一中更新丢失,但是TB回滚TA2会脏读)

3.TA有事务,隔离级别READ_COMMITTED  TA2读到的都是TB事务提交后的数据,没有提交读不到.(没有脏读,TA1读和TA2读到的不一致)

4.TA有事务 隔离级别REPEATABLE_READ   TA2读到的数据和TA1一样无论TB是否有提交(所以可以重复读,这里有幻读的问题,下面专门介绍幻读)

5.TA有事务 隔离级别SERIALIZABLE  TA2读到的和TA1一样,幻读都没有,看阻隔就知道,有写的时候都是排队来的.

幻读

专门理一下幻读,幻读发生在读一张表中不同行的数据时.

比如TA1读操作  select * from project where create_date > '20100101' 第一次查询有2条记录.

TB写操作     插入一条记录创建时间大于20100101的记录

TA2 再读 就读出3条记录了,这个时候就幻读了.

因为REPEATABLE_READ的时候TB是可以同时写的就有这个问题.

SERIALIZABLE是排队的,TB只有在TA的两次读操作都完成后才可以写,所以是完全没有问题的.

 

幻读导致的问题1

比如注册用户,希望用户名不重名.

TA和TB要注册用户gtbald.

TA1查询不存在gtbald.

TB1查询不存在gtbald.

TA2插入gtbald

TB2插入gtblad.

有两个gtbald了.

目前我知道的解决办法可以是DB用户名加上唯一索引.或者业务中注册事务隔离级别设为SERIALIZABLE(性能差).

 

幻读导致的问题2

比如报名人数限制为100人

TA和TB都要提交报名人

TA1查询总报名人数99人

TB1查询总报名人数99人

TA2增加报名一人 现在总报名人数100人

TB2增加报名一人  现在总报名人数101人

 

目前我知道的解决办法:报名务隔离级别设为SERIALIZABLE(性能差).

接下来研究幻读问题的解决方案.