CN112084206A - 数据库的事务请求处理方法、相关设备及存储介质 - Google Patents

Abstract

本发明公开了数据库的事务请求处理方法、相关设备及存储介质，该方法包括：接收针对数据库中第一数据行的更新事务请求；若存储引擎中存在第一数据行的第一热行更新等待队列，则将更新事务请求写入第一热行更新等待队列；若存储引擎中不存在第一数据行对应的第一热行更新等待队列，则确定存储引擎中第一数据行对应的第一行锁等待队列的队列长度；当第一行锁等待队列的队列长度超过预设长度阈值时，在存储引擎中为第一数据行创建对应的第一热行更新等待队列，将更新事务请求写入该第一热行更新等待队列；响应于预设触发信号，将第一热行更新等待队列中的更新事务请求加入第一行锁等待队列。本发明提高了数据库系统在高并发情况下的事务吞吐率。

Description

数据库的事务请求处理方法、相关设备及存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种数据库的事务请求处理方法、相关设备及存储介质。

背景技术

在数据库系统，当有大量的并发事务针对数据库中的同一数据行发出更新操作时，该数据行即成为热点数据行。为了确保数据库系统在高并发情况下的事务吞吐率，一般会针对热点数据行的更新事务请求进行限流处理。

以关系型数据库系统MySQL为例，相关技术中通过增加SQL热点数据行更新hint语法，让MySQL用户在提交SQL语句(即事务请求)时提供热点数据行的主键，MySQL收到带热点数据行hint的SQL语句后，提取出热点数据行主键，然后在MySQL的Server层针对热点数据行主键对事务请求进行排队，确保在任一时刻每个热点数据行主键只有一个事务正在执行操作直至该事务执行结束。

上述相关技术的实现需要改变SQL语法，增加了MySQL用户工作负担，用户若要使用热点数据行功能，需要改变原有应用程序的SQL语句以提供满足上述功能语法格式的SQL语句；此外，由于MySQL用户需要提供热点数据行的主键，因此热点数据行的感知需要由用户来做，这意味着用户程序需要再分配一些系统资源来统计哪些数据行是热点，比如需要用额外的键值缓存系统来存储数据库中数据行的访问频率、主键等信息，同时还需要随着热点变更即时更新维护这些信息，大大增加了数据库用户的维护成本；而且在Server层对热点数据行的更新事务请求用锁作序列化，降低了对同一热点数据行的更新事务之间的并发度，无法充分利用数据库系统闲置资源，不利于提高数据库系统在高并发情况下的事务吞吐率。

发明内容

为了解决现有技术的问题，本发明实施例提供了一种数据库的事务请求处理方法、相关设备及存储介质。所述技术方案如下：

一方面，提供了一种数据库的事务请求处理方法，所述方法包括：

接收针对数据库中第一数据行的更新事务请求；

若存储引擎中存在所述第一数据行对应的第一热行更新等待队列，则将所述更新事务请求写入所述第一热行更新等待队列；

若所述存储引擎中不存在所述第一数据行对应的第一热行更新等待队列，则确定所述存储引擎中所述第一数据行对应的第一行锁等待队列的队列长度；

当所述第一行锁等待队列的队列长度超过预设长度阈值时，在所述存储引擎中为所述第一数据行创建对应的所述第一热行更新等待队列，将所述更新事务请求写入所述第一热行更新等待队列；

响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列。

另一方面，提供了一种数据库的事务请求处理装置，所述装置包括：

接收模块，用于接收针对数据库中第一数据行的更新事务请求；

第一写入模块，用于在存储引擎中存在所述第一数据行对应的第一热行更新等待队列时，将所述更新事务请求写入所述第一热行更新等待队列；

第一确定模块，用于在所述存储引擎中不存在所述第一数据行对应的第一热行更新等待队列时，确定所述存储引擎中所述第一数据行对应的第一行锁等待队列的队列长度；

创建模块，用于当所述第一行锁等待队列的队列长度超过预设长度阈值时，在所述存储引擎中为所述第一数据行创建对应的所述第一热行更新等待队列，将所述更新事务请求写入所述第一热行更新等待队列；

第二写入模块，用于响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列。

作为一个可选的方式，所述第二写入模块包括：

第一监测模块，用于监测所述第一行锁等待队列中是否有更新事务请求接收到所述第一数据行的行锁；

第一信号产生模块，用于在所述第一监测模块监测到有时，产生第一预设触发信号，所述预设触发信号包括所述第一预设触发信号；

第一写入子模块，用于响应于所述第一预设触发信号，将所述第一热行更新等待队列中位于队首的首更新事务请求加入所述第一行锁等待队列。

作为另一个可选的方式，所述第二写入模块包括：

第二监测模块，用于监测所述第一热行更新等待队列中各更新事务请求的等待时长；

第二信号产生模块，用于在监测到所述等待时长超过预设时长时，产生第二预设触发信号，所述预设触发信号包括所述第二预设触发信号；

第二写入子模块，用于响应于所述第二预设触发信号，将所述等待时长超过预设时长的目标更新事务请求加入所述第一行锁等待队列。

作为一个可选的方式，所述装置还包括：

死锁检测模块，用于对所述第一行锁等待队列进行死锁检测，确定所述第一行锁等待队列中产生死锁的死锁更新事务请求；

回滚模块，用于对所述死锁更新事务请求进行回滚操作。

作为一个可选的方式，所述装置还包括：

第三写入模块，用于在所述第一行锁等待队列的队列长度未超过所述预设长度阈值时，将所述更新事务请求写入所述第一行锁等待队列。

作为一个可选的方式，所述装置还包括：

第二确定模块，用于确定所述存储引擎中各数据行对应的更新事务请求的事务总数量；

发送模块，用于在所述事务总数量小于预设事务数量阈值时，将所述更新事务请求发送给所述存储引擎。

作为一个可选的方式，所述装置还包括：

第三确定模块，用于确定所述第一行锁等待队列中各更新事务请求所对应的目标更新字段；

第四确定模块，用于确定具有相同目标更新字段的至少一个更新事务请求；

请求合并模块，用于根据所述至少一个更新事务请求中各更新事务请求的更新指令，合并所述至少一个更新事务请求，得到合并事务请求。

另一方面，提供了一种计算机设备，包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现上述数据库的事务请求处理方法。

另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如上述的数据库的事务请求处理方法。

另一方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的方法。

本发明实施例在接收到针对数据库中第一数据行的更新事务请求时查询存储引擎，若存储引擎中存在与该第一数据行对应的第一热行更新等待队列，则将该更新事务请求写入该第一热行更新等待队列，若存储引擎中不存在与该第一数据行对应的第一热行更新等待队列，则确定该存储引擎中第一数据行对应的第一行锁等待队列的队列长度，当该第一行锁等待队列的队列长度超过预设长度阈值时，在存储引擎中为该第一数据行创建对应的第一热行更新等待队列，将上述更新事务请求写入该第一热行更新等待队列，并响应于预设触发信号将第一热行更新等待队列中的更新事务请求加入第一行锁等待队列，上述技术方案无需改动任何SQL语法，不需要用户侧做任何的热点行信息维护工作，在数据库的存储引擎层自动的发现热点数据行，并在存储引擎层对热点数据行的行锁等待队列入队操作进行限流，使得对同一热点数据行更新的多个事务能够得到更高的并发度，利用上更多的系统资源，大大提高了数据库系统在高并发情况下的事务吞吐率。

附图说明

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

图1是本发明实施例提供的一种实施环境的示意图；

图2是本发明实施例提供的MySQL的基础结构示意图；

图3是本发明实施例提供的数据库的事务请求处理方法的流程示意图；

图4是本发明实施例提供的另一种数据库的事务请求处理方法的流程示意图；

图5(a)是本发明实施例提供的另一种数据库的事务请求处理方法的流程示意图；

图5(b)是本发明实施例提供的另一种数据库的事务请求处理方法的流程示意图；

图6是本发明实施例提供的另一种数据库的事务请求处理方法的流程示意图；

图7是本发明实施例提供的另一种数据库的事务请求处理方法的流程示意图；

图8(a)是本发明实施例提供的在第一场景下的对比实验结果示意图；

图8(b)是本发明实施例提供的在第二场景下的对比实验结果示意图；

图9是本发明实施例提供的数据库的事务请求处理装置的结构示意图；

图10是本发明实施例提供的一种服务器的硬件结构框图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

请参阅图1，其所示为本发明实施例提供的一种实施环境示意图，该实施环境可以包括终端110和服务器120，终端110以及服务器120可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

终端110中可以安装有服务器120提供服务的客户端，终端110可以通过该客户端实现例如数据传输、消息交互(如发送更新事务请求以及接收返回的响应数据)等功能。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。

服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

数据库(Database)，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行查询、更新(可以包括修改、新增、删除)等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

数据库管理系统(英语：Database Management System，简称DBMS)是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML(Extensible MarkupLanguage,即可扩展标记语言)；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL(结构化查询语言(Structured QueryLanguage)、XQuery；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。

图1所示服务器120中的数据库管理系统可以是关系型数据库管理系统如MySQL，也可以是其他兼容关系型数据库管理系统的数据库系统如分布式云数据库CynosDB等等。本发明实施例中以数据库管理系统为MySQL为例来说明本发明实施例提供的数据库的事务请求处理方法。

如图2所示为MySQL的基础结构示意图，MySQL的基础结构包括两层分别为Server层和存储引擎层。

MySQLServer层对接多个用于管理数据的存储引擎，MySQLServer层包括连接层和SQL层。其中，连接层用于实现终端的应用程序与MySQL的连接；SQL层负责权限判断、查询缓存、SQL语法解析、SQL语句优化、SQL语句执行、MySQL协议等功能。

MySQL存储引擎层包括为MySQLServer层提供包含数据表存储、检索、事务等功能的多个存储引擎实现。其中，InnoDB存储引擎是最为常用的MySQL默认存储引擎，其提供了事务处理、行锁系统、数据行存储与检索等功能。

MySQL数据库系统的最小数据单位是一行(数据行)，它是组成MySQL表的基本单位，一个表的所有行具有相同的格式。

为实现MySQL的事务并发安全访问数据表中的不同行，MySQL的InnoDB存储引擎提供了以行为粒度的加锁能力，该功能整体被称为行锁系统。在行锁系统中，InnoDB存储引擎为数据表中每个行(即数据行)维护一个行锁等待队列，该行锁等待队列中按序排列着需要获取相应行对应行锁的更新事务请求，各更新事务请求只有在获取到相应行的行锁时才能对该数据行执行其更新事务请求中的更新操作，并在执行完更新时释放行锁，可以将该行锁递交给相应行锁等待队列中的下一个更新事务请求。

实际应用中，当两个更新事务分别获得了对方所需要的行锁，同时又想要请求获得对方的行锁时，这两个更新事务便进入了循环等待的情形，而此时数据库系统会因该循环等待而进入了死锁状态。

需要说明的是，一个更新事务请求为作为单个逻辑工作单元执行的一系列更新操作，由一系列更新操作指令构成，如语句。其中，更新操作可以包括对数据行中数据记录的修改、新增、删除等。

实际应用中，当有大量的并发事务对MySQL数据库中同一个表的同一行的数据记录进行更新时，可以将该行称为热点数据行。

相关技术中，在实现热点数据行更新时对并发更新事务请求的处理不仅加重了数据库用户侧的工作负担和维护成本，而且在Server层进行加锁排队降低了对同一热点数据行的更新事务之间的并发度，无法充分利用数据库系统闲置资源，不利于提高数据库系统在高并发情况下的事务吞吐率。

同时，在实现本发明的过程中，发明人还发现在更新热点数据行时，热点数据行对应的行锁等待队列的队列长度与并发度紧密相关，同时死锁检测是每个更新事务请求执行的必要步骤，在执行死锁检测时会锁住整个行锁系统，死锁检测的执行时间复杂度与行锁等待队列的队列长度紧密相关。在更新热点数据行时，随着并发度的增加，热点数据行的行锁等待队列的队列长度增加会导致死锁检测代价快速增加，进而会导致系统的整体事务吞吐率急剧下降。

综合以上考虑，本发明提出了基于存储引擎层限流的数据库的事务请求处理方法，该方法不改变SQL语法，在存储引擎层自动的发现热点数据行，并对热点数据行的行锁等待队列入队操作进行限流，控制热点数据行所对应行锁等待队列的队列长度，从而控制了死锁检测的开销，在为用户提供了透明的热点数据行检测的同时进行限流保护，实现了在高并发情况下系统资源保持高效的利用率和高的事务吞吐率，可以用于优化如电商商品秒杀等服从幂分布的高频更新工作负载。

本发明实施例中，对于维护了行锁系统的存储引擎如InnoDB，每个数据行都会对应一个行锁等待队列，而当该行锁等待队列的队列长度超过一定阈值(比如阈值为32)时，由于死锁检测代价与该队列长度正相关，整个系统的事务吞吐率将开始降低，因此，本发明实施例采用了基于行锁等待队列的队列长度与阈值的关系来判断一个数据行是否为热点数据行。并且，本发明实施例在存储引擎层为发现的热点数据行创建一个独立的队列，称为热行更新等待队列，所有后续尝试对该热点数据行加锁的事务请求在发现该数据行存在热行更新等待队列后，会首先将自己加入该热行更新等待队列进行等待，直到行锁等待队列长度低于阈值之后，才会真正进入相应的行锁等待队列，这样能够保证行锁等待队列的队列长度保持在一个阈值之内，不受并发度增加的影响，进而控制死锁检测的开销。

下面从事务对于热点数据行的更新加锁角度来对本发明实施例的技术方案进行详细说明。

请参阅图3，其所示为本发明实施例提供的一种数据库的事务请求处理方法的流程示意图，该方法可以应用于图1中的服务器。需要说明的是，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图3所示，所述方法可以包括：

S301，接收针对数据库中第一数据行的更新事务请求。

其中，第一数据行可以是数据库中任一表的任一数据行。更新事务请求用于请求对第一数据行中的数据记录进行更新操作，该更新操作可以包括修改、新增和删除，更新事务请求可以是终端对应的用户在操作终端的客户端时产生。

以电商商品秒杀的场景为例，一般商品秒杀活动中参与秒杀的各个秒杀商品的数量是预定的，例如某个秒杀商品预定有100件参与秒杀活动，则电商平台的后台服务器可以在数据库中维护一个秒杀商品数据表，该秒杀商品数据表中每个数据行对应记录一个秒杀商品的相关信息，包括剩余数量。当终端用户通过客户端在电商平台上购买了某个秒杀商品时，客户端可以产生对应该秒杀商品的更新事务请求，并将该更新事务请求发送给后台服务器，相应的后台服务器在接收到该更新事务请求后，可以根据该更新事务请求对数据库的秒杀商品数据表中对应该秒杀商品的数据行进行数据记录更新操作，如修改剩余数量，将剩余数量减1等。

对于MySQL，可以由MySQLServer层所包含的连接层与终端中的客户端建立连接，并接收客户端发送的更新事务请求。

S303，判断存储引擎中是否存在所述第一数据行对应的第一热行更新等待队列，若存在，则执行步骤S305；若不存在，则执行步骤S307至步骤S309。

S305，将所述更新事务请求写入所述第一热行更新等待队列。

具体的，在存储引擎中存在与第一数据行对应的第一热行更新等待队列时，表明该第一数据行目前是热点数据行，此时将更新事务请求写入第一热行更新等待队列中，而非直接写入第一数据行对应的行锁等待队列，可以很好的避免高并发导致的行锁等待队列过长，死锁检测开销大对系统事务吞吐率的影响，保证了系统具有高的事务吞吐率。

其中，第一热行更新等待队列可以是顺序队列，也可以是循环队列，优选的为先进先出队列。

S307，确定所述存储引擎中所述第一数据行对应的第一行锁等待队列的队列长度。

S309，判断所述第一行锁等待队列的队列长度是否超过预设长度阈值，若超过，则执行步骤S311。

其中，预设长度阈值的大小可以根据实际应用中对于系统的事务吞吐率需求进行设定，一般事务吞吐率需求高，则可以将预设长度阈值设置的小一些，而事务吞吐率需求不要求太高时，可以将预设长度阈值设置的稍微大一些。作为一个可能的实施方式，该预设长度阈值可以设置为32，也即行锁等待队列中最多可以允许排列32个更新事务。

S311，在所述存储引擎中为所述第一数据行创建对应的所述第一热行更新等待队列，将所述更新事务请求写入所述第一热行更新等待队列。

本发明实施例中，当第一行锁等待队列的队列长度超过了预设长度阈值，则表明有大量针对第一数据行的并发请求，此时第一数据行成为了热点数据行，可以为其在存储引擎层创建对应的第一热行更新等待队列，并将新接收的更新事务请求写入到该第一热行更新等待队列中，从而可以避免第一行锁等待队列由于队列长度过长所导致的死锁检测开销过大，进而使得系统的事务吞吐率得到提高。

作为一个可能的实施方式，如图4所示，若第一数据行不存在热行更新等待队列，且步骤S309判断的结果是该第一数据行对应的第一行锁等待队列的队列长度未超过预设长度阈值，则表明该第一数据行当前不是热点数据行，此时可以执行步骤S315，将新接收的更新事务请求直接写入该第一行锁等待队列。

如图4中S317至S319中所示，第一行锁等待队列中的各更新事务请求根据排列顺利，在获取到第一数据行的行锁时，可以基于该行锁对第一数据行中的数据记录进行更新操作，并在更新操作执行完成时释放行锁，将该行锁传递给第一行锁等待队列中的下一个更新事务请求。

需要说明的是，本发明实施例中行锁等待队列中的更新事务请求处于正常的行锁获取流程中，可以直接获取到行锁进而对相应的数据行进行更新操作；而热行更新等待队列中的更新事务请求并不能直接获取到行锁，并未处于正常的行锁获取流程中，其状态可以理解为等待进入行锁等待队列的待唤醒状态，热行更新等待队列中的更新事务请求只有被唤醒加入到相应的行锁等待队列中后才能进入正常的行锁获取流程中获取行锁。因此，在本发明实施例中，只有行锁等待队列会进行死锁检测，而对热行更新等待队列不进行死锁检测。

S313，响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列。

具体的，在加入第一行锁等待队列时可以根据该第一行锁等待队列的入队规则进入该第一行锁等待队列，例如该入队规则可以是将该新加入的更新事务请求写入到第一行锁等待队列的队尾。

本发明实施例中，第一热行更新等待队列中的更新事务请求将会在以下两种情形下被唤醒完成等待。

第一种情形，是由第一行锁等待队列中获得行锁的更新事务请求唤醒。一般而言，当一个更新事务请求在行锁等待队列中获取到行锁，并执行完相应的更新操作需要释放行锁时，会将该行锁传递给该行锁等待队列中的下一个更新事务请求，若该行锁等待队列对应的数据行为热点数据行时，则还会唤醒该数据行对应的热行更新等待队列中位于队首的更新事务请求，并让其加入到该热点数据行对应的行锁等待队列以进入正常的行锁获取流程中。

第二种情形，是由等待超时而唤醒。当一个更新事务请求在热行更新等待队列中等待时间过长时，有可能是因为该更新事务请求中的事务内容含有多行更新，并由于在热行更新等待队列无限等待而发生了死锁。本发明实施例在热行更新等待队列中更新事务请求的等待时长超过一定阈值时，会自动超时醒来，直接加入相应的行锁等待队列，并对加入后的行锁等待队列进行死锁检测以便发现死锁与处理死锁。

与上述第一种情形相对应，上述的预设触发信号可以包括用于唤醒第一热行更新等待队列中更新事务请求的第一预设触发信号，具体的，本发明实施例在执行步骤S313时可以包括如图5(a)中的以下步骤：

S501a，监测所述第一行锁等待队列中是否有更新事务请求接收到所述第一数据行的行锁。

具体的，当前更新事务请求在所对应的更新操作执行完毕时释放行锁，并将该行锁传递给第一行锁等待队列中的下一个更新事务请求，该下一个更新事务请求在获取到行锁后便可以出队执行相应的更新操作了，此时第一行锁等待队列的队列长度将会小于预设长度阈值，通过对第一行锁等待队列中是否有更新事务请求接收到第一数据行的行锁进行监测，可以及时将第一热行更新等待队列中的更新事务请求加入到正常的行锁获取流程中。

若监测到第一行锁等待队列中有更新事务请求接收到第一数据行的行锁，则可以执行步骤S501a。

S503a，产生第一预设触发信号。

S505a，响应于所述第一预设触发信号，将所述第一热行更新等待队列中位于队首的首更新事务请求加入所述第一行锁等待队列。

具体的，可以将第一热行更新等待队列中位于队首的首更新事务请求加入第一行锁等待队列的队尾，从而使得热行更新等待队列中的更新事务请求及时进入到正常的行锁获取流程中，保证了系统的高事务吞吐率。

与上述第二种情形相对应，上述的预设触发信号可以包括用于唤醒第一热行更新等待队列中更新事务请求的第二预设触发信号，具体的，本发明实施例在执行步骤S313时可以包括如图5(b)中的以下步骤：

S501b，监测所述第一热行更新等待队列中各更新事务请求的等待时长。

具体的，可以为每个第一热行更新等待队列配置一个计时器，该计时器可以记录每个相应热行更新等待队列中各更新事务请求的入队时长，该入队时长即为等待时长。

S503b，在监测到所述等待时长超过预设时长时，产生第二预设触发信号。

其中，预设时长可以根据实际应用中的经验进行设定，本发明对此不作具体限定。

S505b，响应于所述第二预设触发信号，将所述等待时长超过预设时长的目标更新事务请求加入所述第一行锁等待队列。

其中，目标更新事务请求可能是一个更新事务请求，也可能是多个更新事务请求。

本发明实施例中，当热行更新等待队列中为空时，表明对于该热行更新等待队列对应的热点数据行的更新事务请求都能加入到相应的行锁等待队列，也即该行锁等待队列的队列长度已经小于预设长度阈值，也即表明该热行更新等待队列对应的热点数据行已经由热点数据行转为普通数据行，此时可以删除该数据行对应的热行更新等待队列。

实际应用中，在将等待时长超过预设时长的目标更新事务请求加入到第一行锁等待队列之后，还可以包括图5(b)中的以下步骤：

S507b，对所述第一行锁等待队列进行死锁检测，确定所述第一行锁等待队列中产生死锁的死锁更新事务请求。

当热行更新等待队列中出现等待时长超过预设时长的目标更新事务请求时，很有可能这些目标更新事务请求的更新操作内容中含有多行更新，并由于在热行更新等待队列无限等待而发生了死锁。因此，在将这些目标更新事务请求加入到相应的行锁等待队列中之后，对该行锁等待队列及时进行死锁检测以确定出产生死锁的死锁更新事务请求。

S509b，对所述死锁更新事务请求进行回滚操作。

实际应用中，当两个事务请求分别获得了对方所需要的行锁，同时又想要请求获取对方的行锁时，这个时候系统变进入了死锁。MySQL的InnoDB存储引擎提供了死锁检测的功能，能够通过检查行锁等待队列来发现这种循环等待的情况，并主动回滚掉其中一个死锁更新事务请求，让系统继续运行。

本发明实施例的技术方案无需改动任何SQL语法，不需要用户侧做任何的热点行信息维护工作，在数据库的存储引擎层自动的发现热点数据行，并在存储引擎层对热点数据行的行锁等待队列入队操作进行限流，使得对同一热点数据行更新的多个事务能够得到更高的并发度，利用上更多的系统资源，大大提高了数据库系统在高并发情况下的事务吞吐率。

为了能够更好的降低死锁检测的开销，提高系统在高并发情形下的事务吞吐率，在一个可能的实施方式中，如图6所示，服务器在接收到针对数据库中第一数据行的更新事务请求之后，还可以包括以下步骤：

S601，确定所述存储引擎中各数据行对应的更新事务请求的事务总数量。

S603，在所述事务总数量小于预设事务数量阈值时，将所述更新事务请求发送给所述存储引擎。

对于MySQL，其innodb存储引擎提供了innodb_thread_concurrency参数，该参数用于控制进入innodb存储引擎的物理线程数量也即更新事务请求数量，在默认情形下，该参数一般为零，表示不作任何限制。本发明实施例通过设置该参数来达到控制进入innodb存储引擎的线程数量，进而可以在热行更新等待队列的基础上进一步限制热点行锁等待队列的队列长度，进一步提高了系统在高并发情形下的事务吞吐率。

具体的，存储引擎中各数据行对应的更新事务请求的事务总数量可以通过统计各数据行对应的热行更新等待队列和行锁等待队列中的更新事务请求的数量和值得到。预设事务数量阈值可以通过获取存储引擎的thread_concurrency参数得到。具体的实施中，该参数可以设置为CPU的核心数与并发因子的乘积，其中，并发因子的取值范围可以为4～1000，其具体数值可以根据实际应用中的并发情况来选取。例如，并发因子为4，CPU的核心数为16，则存储引擎的thread_concurrency参数可以设置为16*4＝64。

在将更新事务请求发送给存储引擎时，可以根据事务总数量与预设事务数量阈值的差值，将该差值数量个的更新事务请求发送给存储引擎。

考虑到实际应用中，对于热点数据行的更新大多都是单点update，并且执行的SQL语句类似，比如都是对热点数据行的一个counter字段进行递增或递减，对于这种情况，为了进一步提高系统在高并发情形下的事务吞吐率，在一个可能的实施方式中，如图7所示，在响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列之后，还可以包括以下步骤：

S701，确定所述第一行锁等待队列中各更新事务请求所对应的目标更新字段。

S703，确定具有相同目标更新字段的至少一个更新事务请求。

S705，根据所述至少一个更新事务请求中各更新事务请求的更新指令，合并所述至少一个更新事务请求，得到合并事务请求。

举例而言，第一行锁等待队列中有10个更新事务请求对应的目标更新字段都是counter字段，且更新指令均为递增1，则可以将这个10个更新事务请求合并为一个合并事务请求，该合并事务请求对应的更新指令为对该counter字段加10，从而能够大大降低行锁等待队列的队列长度，有利于提高系统在高并发情形下的事务吞吐率。

考虑到对于行锁等待队列的死锁检测的运行时间与行锁等待队列的队列长度正相关，若关闭死锁检测则可以避免死锁检测对系统的并发事务吞吐率的影响，进而可以保证系统具有很高的并发事务吞吐率。但是，关闭死锁检测之后，需要依赖设置合适的lock_wait_timeout参数值来解决死锁问题，让死锁事务超时后直接返回失败。鉴于此，作为另一个可能的实施方式，还可以关闭存储引擎中对于行锁等待队列的死锁检测，那么，相应的在响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列之后，该方法还可以包括以下步骤：

1)确定所述第一行锁等待队列中各更新事务请求的锁等待时长；

2)确定所述锁等待时长超过预设等待时长的更新事务请求，其中，预设等待时长可以根据实际经验进行设定，例如可以设定为50秒。

3)将所述锁等待时长超过预设等待时长的更新事务请求确定为死锁更新事务请求；

4)将所述死锁更新事务请求从所述第一行锁等待队列中移除，并返回所述死锁更新事务请求执行失败的消息。

本发明实施例通过存储引擎层面的细粒度限流，对用户侧提供完成透明的热度数据行检测与限流功能，确保在高并发情况下，系统资源保持高效的利用和高事务吞吐，可于优化如电商商品秒杀等服从幂律分布的高频更新工作负载。

为了验证本发明的有益效果，本发明实施例做了以下两组对比实验。

第一组，单热点数据行场景

在该组实验中，测试的MySQL表中含有一行热点数据，所有更新事务请求都对该热点数据行的某一个字段进行更新。如图8(a)所示是现有技术1、本发明和现有技术2在该组场景下的实验结果示意图，其中，现有技术1未对数据库的更新事务请求做任何限流处理，现有技术2采用了背景技术中所述通过修改SQL语法并在MySQL Server层进行限流处理。

由图8(a)可以看到，随着更新事务请求并发度的上升，在现有技术1的方案下，系统的事务吞吐率(TPS)开始了出现急剧下降；而在本发明实施例的技术方案下，在高并发的情况下，系统仍具有很高的事务吞吐率，且事务吞吐率没有出现急剧下降的问题；在现有技术2的方案下，系统的事务吞吐率虽然保持稳定，但非常小，原因是现有技术2对所有更新事务请求在Server层用锁序列化，导致每个更新事务请求都是按顺序执行，没有任何并发执行的可能，因此其CPU利用率很低，整体的事务吞吐率要远低于现有技术1和本发明。本发明的更新事务请求的序列化只在必要的时候做即只在加行锁阶段，而事务处理的其他部分可以并行执行，因此提高了CPU利用率和事务吞吐率(TPS)。

第二组，多热点数据行场景

在该组实验中，采用和第一组类似的更新操作，不同之处在于增加热点数据行的数量到32个，每个热点数据行的访问概率相同。如图8(b)所示是现有技术1、本发明和现有技术2在该组场景下的实验结果示意图，其中，现有技术1未对数据库的更新事务请求做任何限流处理，现有技术2采用了背景技术中所述通过修改SQL语法并在MySQL Server层进行限流处理。

由图8(b)可以看到，相对于第一组实验结果现有技术1方案下的系统事务吞吐率(TPS)得到了增加，这主要是因为热点数据行的数量多了，并发度没有变，每个热点数据行得到的并发更新事务请求数量也会下降，进而降低了死锁检测代价，系统整体TPS因此得到增加，与本发明的TPS差距也有所缩小；相对于第一组实验结果现有技术2方案下的TPS也有所增加，主要还是因为热点数据行多了，但与本发明相比，现有技术2的TPS始终低于本发明。

由此可见，本发明在单/多热点数据行场景下对系统高并发热点数据行的更新事务请求的事务吞吐率都有很大提升，且系统事务吞吐率远高于现有技术。

与上述几种实施例提供的数据库的事务请求处理方法相对应，本发明实施例还提供一种数据库的事务请求处理装置，由于本发明实施例提供的数据库的事务请求处理装置与上述几种实施例提供的数据库的事务请求处理方法相对应，因此前述数据库的事务请求处理方法的实施方式也适用于本实施例提供的数据库的事务请求处理装置，在本实施例中不再详细描述。

请参阅图9，其所示为本发明实施例提供的一种数据库的事务请求处理装置的结构示意图，该装置具有实现上述方法实施例中数据库的事务请求处理方法的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。如图9所示，该装置可以包括：

接收模块910，用于接收针对数据库中第一数据行的更新事务请求；

第一写入模块920，用于在存储引擎中存在所述第一数据行对应的第一热行更新等待队列时，将所述更新事务请求写入所述第一热行更新等待队列；

第一确定模块930，用于在所述存储引擎中不存在所述第一数据行对应的第一热行更新等待队列时，确定所述存储引擎中所述第一数据行对应的第一行锁等待队列的队列长度；

创建模块940，用于当所述第一行锁等待队列的队列长度超过预设长度阈值时，在所述存储引擎中为所述第一数据行创建对应的所述第一热行更新等待队列，将所述更新事务请求写入所述第一热行更新等待队列；

第二写入模块950，用于响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列。

在一个可能的实施方式中，第二写入模块950可以包括：

第一监测模块，用于监测所述第一行锁等待队列中是否有更新事务请求接收到所述第一数据行的行锁；

第一信号产生模块，用于在所述第一监测模块监测到有时，产生第一预设触发信号，所述预设触发信号包括所述第一预设触发信号；

第一写入子模块，用于响应于所述第一预设触发信号，将所述第一热行更新等待队列中位于队首的首更新事务请求加入所述第一行锁等待队列。

在另一个可能的实施方式中，第二写入模块950可以包括：

第二监测模块，用于监测所述第一热行更新等待队列中各更新事务请求的等待时长；

第二信号产生模块，用于在监测到所述等待时长超过预设时长时，产生第二预设触发信号，所述预设触发信号包括所述第二预设触发信号；

第二写入子模块，用于响应于所述第二预设触发信号，将所述等待时长超过预设时长的目标更新事务请求加入所述第一行锁等待队列。

在一个可能的实施方式中，该装置还可以包括：

死锁检测模块，用于对所述第一行锁等待队列进行死锁检测，确定所述第一行锁等待队列中产生死锁的死锁更新事务请求；

回滚模块，用于对所述死锁更新事务请求进行回滚操作。

在一个可能的实施方式中，该装置还可以包括：

第三写入模块，用于在所述第一行锁等待队列的队列长度未超过所述预设长度阈值时，将所述更新事务请求写入所述第一行锁等待队列。

在一个可能的实施方式中，该装置还可以包括：

第二确定模块，用于确定所述存储引擎中各数据行对应的更新事务请求的事务总数量；

发送模块，用于在所述事务总数量小于预设事务数量阈值时，将所述更新事务请求发送给所述存储引擎。

在一个可能的实施方式中，该装置还可以包括：

第三确定模块，用于确定所述第一行锁等待队列中各更新事务请求所对应的目标更新字段；

第四确定模块，用于确定具有相同目标更新字段的至少一个更新事务请求；

请求合并模块，用于根据所述至少一个更新事务请求中各更新事务请求的更新指令，合并所述至少一个更新事务请求，得到合并事务请求。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本发明实施例的数据库的事务请求处理装置在接收到针对数据库中第一数据行的更新事务请求时查询存储引擎，若存储引擎中存在与该第一数据行对应的第一热行更新等待队列，则将该更新事务请求写入该第一热行更新等待队列，若存储引擎中不存在与该第一数据行对应的第一热行更新等待队列，则确定该存储引擎中第一数据行对应的第一行锁等待队列的队列长度，当该第一行锁等待队列的队列长度超过预设长度阈值时，在存储引擎中为该第一数据行创建对应的第一热行更新等待队列，将上述更新事务请求写入该第一热行更新等待队列，并响应于预设触发信号将第一热行更新等待队列中的更新事务请求加入第一行锁等待队列，上述技术方案无需改动任何SQL语法，不需要用户侧做任何的热点行信息维护工作，在数据库的存储引擎层自动的发现热点数据行，并在存储引擎层对热点数据行的行锁等待队列入队操作进行限流，使得对同一热点数据行更新的多个事务能够得到更高的并发度，利用上更多的系统资源，大大提高了数据库系统在高并发情况下的事务吞吐率。

本发明实施例提供了一种计算机设备，该计算机设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的数据库的事务请求处理方法。

存储器可用于存储软件程序以及模块，处理器通过运行存储在存储器的软件程序以及模块，从而执行各种功能应用以及数据库的事务请求处理。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、功能所需的应用程序等；存储数据区可存储根据所述设备的使用所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器还可以包括存储器控制器，以提供处理器对存储器的访问。

本发明实施例所提供的方法实施例可以在计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图10是本发明实施例提供的运行一种数据库的事务请求处理方法的服务器的硬件结构框图，如图10所示，该服务器1000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，CPU)1010(处理器1010可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器xx30，一个或一个以上存储应用程序1023或数据1022的存储介质1020(例如一个或一个以上海量存储设备)。其中，存储器1030和存储介质1020可以是短暂存储或持久存储。存储在存储介质1020的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1010可以设置为与存储介质1020通信，在服务器1000上执行存储介质1020中的一系列指令操作。服务器1000还可以包括一个或一个以上电源xx60，一个或一个以上有线或无线网络接口xx50，一个或一个以上输入输出接口xx40，和/或，一个或一个以上操作系统xx21，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

输入输出接口1040可以用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器1000的通信供应商提供的无线网络。在一个实例中，输入输出接口1040包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，输入输出接口1040可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

本领域普通技术人员可以理解，图10所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器1000还可包括比图10中所示更多或者更少的组件，或者具有与图10所示不同的配置。

本发明的实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质可设置于计算机设备之中以保存用于实现一种数据库的事务请求处理方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的数据库的事务请求处理方法。

本发明的实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的方法。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是：上述本发明实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据库的事务请求处理方法，其特征在于，所述方法包括：

接收针对数据库中第一数据行的更新事务请求；

若存储引擎中存在所述第一数据行对应的第一热行更新等待队列，则将所述更新事务请求写入所述第一热行更新等待队列；

若所述存储引擎中不存在所述第一数据行对应的第一热行更新等待队列，则确定所述存储引擎中所述第一数据行对应的第一行锁等待队列的队列长度；

当所述第一行锁等待队列的队列长度超过预设长度阈值时，在所述存储引擎中为所述第一数据行创建对应的所述第一热行更新等待队列，将所述更新事务请求写入所述第一热行更新等待队列；

响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列。

2.根据权利要求1所述的数据库的事务请求处理方法，其特征在于，所述响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列包括：

监测所述第一行锁等待队列中是否有更新事务请求接收到所述第一数据行的行锁；

若监测到有，则产生第一预设触发信号，所述预设触发信号包括所述第一预设触发信号；

响应于所述第一预设触发信号，将所述第一热行更新等待队列中位于队首的首更新事务请求加入所述第一行锁等待队列。

3.根据权利要求1所述的数据库的事务请求处理方法，其特征在于，所述响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列包括：

监测所述第一热行更新等待队列中各更新事务请求的等待时长；

在监测到所述等待时长超过预设时长时，产生第二预设触发信号，所述预设触发信号包括所述第二预设触发信号；

响应于所述第二预设触发信号，将所述等待时长超过预设时长的目标更新事务请求加入所述第一行锁等待队列。

4.根据权利要求3所述的数据库的事务请求处理方法，其特征在于，在响应于所述第二预设触发信号，将所述等待时长超过预设时长的目标更新事务请求加入所述第一行锁等待队列之后，所述方法还包括：

对所述第一行锁等待队列进行死锁检测，确定所述第一行锁等待队列中产生死锁的死锁更新事务请求；

对所述死锁更新事务请求进行回滚操作。

5.根据权利要求1所述的数据库的事务请求处理方法，其特征在于，所述方法还包括：

在所述第一行锁等待队列的队列长度未超过所述预设长度阈值时，将所述更新事务请求写入所述第一行锁等待队列。

6.根据权利要求1所述的数据库的事务请求处理方法，其特征在于，在接收针对数据库中第一数据行的更新事务请求之后，所述方法还包括：

确定所述存储引擎中各数据行对应的更新事务请求的事务总数量；

在所述事务总数量小于预设事务数量阈值时，将所述更新事务请求发送给所述存储引擎。

7.根据权利要求1所述的数据库的事务请求处理方法，其特征在于，在响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列之后，所述方法还包括：

确定所述第一行锁等待队列中各更新事务请求所对应的目标更新字段；

确定具有相同目标更新字段的至少一个更新事务请求；

根据所述至少一个更新事务请求中各更新事务请求的更新指令，合并所述至少一个更新事务请求，得到合并事务请求。

8.一种数据库的事务请求处理装置，其特征在于，所述装置包括：

接收模块，用于接收针对数据库中第一数据行的更新事务请求；

第一写入模块，用于在存储引擎中存在所述第一数据行对应的第一热行更新等待队列时，将所述更新事务请求写入所述第一热行更新等待队列；

第一确定模块，用于在所述存储引擎中不存在所述第一数据行对应的第一热行更新等待队列时，确定所述存储引擎中所述第一数据行对应的第一行锁等待队列的队列长度；

创建模块，用于当所述第一行锁等待队列的队列长度超过预设长度阈值时，在所述存储引擎中为所述第一数据行创建对应的所述第一热行更新等待队列，将所述更新事务请求写入所述第一热行更新等待队列；

第二写入模块，用于响应于预设触发信号，将所述第一热行更新等待队列中的更新事务请求加入所述第一行锁等待队列。

9.一种计算机设备，其特征在于，包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如权利要求1～7中任一项所述的数据库的事务请求处理方法。

10.一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如权利要求1～7任一项所述的数据库的事务请求处理方法。

Images