并发数据库中丢失修改问题的解决措施详解

并发数据库中丢失修改问题的解决措施是本文我们主要要介绍的内容，接下来我们就从一个简单的例子开始介绍这部分内容，希望能够对您有所帮助。

1．问题定义

先从一个较简单的例子为例，如火车售票系统，数据库表（车次，剩余票数），一个售票事务的处理过程如下：

（1）查询该车次剩余票数x=16。

（2） x = x – 1，得x=15

（3）将x=15写回该车次剩余票数。

这样一个事务在串行运行的数据库系统中是没有问题的，如果两个事务串行运行，各售一张票，最终结果为14。但如果在并行系统中，可能会有两个售票事务实例同时执行，由于CPU分时间片轮流执行事务，这时有可能发生如下情况（执行次序自上而下，两个事务交叉运行）：

售票事务T1 售票事务T2

（1）查询剩余票数x=16

（2）查询剩余票数x=16

（3） x=x-1，得x=15

（4）将x=15写回数据库。

（5） x=x-1，得x=15

（6）将x=15写回数据库。

即T1先查询出了剩余票数16，此时它把控制权交给CPU，等待分配下一个时间片执行。然后T2获得了执行权，查出票数依然是16。然后T1和T2不管如何轮换执行，售出一张票后（售多张票是类似的），都将得到结果15。那么后一个事务提交的数据就覆盖了前一个事务的数据，最终结果是15，这就是所谓的丢失修改问题。

这个问题在分布式数据库中具有一般性，其它的例子如申请手机号时，两个用户同时申请同一个手机号的问题，本文中我们给出这类问题的一个通用解决方案。（火车售票例子太简单，还是比较容易解决的，没必要用本文所述的一般性的方法，呵呵）。

2．思路

我们可以采用一个时间戳字段记录哪个事务先修改的记录。时间戳不是一个时间，而类似于一个自动增长字段，但它有一个特点，就是每次更新某条记录时，会自动更新为一个新的时间戳数据。在SQL Server中，设置为一个字段为timestamp数据类型，读取时可以使用varbinary类型读取。

主要思路是：读取剩余票数时就同时读取该记录的时间戳，当更新记录时，判断时间戳是否与原来读取的相同，如果不同，说明已经有一个事务修改了这条记录，就让当前事务失败。

这样我们把数据库表修改为：车次表（车次，剩余票数，修改时间）。注意修改时间字段设置为timestamp类型，不允许为空，这样初始化时就先自动生成了一个时间戳。

3．解决方案

售票的存储过程：

Create Procedure Sale  
 
(@Serial varchar(10), -- 车次  
 
@SaleCount int -- 所售票数  
 
) As  
 
-- 取出剩余票数  
 
Declare @RealCount int, -- 剩余票数  
 
@Time varbinary(6) -- 时间戳  
 
Select @RealCount=剩余票数, @Time=修改时间 From 车次表 Where 车次=@Serial  
 
-- 判断票数是否够  
 
If (@SaleCount > @RealCount)  
 
Begin  
 
Print ‘票数不够’  
 
return  
 
End  
 
-- 更新数据  
 
Declare @RowsCount int -- 更新时影响的行数  
 
Update 车次表 Set 剩余票数=剩余票数-@SaleCount  
 
Where 车次=@Serial and 修改时间=@Time  
 
Set @RowsCount=@@RowsCount  
 
/* @@RowsCount记录了修改最近一条SQL语句影响的行数，如果为1，表示修改成功，如果为0，表示未修改任何行，出现这种情况的原因就是其它事务已经修改了这条记录，造成修改时间这个自动的值变化了 */  
 
-- 判断结果  
 
If (@RowsCount = 0)  
 
Print ‘事务并发造成的修改失败’  
 
Else  
 
Print ‘售票成功  
 
Go