(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202211158810.0 (22)申请日 2022.09.22 (71)申请人 贵州易鲸捷信息技 术有限公司 地址 550000 贵州省贵阳市贵阳综合保税 区都拉营综保路349号海关大楼8楼 801 (72)发明人 于伟　朴志桓　王建忠　张学　 武新　李建衡　 (74)专利代理 机构 四川言己律师事务所 51349 专利代理师 罗韬 (51)Int.Cl. G06F 9/50(2006.01) G06F 9/52(2006.01) G06F 16/2453(2019.01) G06F 16/27(2019.01)H04L 67/133(2022.01) (54)发明名称 分布式事务内存态 锁过程中的锁检查方法 (57)摘要 本发明公开了一种分布式事务内存态锁过 程中的锁检查方法， 属一种分布式数据库事务并 发控制技术， 该方法在事务启 动后， 在当前事务 的所属的数据库节点中， 对当前事务的数据增加 内存态锁， 再次读取到当前事务的数据时， 通过 加锁数据范围与加锁时间戳判断当前事务的数 据是否已增加过内存态锁； 如判断结果为是， 则 进一步校验当前事务的数据， 判断其是否有新的 版本； 如判断结果为否， 则内存态锁所关联的数 据一致， 正常读取当前事务的数据。 在事务启动 后的后续读取过程中， 同时进行内存态锁检查， 防止出现内存态锁丢失造成的数据不一致现象； 减少操作流 程环节以提升性能。 权利要求书1页 说明书6页 附图1页 CN 115357399 A 2022.11.18 CN 115357399 A 1.一种分布式事务内存态锁过程中的锁检查方法， 其特征在于所述的方法包括如下步 骤： 事务启动后， 在 当前事务的所属的数据库节点中， 对当前事务的数据增加内存态锁， 并 由当前分布式数据库中的协调者节点记录当前事务已增 加过内存态 锁的信息； 所述协调者节点记录的信息为当前事务的加锁数据范围与加锁时间戳； 事务启动后的执行过程中， 再次读取到当前事务的数据时， 通过加锁数据范围与加锁 时间戳判断当前事务的数据是否已增 加过内存态 锁； 如判断结果 为否， 则正常读取当前事务的数据； 如判断结果 为是， 则进一 步校验当前事务的数据， 判断其是否有新的版本； 如判断结果 为否， 则内存态 锁所关联的数据一 致， 正常读取当前事务的数据； 如判断结果 为是， 则当前事务的数据的内存态 锁丢失， 当前事务回滚。 2.根据权利要求1所述的分布式事务内存态锁过程中的锁检查方法， 其特征在于： 所述 方法在当前事务的所属的数据库 节点中增加内存态锁， 的下一执行步骤中判断当前事务的 数据是否已增 加过内存态 锁。 3.根据权利要求1所述的分布式事务内存态锁过程中的锁检查方法， 其特征在于： 所述 协调者节点同时或者先后记录多个事务已增加过内存态锁的信息， 并分别判断当前事务的 数据是否已增 加过内存态 锁， 且进一 步判断事务的内存态 锁是否丢失。 4.根据权利要求1至3任意一项所述的分布式事务内存态锁过程中的锁检查方法， 其特 征在于： 所述方法中判断当前事务的数据是否已增加过内存态锁， 以及进行校验当前事务 的数据判断其是否有新的版本， 均是在读取事务的 的阶段进行的。 5.根据权利要求1所述的分布式事务内存态锁过程中的锁检查方法， 其特征在于： 所述 方法在分布式数据库中的主节点中对当前事务增 加内存态 锁。 6.一种计算机可读介质， 其特征在于： 所述计算机可读的存储介质中存储有指令， 当计 算机执行所述指 令时， 使得计算机执行权利要求 1至5任意一项 所述的分布式事务内存态锁 过程中的锁检查方法。权　利　要　求　书 1/1 页 2 CN 115357399 A 2分布式事务内存态锁过 程中的锁检查方 法 技术领域 [0001]本发明涉及一种分布式数据库事务并发控制技术， 更具体的说， 本发明主要涉及 一种分布式事务内存态 锁过程中的锁检查方法。 背景技术 [0002]数据库事务通过两阶段封锁协议及其相关协议实现并发控制是常用的方法。 无论 单机数据库系统或是分布式数据库系统均可以采用该技术方法， 而加锁的实现方案对数据 库而言就尤为重要。 对于 分布式数据库而言， 基于内存态加锁 （易 失性锁） 或基于磁盘锁 （非 易失性锁） 相对性能影响较大。 因为分布式事务需要走存储多份副本， 而采用数据节点 leader的内存态加锁是保证性能的关键要素。 采用leader节点的内存态加锁提升了性能， 但是引入了新的问题需要解决。 那就是锁丢失的问题， 当一个分布式数据库的一个数据分 片leader因为网络异常或其他异常不可用时， 会选举新的leader， 而当采用易失性锁时， 事 务在运行过程中申请的锁就丢失了， 丢失后如果其他冲突的事务要访问锁要保护的数据， 并且发生了修改， 则会造成数据不一致。 针对前述的问题现有技术方案是采用事务提交前 锁检查的方案。 “提交前锁检查 ”顾名思义， 分布式事务的协调者 （TxnCoordinator） 节点会 记录该事务增加过的锁信息， 在事务提交时， 会通过RPC发送请求到数据节点， 对所有申请 过的锁信息进 行检查， 如果锁数据丢失则认为该事务不具备提交条件， 不 允许提交， 事务需 要回滚， 只有当所有的锁数据都存在时才允许提交。 [0003]而上述提交前锁检查主要存在两个缺陷， 一是在事务提交前才会进行锁检查， 这 样会带来检查的滞后性， 这是一种比较乐观的技术方案， 当锁不丢失时则锁检查不会出现 问题。 但如果一个长事务且在事务运行 的开始就出现了锁丢失， 则只能在提交时候报错并 进行事务的回滚， 在锁丢失后所做的工作其 实已经不需要了， 这是一种系统资源的浪费。 二 是提交前进行锁检查需要在协调者节点发起RPC请求到所有的数据节点进行一致性检查， 这会带来 一次额外的RPC， 会造成一定的性能影响。 发明内容 [0004]本发明的目的之一在于针对上述不足， 提供一种分布式事务内存态锁过程中的锁 检查方法， 以期望解决现有技术中事务内存态锁检查在提交前进行具有滞后性， 且会带来 额外的RPC， 对数据库性能造成形象等 技术问题。 [0005]为解决上述的技 术问题， 本发明采用以下技 术方案。 [0006]本发明所提供的一种分布式事务内存态锁过程中的锁检查方法， 所述的方法包括 如下步骤： 步骤A、 事务启动后， 在当前事务的所属的数据库节点中， 对当前事务的数据增加 内存态锁， 并由当前分布式数据库中的协调者节点记录当前事务已增加过内存态锁的信 息。 [0007]步骤B、 协调者节点记录的信息为当前事务的加锁数据范围与加锁时间戳； 事务启说　明　书 1/6 页 3 CN 115357399 A 3