一种并发控制方法及装置

本发明涉及计算机技术领域，具体涉及一种并发控制方法及装置。

在计算机科学，特别是程序设计、操作系统、多重处理和数据库等领 域，并发控制是确保及时纠正由并发操作导致的错误的一种机制。并发控 制的基本单位是事务。并发控制指的是当多个用户同时更新运行时，用于 保护数据库完整性的各种技术。并发机制不正确可能导致脏读、幻读和不 可重复读等此类问题。并发控制的目的是保证一个用户的工作不会对另一 个用户的工作产生不合理的影响。在某些情况下，这些措施保证了当用户 和其他用户一起操作时，所得的结果和她单独操作时的结果是一样的。在 另一些情况下，这表示用户的工作按预定的方式受其他用户的影响。

数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同 时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的 统一性。下面举例说明并发操作带来的数据不一致性问题：现有两处火车 票售票点，同时读取某一趟列车车票数据库中车票余额为X。两处售票点 同时卖出一张车票，同时修改余额为X-1写回数据库，这样就造成了实际 卖出两张火车票而数据库中的却记录只少了一张。产生这种情况的原因是 因为两个事务读入同一数据并同时修改，其中一个事务提交的结果破坏了 另一个事务提交的结果，导致其数据的修改被丢失，破坏了事务的隔离性。 并发控制要解决的就是这类问题。封锁、时间戳、乐观并发控制和悲观并 发控制是并发控制主要采用的技术手段。

在并发控制中采用封锁协议解决数据的不一致性并发控制的主要方法 是封锁(Locking)。就是要用正确的方式调度并发操作，使一个用户的事务 在执行过程中不受其他事务的干扰，从而避免造成数据的不一致性。封锁 是使事务对它要操作的数据有一定的控制能力。封锁通常具有3个环节： 第一个环节是申请加锁，即事务在操作前要对它将使用的数据提出加锁申 请；第二个环节是获得锁，即当条件成熟时，系统允许事务对数据进行加 锁，从而事务获得数据的控制权；第三个环节是释放锁，即完成操作后事 务放弃数据的控制权。

基本的封锁类型有以下两种：

1.排它锁(Exclusive Locks，简称X锁)

排它锁也称为独占锁或写锁。一旦事务T对数据对象A加上排它锁(X 锁)，则只允许T读取和修改A，其他任何事务既不能读取和修改A，也 不能再对A加任何类型的锁，直到T释放A上的锁为止。

2.共享锁(Share Locks，简称S锁)

共享锁又称读锁。如果事务T对数据对象A加上共享锁(S锁)，其 他事务只能再对A加S锁，不能加X锁，直到事务T释放A上的S锁为 止。

然而，封锁一方面可以保证数据库事务的ACID属性(数据库的四大 基本特性：Atomicity原子性，Consistency一致性，Isolation隔离性， Durability持久性)，另一方面封锁的存在会影响数据库的并发性能。基于 现有设计模式下的封锁类型，在高并发情况下，会严重制约整个系统的吞 吐能力。因此，高效的并发控制技术是设计高性能数据库软件的关键所在。

为了解决现有技术中高并发情况下数据库系统并发吞吐能力受限的问题， 本发明实施例提供一种并发控制方法及装置，包括：

第一方面，一种并发控制方法，包括：

接收至少两条事务操作请求，所述至少两条事务操作请求中的每条事务操 作请求包括操作对象信息及操作类型信息，所述操作对象信息用于指示所述事 务操作请求的操作对象，所述操作类型信息包括写操作或读操作；

根据所述至少两条事务操作请求进行用锁申请；

根据所述用锁申请的请求锁状态和当前锁状态确定所述申请是否通过；若 是则确定用所述请求锁状态对所述至少两条事务操作请求进行并发控制；其中， 所述锁状态至少包括三种模式：共享读模式、共享写模式、排他模式，其中所 述共享写模式包括允许大于或等于两个的写操作对所述操作对象同时进行写操 作，所述锁状态包括所述请求锁状态和所述当前锁状态。

结合第一方面，在第一方面的第一种可能的实现方式中，所述根据所述用 锁申请的请求锁状态和当前锁状态确定所述申请是否通过包括：

当所述请求锁状态和所述当前锁状态均为共享读模式，或，所述请求锁状 态和所述当前锁状态均为共享写模式，则通过所述申请。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种 可能的实现方式中，若所述申请不通过则等待下一次用锁时机重新进行用锁申 请，所述下一次用锁时机包括所述当前锁状态结束时的时机。

结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现 方式中，所述若所述申请不通过包括：

当所述请求锁状态或所述当前锁状态为排他模式，或，当所述请求锁状态 为共享写模式时所述当前锁状态为共享读模式，或，所述请求锁状态为共享读 模式时所述当前锁状态为共享写模式，则所述申请不通过。

结合第一方面，第一方面的第一种可能的实现方式至第一方面的第三种可 能的实现方式中的任一种可能的实现方式，在第一方面的第四种可能的实现方 式中，所述操作对象包括多个局部操作对象，所述大于或等于两个的写操作对 所述操作对象同时进行写操作包括：所述大于或等于两个的写操作分别对所述 操作对象的多个局部操作对象中的不同局部操作对象进行写操作。

第二方面，一种并发控制装置，包括接收模块、用锁申请模块、中枢决策 模块及决策执行模块：

所述接收模块，用于接收至少两条事务操作请求，所述至少两条事务操作 请求中的每条事务操作请求包括操作对象信息及操作类型信息，所述操作对象 信息用于指示所述事务操作请求的操作对象，所述操作类型信息包括写操作或 读操作；

所述用锁申请模块，用于根据所述至少两条事务操作请求进行用锁申请；

所述中枢决策模块，用于根据所述用锁申请的请求锁状态和当前锁状态确 定所述申请是否通过；若是则通过所述决策执行模块确定用所述请求锁状态对 所述至少两条事务操作请求进行并发控制；其中，所述锁状态至少包括三种模 式：共享读模式、共享写模式、排他模式，其中所述共享写模式包括允许大于 或等于两个的写操作对所述操作对象同时进行写操作，所述锁状态包括所述请 求锁状态和所述当前锁状态。

结合第二方面，在第二方面的第一种可能的实施方式中，所述中枢决策模 块具体用于确定：

当所述请求锁状态和所述当前锁状态均为共享读模式，或，所述请求锁状 态和所述当前锁状态均为共享写模式，则通过所述申请。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第二种 可能的实现方式中，若所述中枢决策模块确定所述申请不通过，则所述中枢决 策模块确定等待下一次用锁时机重新进行用锁申请，所述下一次用锁时机包括 所述当前锁状态结束时的时机。

结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现 方式中，所述中枢决策模块具体用于确定：

当所述请求锁状态或所述当前锁状态为排他模式，或，当所述请求锁状态 为共享写模式时所述当前锁状态为共享读模式，或，所述请求锁状态为共享读 模式时所述当前锁状态为共享写模式，则所述申请不通过。

结合第二方面，第二方面的第一种可能的实现方式至第二方面的第三种可 能的实现方式中任一可能的实现方式，在第二方面的第四种可能的实现方式中， 所述操作对象包括多个局部操作对象，所述大于或等于两个的写操作对所述操 作对象同时进行写操作包括：所述大于或等于两个的写操作分别对所述操作对 象的多个局部操作对象中的不同局部操作对象进行写操作。

本发明实施例中的锁状态至少包括三种模式：共享读模式、共享写模式、 排他模式，其中共享写模式的增加使得在系统高并发情况下可以高效提升数据 库系统的并发吞吐能力

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述 中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付 出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是介绍本发明背景的一个示例图；

图2是介绍本发明背景的另一个示例图；

图3是介绍本发明背景的又一个示例图；

图4是介绍本发明背景的再一个示例图；

图5是介绍本发明背景的再一个示例图；

图6是介绍本发明背景的再一个示例图；

图7是根据本发明一个实施例的并发控制方法的示意性流程图；

图8是根据本发明一个实施例的并发控制装置的示意框图。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清 楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全 部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳 动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。

为了使读者理解什么是并发控制，首先将对本发明技术背景做进一步介绍。

由于目前主流的关系数据库通常都允许多个用户同时使用和共享，所以也 都具有并发控制的机制，也就是控制数据库，防止多用户并发使用数据库时造 成数据错误和程序运行错误，以保证数据的完整性。

当多用户并发存取数据时，就会产生多个事务同时存取同一数据的情况， 从而引起严重的数据错误和程序运行错误。那么，什么是事务及并发控制呢？

事务就是用户定义的一个数据库操作序列，这些操作要么全做，要么全不 做，是一个不可分割的很小的工作单位。例如，在SQL语言中，定义事务的语 句有三条：

BEGINTRANSACTION；

COMMIT；

ROLLBACK；

其中的BEGINTRANSACTION是事务开始的标记，而以COMMIT或者ROLLBACK 结束，COMMIT用于提交事务的所有操作，ROLLBACK则在事务运行过程中一旦 发生了某种故障而使事务无法继续执行的时候，系统就将事务中对数据库的所 有刚刚完成的操作全部撤消，滚动回到事务开始时的状态。为了充分利用系统 资源，使数据库的共享资源得以有效利用，必须可以使多个事务并行的执行， 而数据库对并行执行的事务进行的控制就是并发控制。

但是，由于种种原因，都可能引起数据库的数据遭到破坏，比如多个事务 在并行运行的时候，不同的事务的操作产生了交叉执行，或者，事务在运行过 程中被强行停或者中断。因此，事务在进行并发操作的时候很可能引起数据的 不一致，下面我们看一个具体的例子。例如飞机票的联网销售系统，如果有以 下的操作序列：

1.甲售票处(设置为T1事务)读出某班次的机票剩余数A，

设A＝20；

2.乙售票处(设置为T2事务)读出同班次的机票剩余数A，也是20；

3.甲售票处(T1事务)卖出一张机票，修改剩余数减一(A←A-1)，把A＝19 写回数据库中；

4.乙售票处(T2事务)也卖出一张机票，修改剩余数减一(A←A-1)，把 A＝19写回数据库中从这些操作中，我们看到，乙售票处的修改数据覆盖了甲售 票处修改的数据，实际发生了两张机票的销售，而数据库中却错误的存入19， 少了一张。参看图1的情况，这种情况是并发操作引起数据不一致的第一种情 况，叫做丢失修改(Lost Update)，参看图2的情况，这种情况是不可重复读 (Non-Repeatable Read)，不可重复读是指事务T1读数据以后，T2执行更新 操作，就使T1无法再现原先读取的数据，得到与上一次不同的结果。参看图3 的情况，这种情况是读“脏”数据(DirtyRead)，读“脏”数据是指T1修改某 数据并将其写回数据库，T2读取同一数据后，T1由于某种原因被撤消，T1执 行回滚，恢复到原始的数据，T2就读取到了过程中的一个作废的数据，这个数 据就是一种垃圾数据，称之为“脏”数据，也是不正确的。

从以上例子我们看到，数据不一致性的主要原因就是并发操作没有对事务 进行一定的隔离，所以，正确的调度应该使一个用户的事务不受到其他事务的 干扰，从而避免数据的不一致性。

在并发控制中采用封锁协议解决数据的不一致性并发控制的主要方法是封 锁(Locking)。就是要用正确的方式调度并发操作，使一个用户的事务在执行过 程中不受其他事务的干扰，从而避免造成数据的不一致性。封锁是使事务对它 要操作的数据有一定的控制能力。封锁通常具有3个环节:第一个环节是申请加 锁，即事务在操作前要对它将使用的数据提出加锁申请；第二个环节是获得锁， 即当条件成熟时，系统允许事务对数据进行加锁，从而事务获得数据的控制权； 第三个环节是释放锁，即完成操作后事务放弃数据的控制权。

现有的封锁类型有以下两种：

1.排它锁(Exclusive Locks，简称X锁)

排它锁也称为独占锁或写锁。一旦事务T对数据对象A加上排它锁(X锁)， 则只允许T读取和修改A，其他任何事务既不能读取和修改A，也不能再对A 加任何类型的锁，直到T释放A上的锁为止。

2.共享锁(Share Locks，简称S锁)

共享锁又称共享读锁。如果事务T对数据对象A加上共享锁(S锁)，其他 事务只能再对A加S锁，不能加X锁，直到事务T释放A上的S锁为止。在 对数据进行加锁时，另外需要约定并执行一些规则和协议，其中包括何时申请 锁，保持锁的时间以及何时释放等，这些规则就称为封锁协议(Locking  Protocol),其总共分为以下三级:

(1)一级封锁协议。一级封锁协议是事务T在修改数据之前必须先对其加X 锁，直到事务结束才释放。

(2)二级封锁协议。二级封锁协议是事务T对要修改数据必须先加X锁， 直到事务结束才释放X锁；对要读取的数据必须先加S锁，读完后即可释放S锁。

(3)三级封锁协议。三级封锁协议是事务T在读取数据之前必须先对其加S 锁，在要修改数据之前必须先对其加X锁，直到事务结束后才释放所有锁。

执行了封锁协议之后，就可以克服数据库操作中的数据不一致所引起的问 题。

如图4所示，事务T1在执行过程中独自占用并加X锁，直到处理完之后 再释放锁，T2虽然也需要使用，但是在封锁协议的约束之下，T2所要求的X锁 就被拒绝，因此必须处于等待状态，直到T1释放之后，T2才获得使用的权利， 这样就不会发生使用冲突，避免了数据的丢失。这里我们看到，此处实际上是 执行了一级封锁协议。

如图5所示，由于施行了封锁协议，使事务T1使用了共享锁占用A,B两 块数据,这样T2需要加上的X锁就无法实现，(如果是S锁，虽然可以加上, 但也不能够随便修改数据,只是读取一下数据。)当T1释放锁之后，T2就可以 得到并使用锁了,这样读取的数据B仍然还是100，不影响A+B的结果，这就是 可重复读取。这里用的就是三级封锁协议。

如图6所示，事务T1在对数据C修改之前，先加上了X锁，修改后写回 数据库，这时T2请求在C上添加S锁，因为T1加了X锁，T2只好等待，当 T1因为某种原因撤销了修改的数据后，C就恢复了原来的数据100，等T1释 放X锁后T2获得C上的S锁，读到的还是C＝100，因此避免了读出“脏” 数据。这里使用的其实就是二级封锁协议。

综上，数据库由于采用一定的封锁协议避免了数据的不一致性问题，这使 得数据库的并发控制有效而且有益，从而使得多项事务可以并行的操作数据库 的共享资源。这就是数据库合理的进行调度，避免了冲突，避免了数据的不一 致。

然而，上述的并发控制方法在保证数据一致性的前提下牺牲了部分数据库 系统吞吐能力，为了使得在高并发情况下数据库吞吐能力不受限，本发明一个 实施例提供一种并发控制方法，如图7所示，所述方法包括：

S101、接收至少两条事务操作请求，所述至少两条事务操作请求中的每条 事务操作请求包括操作对象信息及操作类型信息，所述操作对象信息用于指示 所述事务操作请求的操作对象，所述操作类型信息包括写操作或读操作；

S103、根据所述至少两条事务操作请求进行用锁申请；

S105、根据所述用锁申请的请求锁状态和当前锁状态确定所述申请是否通 过；若是则确定用所述请求锁状态对所述至少两条事务操作请求进行并发控制； 其中，所述锁状态至少包括三种模式：共享读模式、共享写模式、排他模式， 其中所述共享写模式包括允许大于或等于两个的写操作对所述操作对象同时进 行写操作，所述锁状态包括所述请求锁状态和所述当前锁状态。

因此，本发明实施例通过提供至少三种锁状态，包括共享读模式、共享写 模式、排他模式，其中共享写模式包括允许大于或等于两个的写操作对所述操 作对象同时进行写操作，使得写操作之间可以并行，从而有效提升高并发情况 下数据库系统的吞吐能力。

在上述实施例的基础上，可选的，步骤S105、根据所述用锁申请的请求锁 状态和当前锁状态确定所述申请是否通过可以具体包括：

当所述请求锁状态和所述当前锁状态均为共享读模式，或，所述请求锁状 态和所述当前锁状态均为共享写模式，则通过所述申请。

在发明的另一个可选的实施例中，若所述申请不通过则等待下一次用锁时 机重新进行用锁申请，所述下一次用锁时机包括所述当前锁状态结束时的时机。

具体的，所述申请不通过可以包括：当所述请求锁状态或所述当前锁状态 为排他模式，或，当所述请求锁状态为共享写模式时所述当前锁状态为共享读 模式，或，所述请求锁状态为共享读模式时所述当前锁状态为共享写模式，则 所述申请不通过。

在上述所有实施例的基础上，本发明实施例还提供另一种实施方法，即所 述操作对象包括多个局部操作对象，所述大于或等于两个的写操作对所述操作 对象同时进行写操作包括：所述大于或等于两个的写操作分别对所述操作对象 的多个局部操作对象中的不同局部操作对象进行写操作。

应理解的是，各个写操作分别针对不同局部操作对象进行写操作时方可应 用所述并行写模式的锁。

值得说明的是，实施例中所述的共享读模式即前文所述共享锁(Share  Locks，简称S锁)，实施例中所述排他模式即前文所述排它锁(Exclusive Locks， 简称X锁)，此处不再赘述。

举个例子，当前锁状态为共享读模式，此时有个用锁申请请求，其请求的 请求锁状态为共享读模式，则此时通过该用锁申请；

当前锁状态为共享写模式，此时有个用锁申请请求，其请求的请求锁状态 为共享写模式，则此时通过该用锁申请；

但是，若当前锁状态为排他模式，此时有个用锁申请请求，则无论该请求 的请求锁状态为什么模式，此时该用锁申请均不通过；或，

无论当前锁状态为什么模式，此时有个用锁申请请求，该请求的请求锁状 态为排他模式，则此时该用锁申请均不通过；

并且，若当前锁状态为共享写模式，此时有个用锁申请请求，该请求的请 求锁状态为共享读模式，则此时该用锁申请不通过；或，

若当前锁状态为共享读模式，此时有个用锁申请请求，该请求的请求锁状 态为共享写模式，则此时该用锁申请不通过。

上文中结合图1至图7，详细描述了根据本发明实施例的并发控制方法，下 面结合图8详细描述根据本发明实施例的并发控制装置。

在描述本发明实施例的并发控制装置之前，先介绍数据库系统的基本情况：

数据库系统大体上可以分为四个组件：连接管理系统，编译执行系统，存 储管理系统和事务系统。其中事务系统是整个数据库系统中最核心也是最复杂 的模块，几乎所有其他模块都依赖于事务系统。客户端发起的一个query动作， 经由连接管理系统到达数据库内核，在内核中，先由编译执行系统对query进行 解析和生成执行计划，再交由执行引擎执行，执行过程中通过存储引擎访问存 储器数据。整个过程都会受到事务系统的控制。

事务系统总共分为三个模块：事务管理器、日志管理器、并发锁控制。本 发明即围绕着并发锁控制模块来展开的。

如图8所示，本发明实施例提供一种并发控制装置800，包括包括接收模块 801、用锁申请模块803、中枢决策模块805及决策执行模块807：

其中，接收模块801，用于接收至少两条事务操作请求，所述至少两条事务 操作请求中的每条事务操作请求包括操作对象信息及操作类型信息，所述操作 对象信息用于指示所述事务操作请求的操作对象，所述操作类型信息包括写操 作或读操作；

用锁申请模块803，用于根据所述至少两条事务操作请求进行用锁申请；

中枢决策模块805，用于根据所述用锁申请的请求锁状态和当前锁状态确定 所述申请是否通过；若是则通过决策执行模块807确定用所述请求锁状态对所 述至少两条事务操作请求进行并发控制；其中，所述锁状态至少包括三种模式： 共享读模式、共享写模式、排他模式，其中所述共享写模式包括允许大于或等 于两个的写操作对所述操作对象同时进行写操作，所述锁状态包括所述请求锁 状态和所述当前锁状态。

因此，本发明实施例通过提供至少三种锁状态，包括共享读模式、共享写 模式、排他模式，其中共享写模式包括允许大于或等于两个的写操作对所述操 作对象同时进行写操作，使得写操作之间可以并行，从而有效提升高并发情况 下数据库系统的吞吐能力。

在上述实施例的基础上，可选的，所述中枢决策模块具体用于确定：

当所述请求锁状态和所述当前锁状态均为共享读模式，或，所述请求锁状 态和所述当前锁状态均为共享写模式，则通过所述申请。

在上述实施例的基础上，进一步可选的，若所述中枢决策模块确定所述申 请不通过，则所述中枢决策模块确定等待下一次用锁时机重新进行用锁申请， 所述下一次用锁时机包括所述当前锁状态结束时的时机。

其中，所述中枢决策模块还可以具体用于确定：

当所述请求锁状态或所述当前锁状态为排他模式，或，当所述请求锁状态 为共享写模式时所述当前锁状态为共享读模式，或，所述请求锁状态为共享读 模式时所述当前锁状态为共享写模式，则所述申请不通过。

值得注意的是，所述操作对象可以包括多个局部操作对象，所述大于或等 于两个的写操作对所述操作对象同时进行写操作包括：所述大于或等于两个的 写操作分别对所述操作对象的多个局部操作对象中的不同局部操作对象进行写 操作。

应当说明的是，本发明实施例的应用场景不仅仅局限于事务管理器，也不 局限于数据库领域，对于其他场景，如操作系统，应用软件等，只要具有本方 案应用场景特点的领域均可适用。

举个例子，在应用软件领域，比如Dota等格斗类游戏应用中，很重要的一 个信息就是用生命能量方格条来显示各个战斗队员当前时刻还有几滴血，以此 来表征还剩下多少生命能量。对于整个游戏系统而言，所有成员的“生命能量 方格条“信息通过一个全局列表来维护。格斗过程中，每个成员的生命能量就 会实时更新到全局列表相应的方格条中，各个成员的更新动作互不冲突，因此 可以采用本发明方案并行更新，以提升游戏整体效率，提升游戏玩家的满意度。

并且，还值得说明的是，本发明实施例不局限于单机应用场景，在集、 分布式等领域中也同样适用。比如集场景中，各个节点的状态信息会通过主 节点以一个全局状态列表的方式进行维护，每个节点更新状态时，需要向主节 点发起更新状态请求，由于是对全局共享列表进行更新，因此，需要申请使用 排他写模式的锁，被允许更新后再执行实际更新操作。而每个节点更新请求仅 需要更新主节点全局状态列表中与本节点相对应的信息即可，各个节点更新的 位置互不冲突。该场景下，即可采用本发明实施例所提供的方案，申请使用共 享写模式的锁来提升系统并发度。