数据库中的事务和并发问题探讨

数据库中的事务和并发问题探讨

引子

最近有同事写了段代码，负责建立订单的逻辑，代码审查时发现可能会有并发的问题。同事并不认同，他认为他的逻辑是写在存储过程当中的，应该没有问题。

代码的逻辑大概是(伪代码)：

begin transaction if 查询到客户存在进行中的订单 rollback transaction if 查询到设备存在进行中的订单 rollback transaction 插入订单 commit transaction

下面针对这个逻辑进行分析，为何这个事务会出现并发问题。

事务概述

首先，提出两个问题，而后带着问题讨论事务相关的知识点，最后来解决这两个问题并回答前文的问题。

第一个问题，事务是否能够并发?

第二个问题，数据库是怎么隔离事务的？

事务的表现特性

数据库中执行事务涉及到不少方面，包括如何处理临界资源，如何加锁解锁等等。可是不管事务如何执行，都须要保证如下几个特性：

• 原子性
• 一致性
• 隔离性
• 持久性

原子性：全部的操做是一个逻辑单元，要么都提交成功，要么就都失败；

一致性：只有合法的数据被写入数据库，不然事务回滚到最初的状态；

隔离性：容许多个事务同时进行，而不会破坏数据的正确性和完整性；

持久性：事务结束后，已经提交的结果被固化保存。

数据库的各类锁

1. 共享锁

共享锁用于非独占的业务，容许多个事务同时读取锁定的资源，可是不容许资源被更新。

• 加锁时机：执行select语句时默认会被加上
• 解锁时机：执行完读取后默认解除
• 与其余锁兼容性：数据上被设置了共享锁，则不会容许再增长共享锁和独占锁
• 并发性能：具备良好的并发性能

2. 排他锁

排他锁，也叫独占锁。顾名思义，被排他锁锁定的资源不会容许其余事务进行任何操做。

• 加锁时机：执行insert,update,delete时默认会被加上
• 解锁时机：事务结束才能解除
• 兼容性：若是数据上有其余锁，不能增长独占锁；一样独占锁存在时也不会容许增长其余锁
• 并发性能：其余事务必须等待前一个事务结束后才能执行，不能并发，只能串行

3. 更新锁

在更新的初始阶段用于锁定所须要的资源，防止在读取阶段使用共享锁形成死锁。

• 加锁时机：执行update时，使用更新锁锁定相关资源
• 解锁时机：读取完毕，执行更新操做时，更新锁升级为独占锁
• 兼容性：更新锁与共享锁兼容，便可以同时存在更新锁和共享锁，但只能有一个更新锁
• 并发性能：更新初期的读取阶段能够容许其余事务读取资源，容许有限的并发；后期对资源进行独占时不容许并发。

事务隔离级别

通用的事务隔离级别有四种，SQL Server还有另外扩展出来的级别，在此很少介绍。

1. Serializable(串行化)

工做方式相似于可重复读。但它不只会锁定受影响的数据，还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围，这种状况能够致使幻像读。

2. Repeatable Read(可重复读)

像已提交读级别那样读数据，但会保持共享锁直到事务结束。

3. Read Commit

只读取提交的数据并等待其余事务释放排他锁。读数据的共享锁在读操做完成后当即释放。已提交读是SQL Server的默认隔离级别。

4. Read Uncommited

在读数据时不会检查或使用任何锁。所以，在这种隔离级别中可能读取到没有提交的数据。

回答前文的问题

第一个问题，事务是否能够并发?

答案是确定的，数据库中为了提升性能，容许同时进行多个事务操做，这个事务跟发起方式无关，使用存储过程发起，或者使用代码发起，又或者使用普通的SQL语句发起并无什么区别。

第二个问题，数据库是怎么隔离事务的？

要回答这个问题，先要理解数据库中的锁机制和数据库事务隔离级别。数据库中的锁能够分为三种类型：共享锁、独占锁和更新锁。使用不一样级别的锁并配合不一样的锁定范围已达到不一样的事务隔离级别并在此基础上并发或串行执行事务。

第三个问题，为何本文开头的事务会存在并发问题？

由于事务的开始执行的是select，select使用的是共享锁，有可能并发的事务在同一时间执行select致使同时认为本身都是合法操做，而排队执行后续的事务。结果致使了实际上就有可能插入重复的数据，好比只剩下一个商品，却建立了两个销售订单。

如何防止并发问题

1. 在事务中

根据前文所讲，使用insert,update或delete能够在默认事务级别人为形成事务串行化，所以能够在事务内部一开始都使用update更新一条公共的数据，这样的话同类型的事务都会串行化，而后再增长一个判断语句，用于判断后续的事务内容是否应该执行。这样足以确保全部的操做都按照合理合法，惟一的缺点是可能形成性能问题。

2. 在事务外

如今分布式的系统愈来愈多，可是再分布的系统也会有些共享资源，好比redis或zookeeper，能够利用redis或者zookeeper造一些分布式的锁（此类属于其余博文内容，在此再也不展开）。利用事务外部的锁将同类型的事务作一些串行化处理，再配合事务内部的检查机制，足以确保解决事务的并发问题。

参考资料

• 事务并发的问题及处理
• 数据库事务的四大特性以及事务的隔离级别
• 数据库事务和并发
• SQLServer事务的隔离级别