CN114217978A - 一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质 - Google Patents

一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质 Download PDF

Info

Publication number
CN114217978A
CN114217978A CN202210155332.1A CN202210155332A CN114217978A CN 114217978 A CN114217978 A CN 114217978A CN 202210155332 A CN202210155332 A CN 202210155332A CN 114217978 A CN114217978 A CN 114217978A
Authority
CN
China
Prior art keywords
transaction
lock
data item
locking
changed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210155332.1A
Other languages
English (en)
Other versions
CN114217978B (zh
Inventor
黄强
郭子文
林逸
杨利华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Yunyou Interactive Network Technology Co ltd
Online Tuyoo Beijing Technology Co ltd
Original Assignee
Beijing Yunyou Interactive Network Technology Co ltd
Online Tuyoo Beijing Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Yunyou Interactive Network Technology Co ltd, Online Tuyoo Beijing Technology Co ltd filed Critical Beijing Yunyou Interactive Network Technology Co ltd
Priority to CN202210155332.1A priority Critical patent/CN114217978B/zh
Publication of CN114217978A publication Critical patent/CN114217978A/zh
Application granted granted Critical
Publication of CN114217978B publication Critical patent/CN114217978B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2462—Approximate or statistical queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory

Abstract

本申请提供一种基于乐观锁的数据库事务处理方法及系统、计算设备和计算机可读存储介质。在该方法中，通过将乐观锁与读写锁相结合的方式，不仅避免了悲观锁中的数据死锁问题，而且在发现事务重做后需要的锁发生变化时，使用了最小锁调整策略来最小化竞争，在保证不死锁的情况下，尽可能地少释放锁，降低了冲突的概率，因而避免了事务频繁重做带来的一系列问题。

Description

一种基于乐观锁的数据库事务处理方法、系统、计算设备和计 算机可读存储介质
技术领域
本申请涉及计算机技术领域，特别涉及一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质。
背景技术
数据库应用中为防止数据读写发生冲突，多使用悲观锁与乐观锁来对数据库中的事务进行处理。
悲观锁作为数据库锁的一种，其具有排他性：如果事务成功获取到悲观锁，在整个事务执行过程中，数据将一直处于锁定状态，直到事务执行结束或者事务异常回滚才会释放悲观锁；而如果事务获取悲观锁失败，则会一直等待形成死锁，直到超时。
为了避免死锁的情况，目前的数据库还支持乐观锁技术，乐观锁是一种并发类型的锁，其本身不对数据进行加锁通而是通过数据的版本号来实现锁的功能，不对数据进行加锁就意味着允许多个请求同时访问数据，提升了数据库的并发性能。乐观锁一个主要缺陷在于激烈冲突情况下，频繁的事务重做带来的无效负载增长、系统吞吐下降，甚至引发一些事务长时间无法执行成功导致的线程饥饿问题。因此有必要针对数据库中使用的读写控制方法做进一步的改进。
发明内容
有鉴于此，本申请实施例提供了一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质，以解决现有技术中存在的技术缺陷。
根据本申请实施例的第一方面，提供了一种基于乐观锁的数据库事务处理方法，包括：
S202：事务开始后，当操作序列首次访问到数据库表的数据项时，获取该数据项的版本号和快照；
S204：事务提交时，对所述事务涉及的数据项进行排序；按照所述排序的结果对所述数据项进行加锁，得到第一锁序；
S206：检查每个数据项的版本号，若所有版本号均未变更，将改动的数据项的版本号加1，完成事务提交，释放所有的锁；若数据项的版本号发生变更，则保持当前的锁，并进入到步骤S208，重做所述事务；
S208：重做所述事务时，按照最小锁调整策略完成第一锁序更新过程，再次进入到步骤S206。
根据本申请实施例的第二方面，提供了一种基于乐观锁的数据库事务处理系统，包括：
版本获取单元，用于当事务中的操作序列首次访问数据项时，获取该数据项的版本号和快照；
排序单元，用于事务提交时，对所述事务涉及的数据项进行排序；
加锁单元，用于按照所述排序单元的结果对所述数据项进行加锁得到第一锁序；
版本检查单元，用于检查每个所述数据项的版本号，将版本号的比较结果通知给事务执行单元；若所有版本号均未变更，将改动的数据项的版本号加1；
事务执行单元，若所有版本号均未变更时，完成事务提交，释放所有的锁；若数据项的版本号发生变更，则保持当前的锁，并通知事务重做单元；
事务重做单元，用于当数据项的版本号发生变更时，按照最小锁调整策略完成第一锁序更新过程，再次提交事务到版本号检查单元。
根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述一种基于乐观锁的数据库事务处理方法的步骤。
根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述一种基于乐观锁的数据库事务处理方法的步骤。
本申请实施例中，在提交事务时，对事务中未改动的数据加读锁，改动的加写锁，以最大化系统的并发能力；在结合乐观锁时，当数据的版本发生了变化需要重做时，通过不释放锁重做的方式，可保证绝大多数情况下第二次能完成事务，因而避免了过度冲突下无止境重做的问题，最小锁调整策略的使用则尽可能地少释放锁，降低了资源冲突概率。
附图说明
图1是本申请实施例提供的计算设备的结构框图；
图2是本申请实施例提供的基于乐观锁的数据库事务处理方法的流程图；
图3是本申请实施例提供的事务处理的一示意图；
图4是本申请实施例提供的事务处理的另一示意图；
图5是本申请实施例提供的最小锁调整策略的示意图；
图6是本申请实施例提供的最小锁调整策略的另一示意图；
图7是本申请实施例提供的事务处理的另一示意图；
图8是本申请实施例提供的最小锁调整策略的另一示意图；
图9是本申请实施例提供的事务处理的另一示意图；
图10是本申请实施例提供的最小锁调整策略的另一示意图；
图11是本申请实施例提供的基于乐观锁的数据库事务处理系统的结构示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“响应于确定”。
在本申请中，提供了一种基于乐观锁的数据库事务处理方法及系统、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。
图1示出了根据本申请一实施例的计算设备100的结构框图。该计算设备100的部件包括但不限于存储器110和处理器120。处理器120与存储器110通过总线130相连接，数据库150用于保存数据。
计算设备100还包括接入设备140，接入设备140使得计算设备100能够经由一个或多个网络160通信。这些网络的示例包括公用交换电话网（PSTN）、局域网（LAN）、广域网（WAN）、个域网（PAN）或诸如因特网的通信网络的组合。接入设备140可以包括有线或无线的任何类型的网络接口（例如，网络接口卡（NIC））中的一个或多个，诸如IEEE802.11无线局域网（WLAN）无线接口、全球微波互联接入（Wi-MAX）接口、以太网接口、通用串行总线（USB）接口、蜂窝网络接口、蓝牙接口、近场通信（NFC）接口，等等。
在本申请的一个实施例中，计算设备100的上述部件以及图1中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图1所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。
计算设备100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备（例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等）、移动电话（例如，智能手机）、可佩戴的计算设备（例如，智能手表、智能眼镜等）或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备100还可以是移动式或静止式的服务器。
其中，处理器120可以执行图2所示的基于乐观锁的数据库事务处理方法中的步骤。图2示出了根据本申请实施例中一种基于乐观锁的数据库事务处理方法的流程图，包括步骤S200至步骤208。
首先，对本说明书一个或多个实施例涉及的名词术语进行解释。
事务(Transaction)是访问或者更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言书写的用户程序的执行所引起，并用例如begin transaction和end transaction语句或函数调用来界定。事务由事务开始和事务结束之间执行的全体操作序列组成。
S202：事务开始后，当操作序列首次访问到数据库表的数据项时，获取该数据项的版本号和快照；
具体的，当事务开始后，操作序列开始执行，当事务中的序列首次访问数据项时，获取该数据项的版本号和快照；其中，该数据项为数据表中的行数据。
例如：
Key-value数据库中，通过GET <key>，返回value和版本号。
在该步骤中，不对数据项进行加锁操作。
S204：事务提交（commit）时，对事务涉及的数据项进行排序；按照排序的结果对数据项进行加锁，得到第一锁序。
具体的，当事务中的序列执行完毕，在事务提交时，对事务中所有涉及的数据项进行排序。
在一种可选的方式中，在排序前，获取事务中数据项所在的数据表ID，根据数据项的数据表ID和数据项的key，对数据项进行排序，得到排序结果。
在另一种可选的方式中，在排序时，仅针对事务中数据项的key进行排序，得到数据项的排序结果。
本领域技术人员应当知晓，上述排序方式只是示例并非穷举，排序算法也为本领域技术人员所熟知，在此不再赘述。
为了便于理解，在一个具体的实施例中，如图3所示，玩家A，C，E，F组成了一个队伍Team1，其中玩家A是队长。
在一个事务中，玩家A给队友C、E、F各发100个金币。该事务的示例序列如下所示，本领域技术人员应当知晓，该示例序列仅为示意性描述，并非事务的全部或详细过程，
-首先在队伍表中获得当前队伍Team1的信息，该队伍Team1的信息至少包括包含了Team1中玩家相关信息的数据项GTeam1以及所属的队伍表ID。
-获得队伍Team1中玩家的信息，玩家的信息至少包括代表玩家的key。
-根据各个玩家的key获取各自的金币信息，将玩家A的金币减去300，分别给玩家C、E、F的金币加上100。
在该事务提交时，对该事务涉及的数据项GTeam1、GA（GA表示玩家A的金币信息所在数据表中的具体数据项，下同）、GC、GE、GF按照上述的排序规则进行排序，得到排序后的数据项（GTeam1、GA、GE、GC、GF）。
在该事务中，由于无需对队伍的信息进行修改，因此对数据项GTeam1加上读锁；数据项GA、GC、GE、GF的数据均需要修改，因此对这些数据项加上写锁。最终得到第一锁序：LTeam1、LGA、LGE、LGC、LGF。
S206：检查每个数据项的版本号，若所有版本号均未变更，将改动的数据项的版本号加1，完成事务提交，释放所有的锁；若数据项的版本号发生变更，则保持当前的锁，并进入到步骤S208，重做该事务。
在该步骤中，在事务提交时，再次获取事务中数据项的版本号，并将本次获得的数据项的版本号与步骤S202中获得的数据项版本号进行比较。
具体的，以图3中的事务为例，当该事务提交时，再次获得数据项GTeam1、GA、GC、GE、GF的版本信息，若上述数据项的版本号均未发生变化，则将它们的版本号加1，完成事务的提交，释放所有的锁。
若其中任一个数据项的版本号发生了变化，则应该保持当前的锁，并进入到事务重做步骤S208，重做该事务。
在一种具体的实施方式中，如图4所示，在该事务中，在给数据项GTeam1加读锁之前，用户B加入了该队伍，导致GTeam1的版本号发生了变化，因此在事务提交时，检测到GTeam1的版本号发生了变化，需要重做该事务，进入到步骤S208。
S208：重做事务时，按照最小锁调整策略完成第一锁序更新过程，再次进入到步骤S206。
在该步骤中，在重做事务时，首先获取版本号发生变化的数据项。以图4中的事务为例，当检测到数据项GTeam1的版本号发生了变化时，获取当前版本的GTeam1的信息，此时GTeam1包括了玩家A、C、E、F和B。由于队伍中的玩家增加了，需要重做该事务以重新完成金币的分配。
在现有技术中，由于事务提交时队伍中玩家的数量发生了变化，导致游戏应用会让队长A重新点击分配功能，增加了玩家的操作次数，对玩家的体验不友好；亦或，现有的乐观锁机制并不会对数据进行加锁，仅在发现数据项的版本发生变化时，会进行事务的回滚，再次重新运行整个事务，直到运行成功，这样会导致在资源访问激烈冲突情况下，频繁重做带来的无效负载增长、系统吞吐下降，甚至引发一些事务长时间无法执行成功导致的问题。
而在本申请的实施例中，在事务重做时获取事务重做需要的锁，对当前持有的锁进行调整。在图4的实施例中，本方法根据GTeam1发生的变化-队伍中新加入了玩家B，重新获取事务执行需要加锁的数据项为GTeam1、GA、GE、GC、GF和新加入的玩家B的金币信息所在数据项GB。此时，该事务当前持有的锁为步骤S204形成的第一锁序：LTeam1、LGA、LGE、LGC、LGF。
由于事务重做所需要的锁比事务当前持有的锁多了一个对GB加锁的需要，此时根据最小锁调整策略，对事务持有的第一锁序进行更新。
进一步的，对事务重做需要的锁对应的数据项GTeam1、GA、GC、GE、GF、GB进行排序，排序的方式同步骤S204，在此不在赘述。
在一种可能的排序结果中，通过上述排序后的数据项得到的第二锁序为：LTeam1、LGA、LGE、LGB、LGC、LGF，如附图5所示。
其中，两个锁序的前3个顺序相同，重做需要的锁序在第一锁序的基础上在锁LGC前插入了锁LGB，因此为了从当前持有的锁序得到重做需要的锁序，且尽可能少的避免重做时高并发引起的资源冲突，在该实施方式中，最小锁调整策略应为，保持当前持有的锁序中的（LTeam1、LGA、LGE）不释放，释放当前持有的锁序中的LGC、LGF，再按照GB、GC、GF的顺序对数据项加锁，就可以得到第二锁序。
在另一种可能的排序结果中，得到的第二锁序为：LTeam1、LGA、LGE、LGC、LGF、LGB，如附图6所示。
经过对比，第二锁序比第一锁序多了一个锁LGB，但不影响第一锁序中已有锁的排列顺序，因此，在该实施方式中，最小锁调整策略为直接在第一锁序的基础上对数据项GB加上锁LGB，而无需释放现有的锁。
在上述实施例中，当事务提交时发现数据项的版本出现了变化需要重做事务时，并不是简单的释放所有已经加上的锁，而是先保持原来的锁不释放，进而考虑在不造成死锁的情况下，尽可能的少释放锁，释放的锁越少，资源冲突的概率也就越低。
在另外一种具体的实施方式中，如图7所示，在该事务中在给数据项GTeam1加读锁之前，用户C离开了该队伍，导致GTeam1的版本号发生了变化，因此在事务提交时，检测到GTeam1的版本号发生了变化，需要重做该事务。
在事务重做时获取事务重做需要的锁，对当前持有的锁进行调整。在图7的实施例中，根据GTeam1发生的变化-队伍中的玩家C离开了队伍，重新获取事务执行需要加锁的数据项为GTeam1、GA、GE、GF。此时，该事务当前持有的锁为步骤S204形成的锁序LTeam1、LGA、LGE、LGC、LGF，对比结果如图8所示。
由于事务重做所需要的锁比事务当前持有的锁少了一个LGC，此时根据最小锁调整策略，对事务持有的第一锁序进行更新。
其中，重做需要的锁序仅比当前持有的锁序少了一个锁LGC，因此此时的最小锁调整策略为直接释放锁LGC即可，无需重新加锁。
在该实施例中，由于当前持有的锁释放锁LGC后的锁序并不违反重新排序的结果，不会导致死锁，因此直接释放该锁即可完成事务的重做。
在另外一种具体的实施方式中，如图9所示，在该事务中当玩家A给其他玩家分配金币时，玩家C自行进行了金币的充值，因此在事务提交时，检测到玩家C的数据项版本号发生了变化，需要重做该事务。
在事务重做时获取事务重做需要的锁，对当前持有的锁进行调整。在图9的实施例中，根据数据项版本发生的变化-队伍中的玩家C自行充值100个金币，重新获取事务执行需要加锁的数据项仍为GTeam1、GA、GC、GE、GF。此时，该事务当前持有的锁序为LTeam1、LGA、LGE、LGC、LGF。
可见，在该实施例中，事务当前持有的锁与重做需要的锁序列之间并未发生变化，如图10所示。
但是，事务重做时需要获取新版本的玩家C的金币数据项内容，因此在重做时需要将锁LGC释放，事务提交时再次加锁。为了不违反锁序（LGC、LGF），在该实施例中会保持当前持有的锁序中的（LTeam1、LGA、LGE）不释放，同时释放当前持有的锁序中的LGC、LGF，事务提交时再按照LGC、LGF的顺序对相应数据项加锁，得到第二锁序LTeam1、LGA、LGE、LGC、LGF。
在该实施例中，虽然新旧锁序并未发生变化，但是为了读取玩家C的新版本数据，需要将相关的锁释放，同时需要考虑到再次加锁时不能违反锁序，否则将会导致死锁的问题，因此在该实施例中最小锁调整策略为将锁LGC、LGF释放，在事务重新提交时再按照LGC、LGF的顺序对数据项加锁。
本申请的上述多个实施例中，通过将乐观锁与读写锁相结合的方式，不仅避免了悲观锁中的数据死锁问题，在发现事务重做后需要的锁发生变化时，使用了最小锁调整策略来最小化竞争，在保证不死锁的情况下，尽可能地少释放锁，降低了冲突的概率，保证绝大多数情况下第二次能完成事务，因而避免了过度冲突下无止境重做的问题。其中，最小锁调整策略是在事务重做时，在尽可能少释放锁的情况下，完成事务持有锁序的前后转换，使之符合事务重做的需求。本领域技术人员应当知晓，上述多种具体实施方式仅是示例并非穷举，根据实际情况的需要，本申请多个实施例中的方法可以应用到任何数据库事务中，尤其是在key-value数据库中，将乐观锁的实现方式与key-value数据库按行加锁的方式有机的结合到一起，实现了对开发者透明的无死锁的锁机制，并且保证了即使发生激烈竞争时，也不会出现无休止的事务重做及线程饥饿问题。
与上述方法实施例相对应，本申请还提供了一种基于乐观锁的数据库事务处理系统实施例，图11示出了本申请一个实施例的一种基于乐观锁的数据库事务处理系统的结构示意图。如图11所示，该系统包括：
版本获取单元，用于当事务中的操作序列首次访问数据项时，获取该数据项的版本号和快照；
排序单元，用于事务提交时，对所述事务涉及的数据项进行排序；
加锁单元，用于按照所述排序单元的结果对所述数据项进行加锁得到第一锁序；
版本检查单元，用于检查每个所述数据项的版本号，将版本号的比较结果通知给事务执行单元；若所有版本号均未变更，将改动的数据项的版本号加1；
事务执行单元，若所有版本号均未变更时，完成事务提交，释放所有的锁；若数据项的版本号发生变更，则保持当前的锁，并通知事务重做单元；
事务重做单元，用于当数据项的版本号发生变更时，按照最小锁调整策略完成第一锁序更新过程，再次提交事务到版本号检查单元。
可选地，排序单元被配置为：
根据数据项的key或根据数据项的数据表ID和key对数据项进行排序。
可选地，加锁单元被配置为：
对需要改动的数据项加写锁，对不需要改动的数据项加读锁
可选地，事务重做单元被配置为：
根据版本号的变化获取重做事务需要的数据项对应的第二锁序，将第二锁序与第一锁序进行比较，按照最小锁调整策略对第一锁序进行更新。
可选的，事务获取单元被配置为：
获取key-value数据库事务。
上述为本实施例的一种基于乐观锁的数据库事务处理系统的示意性方案。需要说明的是，该基于乐观锁的数据库事务处理系统的技术方案与上述的基于乐观锁的数据库事务处理方法的技术方案属于同一构思，基于乐观锁的数据库事务处理系统的技术方案未详细描述的细节内容，均可以参见上述基于乐观锁的数据库事务处理方法的技术方案的描述。
本申请一实施例中还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述的基于乐观锁的数据库事务处理方法的步骤。
上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的基于乐观锁的数据库事务处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述基于乐观锁的数据库事务处理方法的技术方案的描述。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述基于乐观锁的数据库事务处理方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的基于乐观锁的数据库事务处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于乐观锁的数据库事务处理方法的技术方案的描述。
上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施例中，多任务处理和并行处理也是可以的或者可能是有利的。
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施例。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (9)

1.一种基于乐观锁的数据库事务处理方法，其特征在于，包括：
S202：事务开始后，当操作序列首次访问到数据库表的数据项时，获取该数据项的版本号和快照；
S204：事务提交时，对所述事务涉及的数据项进行排序；按照所述排序的结果对所述数据项进行加锁，得到第一锁序；
S206：检查每个数据项的版本号，若所有版本号均未变更，将改动的数据项的版本号加1，完成事务提交，释放所有的锁；若数据项的版本号发生变更，则保持当前的锁，并进入到步骤S208，重做所述事务；
S208：重做所述事务时，按照最小锁调整策略完成第一锁序更新过程，再次进入到步骤S206。
2.根据权利要求1所述的方法，其中，所述对该事务中的数据项进行排序还包括：
根据所述数据项的key或根据所述数据项的数据表ID和key对所述数据项进行排序。
3.根据权利要求1所述的方法，其中，重做所述事务时，按照最小锁调整策略完成第一锁序更新过程包括：
根据所述版本号的变化获取重做所述事务需要的数据项对应的第二锁序，将所述第二锁序与所述第一锁序进行比较，按照最小锁调整策略对第一锁序进行调整。
4.根据权利要求3所述的方法，其中，所述最小锁调整策略为：
在尽可能少释放锁的情况下，将所述事务持有的锁序由所述第一锁序调整为所述第二锁序。
5.根据权利要求1所述的方法，还包括，
对事务中需要改动的数据项加写锁，对不需要改动的数据项加读锁。
6.根据权利要求1所述的方法，还包括：
所述数据库为key-value数据库。
7.一种基于乐观锁的数据库事务处理系统，其特征在于，包括：
版本获取单元，用于当事务中的操作序列首次访问数据项时，获取该数据项的版本号和快照；
排序单元，用于事务提交时，对所述事务涉及的数据项进行排序；
加锁单元，用于按照所述排序单元的结果对所述数据项进行加锁得到第一锁序；
版本检查单元，用于再次获取每个所述数据项的版本号，将版本号的比较结果通知给事务执行单元；若所有版本号均未变更，将改动的数据项的版本号加1；
事务执行单元，若所有版本号均未变更时，完成事务提交，释放所有的锁；若数据项的版本号发生变更，则保持当前的锁，并通知事务重做单元；
事务重做单元，用于当数据项的版本号发生变更时，按照最小锁调整策略完成第一锁序更新过程，再次提交事务到版本号检查单元。
8.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述指令时实现权利要求1-6任意一项所述方法的步骤。
9.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该指令被处理器执行时实现权利要求1-6任意一项所述方法的步骤。
CN202210155332.1A 2022-02-21 2022-02-21 一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质 Active CN114217978B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210155332.1A CN114217978B (zh) 2022-02-21 2022-02-21 一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210155332.1A CN114217978B (zh) 2022-02-21 2022-02-21 一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN114217978A true CN114217978A (zh) 2022-03-22
CN114217978B CN114217978B (zh) 2022-05-17

Family

ID=80708991

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210155332.1A Active CN114217978B (zh) 2022-02-21 2022-02-21 一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN114217978B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115629822A (zh) * 2022-11-09 2023-01-20 深圳计算科学研究院 一种基于多核处理器的并发事务处理方法及其系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130325827A1 (en) * 2012-05-31 2013-12-05 Red Hat Inc. Incremental optimistic locking of data distributed on multiple nodes to avoid transaction deadlock
CN105955801A (zh) * 2015-12-21 2016-09-21 上海交通大学 一种基于rdma和htm的分布式乐观并发控制方法
CN110502525A (zh) * 2019-08-16 2019-11-26 华东师范大学 一种混合工作负载的乐观并发控制方法
CN111259071A (zh) * 2020-01-04 2020-06-09 浙江科技学院 一种分布式数据库系统中的并发访问控制方法
CN111797107A (zh) * 2020-07-08 2020-10-20 贵州易鲸捷信息技术有限公司 混合乐观锁和悲观锁的数据库事务并发控制方法
WO2021114628A1 (zh) * 2020-05-28 2021-06-17 平安科技（深圳）有限公司 分布式事务的交易处理方法及相关设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130325827A1 (en) * 2012-05-31 2013-12-05 Red Hat Inc. Incremental optimistic locking of data distributed on multiple nodes to avoid transaction deadlock
CN105955801A (zh) * 2015-12-21 2016-09-21 上海交通大学 一种基于rdma和htm的分布式乐观并发控制方法
CN110502525A (zh) * 2019-08-16 2019-11-26 华东师范大学 一种混合工作负载的乐观并发控制方法
CN111259071A (zh) * 2020-01-04 2020-06-09 浙江科技学院 一种分布式数据库系统中的并发访问控制方法
WO2021114628A1 (zh) * 2020-05-28 2021-06-17 平安科技（深圳）有限公司 分布式事务的交易处理方法及相关设备
CN111797107A (zh) * 2020-07-08 2020-10-20 贵州易鲸捷信息技术有限公司 混合乐观锁和悲观锁的数据库事务并发控制方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115629822A (zh) * 2022-11-09 2023-01-20 深圳计算科学研究院 一种基于多核处理器的并发事务处理方法及其系统

Also Published As

Publication number Publication date
CN114217978B (zh) 2022-05-17

Similar Documents

Publication Publication Date Title
CN107977376B (zh) 分布式数据库系统及事务处理方法
US8671085B2 (en) Consistent database recovery across constituent segments
US11386065B2 (en) Database concurrency control through hash-bucket latching
US11321299B2 (en) Scalable conflict detection in transaction management
EP4254183A1 (en) Transaction processing method and apparatus, computer device, and storage medium
US7536517B2 (en) Direct-update software transactional memory
Lindström et al. IBM solidDB: In-Memory Database Optimized for Extreme Speed and Availability.
US9928265B2 (en) Utilizing shared numeric locks
US11436212B2 (en) Concurrent transaction processing in a database system
CN113297320A (zh) 分布式数据库系统及数据处理方法
CN114217978B (zh) 一种基于乐观锁的数据库事务处理方法、系统、计算设备和计算机可读存储介质
US11243820B1 (en) Distributed deadlock detection and resolution in distributed databases
EP3824397B1 (en) Version-based table locking
CN107533474B (zh) 一种事务处理方法及装置
Chen et al. PEEP: A parallel execution engine for permissioned blockchain systems
US10650021B2 (en) Managing data operations in an integrated database system
CN110955719A (zh) 一种数据存取处理设备、系统和方法
US20130042248A1 (en) System and method for supporting parallel threads in a multiprocessor environment
CN110377614B (zh) 一种分布式环境下的订单处理锁系统
US20230068439A1 (en) Using view layer in database system for zero downtime upgrade
JP2016045698A (ja) 更新処理プログラム、装置、及び方法
CN111240891A (zh) 基于数据库多表间数据一致性的数据恢复方法及装置
CN117093408B (zh) 数据处理方法以及装置
CN113296895B (zh) 事务处理系统、事务处理方法及装置
WO2013189011A1 (zh) 交易处理的方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant