死锁检测控制方法、装置、通信设备及计算机存储介质
技术领域
本发明实施例涉及但不限于通信领域,具体而言,涉及但不限于一种死锁检测控制方法、装置、通信设备及计算机可读存储介质。
背景技术
目前的死锁检测机制通过超时机制,等待死锁超时释放。在这种方式下,须设定合适的超时时间,若设定的超时时间过短,会导致事务失败率提高;若设定的超时时间过长,会导致死锁无法被及时发现,锁资源被长时间占用,相关数据无法被访问,进一步增加死锁冲突的可能性。由于超时机制的超时时间是预先统一设定的,即针对不同的事务设置统一的超时时间,而对不同事务而言,其所统一设定的超时时间不全为合适的超时时间,导致相对统一设定的超时时间过短的事务的误杀率较高,而相对统一设定的超时时间过长的事务的资源被长期占用,尤其在死锁概率大的场景下,会加剧资源的浪费,且有可能在释放后导致重复死锁。
发明内容
本发明实施例提供的死锁检测控制方法、装置、通信设备及计算机存储介质,主要解决的技术问题是:相关死锁检测机制通过超时机制,等待死锁超时释放,而超时时间是预先统一设定的,即针对不同的事务设置统一的超时时间,而设定的超时时间过短会导致事务失败率提高,设定的超时时间过长会导致资源浪费严重,进一步增加死锁冲突的可能性,从而无法兼顾资源和效率的问题。
为解决上述技术问题,本发明实施例提供一种死锁检测控制方法,包括:
确定当前执行的事务之执行时间大于等于事务对应的执行时间阈值时,控制针对事务进行死锁检测;
事务对应的执行时间阈值根据事务历史正常执行时间设置。
为解决上述技术问题,本发明实施例还提供一种死锁检测控制装置,包括:
事务执行模块,用于确定当前执行的事务之执行时间大于等于事务对应的执行时间阈值时,控制针对事务进行死锁检测;
事务对应的执行时间阈值根据事务历史正常执行时间设置。
为解决上述技术问题,本发明实施例还提供一种通信设备,包括处理器、存储器及通信总线;
通信总线用于实现处理器和存储器之间的连接通信;
处理器用于执行存储器中存储的一个或者多个程序,以实现如上所述死锁检测控制方法的步骤。
本发明实施例还提供一种计算机可读存储介质,其特征在于,计算机可读存储介质存储有一个或者多个程序,一个或者多个程序可被一个或多个处理器执行,以实现如上所述死锁检测控制方法的步骤。
本发明的有益效果是:
根据本发明实施例提供的死锁检测控制方法、装置、通信设备及计算机存储介质,通过确定当前执行的事务之执行时间大于等于事务对应的执行时间阈值时,控制针对事务进行死锁检测;事务对应的执行时间阈值根据事务历史正常执行时间设置,即根据事务历史正常执行时间的记录,会针对不同的事务设定对应合适的执行时间阈值,从而可实现针对不同的事务采用最佳的触发死锁检测的策略,保证能在合适的时间内发现死锁冲突,资源占用少,同时不会出现对正常事务的误操作,降低事务的失败率,达到兼顾资源和效率的目的。
本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明,且应当理解,至少部分有益效果从本发明说明书中的记载变的显而易见。
附图说明
图1为本发明实施例一的死锁检测控制方法流程图;
图2为本发明实施例一的单机检测升级为事务全局死锁检测流程示意图;
图3为本发明实施例一的死锁检测流程图;
图4为本发明实施例二的死锁检测控制装置的结构示意图;
图5为本发明实施例三的实现死锁检测的分布式数据库的整体架构图;
图6为本发明实施例三的针对SQL的死锁检测总体流程图;
图7为本发明实施例三的单机检测上升为SQL全局死锁检测流程示意图;
图8为本发明实施例四的通信设备的结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
实施例一:
为了解决相关死锁检测机制通过超时机制,等待死锁超时释放,而超时时间是预先统一设定的,即针对不同的事务设置统一的超时时间,而设定的超时时间过短会导致事务失败率提高,设定的超时时间过长会导致资源浪费严重,进一步增加死锁冲突的可能性,从而无法兼顾资源和效率的问题,本发明实施例提供一种死锁检测控制方法,请参见图1:
S101:确定当前执行的事务之执行时间大于等于事务对应的执行时间阈值;事务对应的执行时间阈值根据事务历史正常执行时间设置。
应当理解的是,在确定当前执行的事务之执行时间是否大于等于事务对应的执行时间阈值之前,包括获取事务历史正常执行时间的步骤,以及根据事务历史正常执行时间的置信区间的设置进行执行时间阈值的设置。
可选地,本实施例中对于事务历史正常执行时间的获取方式可以包括但不限于以下任意一种:
统计预设时间段内事务被正常执行时所花的执行时间,并从统计到的执行时间中选取时间值最大的作为该事务历史正常执行时间;
统计预设时间段内事务被正常执行时所花的执行时间,并从统计到的执行时间中随机选择一个作为该事务历史正常执行时间;
统计预设时间段内事务被正常执行时所花的执行时间,求出平均值,并将该平均值作为该事务历史正常执行时间。
可选的,本实施例中对于事务历史正常执行时间的置信区间的设置以及执行时间阈值的设置可以包括但不限于以下表1中所示例的事务历史正常执行时间的置信区间与执行时间的阈值的对应关系的任意一种:
表1
可以理解的是,获取到事务历史正常执行时间时,若事务历史正常执行时间的置信区间按照95%进行计算,则将该事务历史正常执行时间的95%乘以110%时的计算值为事务执行时间阈值。
应当理解的是,在确定当前执行的事务之执行时间是否大于等于事务对应的执行时间阈值之前,还包括确定当前是否获取到事务历史正常执行时间,若未获取到事务历史正常执行时间,可以通过加载通用的事务的执行时间阈值,确定当前执行的事务之执行时间是否大于等于预设的通用执行时间阈值,或者,选择等待,直到获取到事务历史正常执行时间时进行判断。
S102:控制针对事务进行死锁检测。
其中,控制针对事务进行死锁检测包括:死锁检测模块判断当前是否正在进行系统全局死锁检测,此时的系统全局死锁检测是指对系统中当前执行的各事务进行死锁检测,当确定当前在执行系统全局死锁检测时,死锁检测模块直接从系统全局死锁检测结果中获取事务对应的死锁检测结果;反之,若当前不在进行系统全局死锁检测,此时死锁检测模块针对事务执行死锁检测。应当理解的是,死锁检测模块也可不进行当前是否正在进行系统全局死锁检测的判断,直接进行针对事务执行死锁检测。
需要说明的是,针对事务执行死锁检测具体包括:
对事务进行单机死锁检测,单机死锁检测包括对执行事务所涉及的各数据节点进行锁等待检测;在单机死锁检测的检测结果为存在锁等待时,根据数据节点中产生锁等待的目标数据节点进行事务全局死锁检测。
其中,上述的根据数据节点中产生锁等待的目标数据节点进行事务全局死锁检测包括:确定目标数据节点当前对应的执行过程中的目标事务;对各目标事务进行单机死锁检测,汇总检测结果;根据汇总的检测结果确定存在全局死锁时,死锁检测结束;否则,获取目标事务中存在锁等待的目标数据节点进行事务全局死锁检测,直到检测到全局死锁或无新的目标数据节点。在一些示例中,由单机检测上升为事务全局死锁检测主要包括如图2所述的步骤:
S201:在事务相关的数据节点上查找锁信息。
事务执行模块在该事务涉及到的相关数据节点上查找锁相关信息。
S202:判断是否存在锁等待,若判断出存在锁等待,执行步骤S202;反之,执行步骤209。
S202:确定目标数据节点当前对应的执行过程中的目标事务。
存在长时间锁占用即锁等待,则查找目标数据节点上对应的事务。
S204:对目标事务进行单机检测。
根据目标事务的ID从计算节点上查找对应的分布式信息,即该目标事务涉及哪些分布式节点,接着在这些相关节点上分别查找各节点事务是否存在长时间锁占用以及锁占用的数据行上是否存在其它的锁等待。
S205:汇总检测结果,生成有向图。
将这些相关节点的信息汇总,进行全局有向环图的构建。
S206:判断是否存在全局锁,若判断出存在全局锁,执行步骤S208;否则,执行S207。
S207:判断是否存在新的目标数据节点。
如果存在新的目标数据节点,重复执行S204-S206,直至没有新的目标数据节点后者所有的节点遍历完毕。
S208:进行死锁处理。
全局锁确认存在时,事务执行模块向目标数据节点下发事务中止或者重启命令。
S209:无全局锁,不进行额外处理。
为了更好地理解本实施例的死锁检测控制方法,下面以事务超时触发死锁检测的示例并结合图3进行说明:
S301:执行事务,记录事务开始时间。
事务执行模块在事务执行之前,查找到由事务统计模块提供的对应事务的执行时间阈值。
S302:匹配该事务执行时间阈值,设置回调。
根据SQL执行开始时间和阈值,设置回调函数,回调函数会触发死锁检测。
S303:事务在回调触发之前是否执行完成。
若事务执行正常,在回调函数触发前完成,则不会出现全局死锁,执行S310;否则执行S304。
S304:触发回调函数,进行死锁检测。
当事务执行超过阈值,触发死锁检测后,执行S305。
S305:进行单机死锁检测。
S306:判断是否存在锁等待。若单机死锁检测该事务相关行上无锁等待,则也不会出现全局死锁,执行S310;反之,单机死锁检测升级为事务全局死锁检测,执行S307。
S307:进行事务全局死锁检测。
S308:判断是否存在全局死锁。
S309:进行死锁处理。
S310:无全局死锁,不需要额外处理。
本发明实施例提供的死锁检测控制方法,通过根据事务历史正常执行时间设置事务对应的执行时间阈值,确定当前执行的事务之执行时间大于等于事务对应的执行时间阈值时,控制针对事务进行死锁检测,可达到以最低的代价发现死锁冲突,资源占用最少,同时不会出现对正常事务的误操作,降低事务的失败率的有益效果。
实施例二:
根据本发明的实施例,提供了一种死锁检测控制装置,图4是本发明实施例的死锁检测控制装置的结构示意图,如图4所示,根据本发明实施例的死锁检测控制装置包括:事务统计模块S401,事务执行模块S402以及死锁检测模块S403,以下对本发明实施例的各个模块进行详细的说明。
事务统计模块S401,根据实现方式不同,可以分为集中式统计模块或分布式统计模块。用于统计预设时间段内事务被正常执行时所花的执行时间,并从统计到的执行时间中选取时间值最大的作为该事务历史正常执行时间,再将事务历史正常执行时间同步给事务执行模块。在一些实施例中,事务统计模块负责统计前一段时间事务执行的相关信息,包括该事务的最大执行时间和最大锁占用时间等,譬如统计按照95%置信区间进行,即将该事务的最大执行时间按95%计算后进行统计,接着事务统计模块定时将统计数据同步给事务执行模块。其中,事务统计模块定时将统计数据同步给事务执行模块的方式可以灵活设置,例如根据昼夜设置不同的同步间隔时间,可以在白天5分钟推送一次,而在夜间1小时推送一次;也可以根据数据库的繁忙程度自适应地进行修改同步间隔时间,例如当事务运行平稳的时,自动降低同步频率,而当事务运行指标变化较大的时候,自动加大同步频率。
事务执行模块S402,用于确定当前执行的事务之执行时间大于等于事务对应的执行时间阈值时,控制针对事务进行死锁检测,其中,事务对应的执行时间阈值根据事务历史正常执行时间设置。在一些实施例中,事务执行模块会缓存事务信息统计模块同步过来的数据,并在执行各条事务时,实时监控事务执行情况,并和统计数据作比较,如果通过比较后发现事务实际执行时间大于等于统计数据的阈值,则会触发死锁检测任务。而死锁检测任务根据配置的策略,对检测出来的事务进行kill或者重启,将死锁解除。其中,统计数据的阈值可以灵活设置,譬如默认超出10%,则事务实际执行时间在大于等于统计数据110%时,会触发死锁检测任务。
死锁检测模块S403,用于判断当前是否正在进行系统全局死锁检测,此时的系统全局死锁检测是指对系统中当前执行的各事务进行死锁检测,当确定当前在执行系统全局死锁检测时,死锁检测模块直接从系统全局死锁检测结果中获取事务对应的死锁检测结果;反之,若当前不在进行系统全局死锁检测,此时死锁检测模块针对事务执行死锁检测。在一些实施例中,死锁检测模块也可不进行当前是否正在进行系统全局死锁检测的判断,直接进行针对事务执行死锁检测。
实施例三:
本发明实施例以事务SQL为例,提供了一种用于实现死锁控制方法的分布式数据库,同时还提供一种死锁检测控制方法,但不仅限于适用于SQL,同时也适用与SQL作用相同的数据查询和程序设计语言,其分布式数据库的整体架构以及死锁检测控制方法的步骤一致,就不再一一赘述。
请参见图5,图5为该分布式数据库的整体架构图,架构图中各网元功能介绍如下:
分布式数据库,由多个数据库组构成,不同数据库组可以承载不同的用户数据。分布式数据库以数据服务的方式向应用提供数据库功能,通过无状态的计算节点对应用提供标准的事务接口。应用服务器S501将事务请求发送到计分布式数据库算节点S502上,接着分布式数据库计算节点S502将请求转发至分布式数据库数据节点S503执行。
请参见图6,该死锁检测控制方法主要包括以下步骤:
S601:SQL执行模块加载预设的通用执行时间阈值,SQL执行模块进行正常的事务执行。
S602:SQL统计模块统计SQL对应的执行时间阈值,并将统计数据同步给SQL执行模块。
本实施例中的SQL的执行时间阈值根据SQL历史正常执行时间的置信区间进行设置,其中,SQL历史正常执行时间为统计到的执行时间中的最大时间值,而SQL历史执行时间的置信区间选定为95%,对应的SQL的执行时间的阈值选定为110%,则SQL的执行时间阈值为SQL历史执行时间的95%乘以110%。
S603:SQL执行模块使用统计数据进行监控。
S604:当SQL的实际执行时间达到SQL对应的执行时间阈值时,控制针对SQL进行死锁检测。
S605:死锁检测模块进行死锁检测。
S606:是否存在全局死锁。
当检测出存在全局死锁时,执行S607;反之,执行S608。
S607:进行死锁处理。
S608:无全局死锁,不需要额外处理。
本实施例中的死锁检测模块进行死锁检测时包括:死锁检测模块判断当前是否正在进行系统全局死锁检测,此时的系统全局死锁检测是指对系统中当前执行的各SQL进行死锁检测,当确定当前在执行系统全局死锁检测时,死锁检测模块直接从系统全局死锁检测结果中获取SQL对应的死锁检测结果;反之,若当前不在进行系统全局死锁检测,此时死锁检测模块针对SQL执行死锁检测。其中,针对事务执行死锁检测具体包括:对SQL进行单机死锁检测,单机死锁检测包括对执行SQL所涉及的各数据节点进行锁等待检测;在单机死锁检测的检测结果为存在锁等待时,根据数据节点中产生锁等待的目标数据节点进行SQL全局死锁检测。为了便于理解,由单机检测上升为SQL全局死锁检测主要包括如图7所述的步骤:
S701:在SQL相关的数据节点上查找锁信息。
SQL执行模块在该SQL涉及到的相关数据节点上查找锁相关信息。
S702:是否存在锁等待。
若判断出存在锁等待,执行步骤S702;反之,执行步骤709。
S702:确定目标数据节点当前对应的执行过程中的目标事务。
存在长时间锁占用即锁等待,则查找目标数据节点上对应的事务。
S704:对目标事务进行单机检测。
根据目标事务的ID从计算节点上查找对应的分布式信息,即该目标事务涉及哪些分布式节点,接着在这些相关节点上分别查找各节点事务是否存在长时间锁占用以及锁占用的数据行上是否存在其它的锁等待。
S705:汇总检测结果,生成有向图。
将这些相关节点的信息汇总,进行全局有向环图的构建。
S706:判断是否存在全局锁,若判断出存在全局锁,执行步骤S708;否则,执行S707。
S707:是否存在新的目标数据节点。
如果存在新的目标数据节点,重复执行S704-S706,直至没有新的目标数据节点后者所有的节点遍历完毕。
S708:进行死锁处理。
全局锁确认存在时,SQL执行模块向目标数据节点下发事务中止或者重启命令。
S709:无全局锁,不进行额外处理。
实施例四:
本实施例提供了一种通信设备,参见图8所示,其包括处理器801、存储器802及通信总线803,其中:
通信总线803用于实现处理器801和存储器802之间的连接通信;
处理器803用于执行存储器802中存储的一个或者多个计算机程序,以实现上述实施例一和实施例三中的死锁检测控制方法中的步骤。
本实施例提供了一种计算机可读存储介质,该计算机可读存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、计算机程序模块或其他数据)的任何方法或技术中实施的易失性或非易失性、可移除或不可移除的介质。计算机可读存储介质包括但不限于RAM(Random Access Memory,随机存取存储器),ROM(Read-Only Memory,只读存储器),EEPROM(Electrically Erasable Programmable read only memory,带电可擦可编程只读存储器)、闪存或其他存储器技术、CD-ROM(Compact Disc Read-Only Memory,光盘只读存储器),数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。
本实施例中的计算机可读存储介质可用于存储一个或者多个计算机程序,其存储的一个或者多个计算机程序可被处理器执行,以实现上述实施例一和实施例三中的死锁检测控制方法中的步骤。
可见,本领域的技术人员应该明白,上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的计算机程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中,在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分;例如,一个物理组件可以具有多个功能,或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器,如中央处理器、数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。
此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、计算机程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。所以,本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。