引子

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

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

begin transaction

if 查询到客户存在进行中的订单
 rollback transaction

if 查询到设备存在进行中的订单
 rollback transaction

插入订单

commit transaction

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

事务概述

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

第一个问题，事务是否可以并发?

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

事务的表现特性

数据库中执行事务涉及到很多方面，包括如何处理临界资源，如何加锁解锁等等。但是无论事务如何执行，都需要保证以下几个特性：

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

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

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

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

数据库的各种锁

1. 共享锁

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

1. 排他锁

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

1. 更新锁

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

事务隔离级别

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

1. Serializable(串行化)

工作方式类似于可重复读。但它不仅会锁定受影响的数据，还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围，这种情况可以导致幻像读。

1. Repeatable Read(可重复读)

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

1. Read Commit

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

1. Read Uncommited

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

回答前文的问题

第一个问题，事务是否可以并发?

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

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

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

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

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

如何防止并发问题

1. 在事务中

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

1. 在事务外

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

参考资料