一种死锁检测方法、节点及系统的制作方法
【专利摘要】本发明公开了一种死锁检测方法、节点及系统，涉及数据库领域，可以减小节点之间用于死锁检测的通信开销，并均衡死锁检测造成的负荷。本发明的方法包括：第一计算节点根据运行在第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测；当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。本发明的实施例主要用于数据库系统的死锁检测过程中。
【专利说明】一种死锁检测方法、节点及系统
【技术领域】
[0001]本发明涉及数据库领域，尤其涉及一种死锁检测方法、节点及系统。
【背景技术】
[0002]在数据库系统中，多个事务并发执行时，系统为各个事务分配资源时，会有一定几率导致两个或两个以上的事务之间出现互相等待而停滞不前的现象，这就是死锁。发生死锁会导致系统效率低下，甚至造成系统故障。
[0003]为了解决死锁现象，数据库系统通常会采取必要的死锁检测和处理方法。无论是集中式数据系统或是分级式数据系统，多个计算节点可以以一个控制节点为中心，由控制节点负责其管理下的多个计算节点的死锁检测。具体的死锁检测方法为:每个计算节点定时将本地多个事务所访问的资源之间的依赖关系发送给控制节点，这样控制节点便可以获知其管理下每个计算节点的每个事务所访问的资源之间的依赖关系，从而可以根据这些依赖关系构建资源等待图，已判断运行在各计算节点上的多个事务之间是否存在相互等待的现象，即是否存在死锁。其中，各计算节点向控制节点发送本地多个事务所访问的资源之间的依赖关系的时间间隔越小，已发生的死锁被检测出来的速度越快，但是需要更多的通信开销。
[0004]在实现上述死锁检测的过程中，由于每个计算节点都要定期向控制节点发送本地多个事务所访问的资源之间的依赖关系，控制节点需要维护每个计算节点的每个事务所访问的资源之间的依赖关系并进行资源等待图的构建，这样不仅计算节点与控制节点之间的通信开销较大，控制节点进行死锁检测的负荷也过高。尤其对于系统规模庞大、业务节点数量较多的数据库系统，控制节点通常不能再执行业务操作，而不得不专职承担死锁检测的工作。
【发明内容】
[0005]本发明的实施例提供一种死锁检测方法、节点及系统，可以减小节点之间用于死锁检测的通信开销，并均衡死锁检测造成的负荷。
[0006]为达到上述目的，本发明的第一方面提供一种死锁检测方法，包括:
[0007]第一计算节点根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测；
[0008]当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0009]结合本发明的第一方面，在第一种可能的实现方式中，在所述根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测之前，该方法还包括:
[0010]启动第一时钟，对所述多个事务进行第一次超时检测；[0011]当第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，执行所述根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测的步骤。
[0012]结合本发明的第一方面的第一种可能的实现方式，在第二种可能的实现方式中，在向控制节点发送全局死锁检测请求之后，该方法还包括:
[0013]当所述全局死锁检测结果表明所述多个计算节点之间存在死锁时，接收所述控制节点发送的第二次超时检测指示消息；
[0014]启动第二时钟，对所述多个事务进行第二次超时检测；
[0015]若第二次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待超时，则终止该等待超时的事务；
[0016]若第二次超时检测的结果表明所述第一计算节点上运行的多个事务在等待超时前已被执行，则认定为系统内不存在死锁。
[0017]结合本发明的第一方面的第二种可能的实现方式，在第三种可能的实现方式中，所述控制节点发送的第二次超时检测指示消息中包含所述第二时钟的配置值；其中，所述第二时钟的配置值由所述控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定。
[0018]结合本发明的第一方面，在第四种可能的实现方式中，在向控制节点发送全局死锁检测请求之后，该方法还包括:
[0019]接收所述控制节点反馈的全局死锁检测结果。
[0020]本发明的第二方面，提供一种死锁检测方法，包括:
[0021]控制节点接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明所述第一计算节点上运行的多个事务之间不存在死锁时进行发送；
[0022]根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0023]结合本发明的第二方面，在第一种可能的实现方式中，在根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，该方法还包括:
[0024]当全局死锁检测结果表明所述多个计算节点之间存在死锁时，向所述第一计算节点发送的第二次超时检测指示消息；
[0025]其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对多个事务进行第二次超时检测。
[0026]结合本发明的第二方面的第一种可能的实现方式，在第二种可能的实现方式中，在向所述第一计算节点发送的第二次超时检测指示消息之前，该方法还包括:
[0027]根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值包含在所述第二次超时检测指示消息中发送给所述计算节点。
[0028]结合本发明的第二方面，在第三种可能的实现方式中，在根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，该方法还包括:
[0029]向所述第一计算节点反馈全局死锁检测结果。
[0030]本发明的第三方面，提供一种计算节点，可以作为第一计算节点，该节点包括:
[0031]本地检测单元，用于根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测；
[0032]请求发送单元，用于当所述本地检测单元执行的本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0033]结合本发明的第三方面，在第一种可能的实现方式中，还包括:
[0034]一次超时单元，用于在所述本地检测单元根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测之前，启动第一时钟，对所述第一计算节点上运行的多个事务进行第一次超时检测；
[0035]所述本地检测单元，还用于当所述一次超时单元执行的第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，执行所述根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测。
[0036]结合本发明的第三方面的第一种可能的实现方式，在第二种可能的实现方式中，该节点还包括:
[0037]指示接收单元，用于在所述请求发送单元向控制节点发送全局死锁检测请求之后，当所述全局死锁检测结果表明所述多个计算节点之间存在死锁时，接收所述控制节点发送的第二次超时检测指示消息；
[0038]二次超时单元，用于启动第二时钟，对多个事务进行第二次超时检测；若第二次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待超时，则终止该等待超时的事务；若第二次超时检测的结果表明多个事务在等待超时前已被执行，则认定为系统内不存在死锁。
[0039]结合本发明的第三方面的第二种可能的实现方式，在第三种可能的实现方式中，所述控制节点发送的第二次超时检测指示消息中包含所述第二时钟的配置值；其中，所述第二时钟的配置值由所述控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定。
[0040]结合本发明的第三方面，在第四种可能的实现方式中，该计算节点还包括:
[0041]结果接收单元，用于在所述请求发送单元向控制节点发送全局死锁检测请求之后，接收所述控制节点反馈的全局死锁检测结果。
[0042]本发明的第四方面，提供一种控制节点，包括:
[0043]请求接收单元,用于接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明所述第一计算节点上运行的多个事务之间不存在死锁时进行发送；
[0044]全局检测单元，用于在所述请求接收单元接收到所述全局死锁检测请求后，根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0045]结合本发明的第四方面，在第一种可能的实现方式中，该节点还包括:[0046]结果指示单元，用于在所述全局检测单元根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，当全局死锁检测结果表明所述多个计算节点之间存在死锁时，向所述第一计算节点发送的第二次超时检测指示消息；
[0047]其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对多个事务进行第二次超时检测。
[0048]结合本发明的第四方面的第一种可能的实现方式，在第二种可能的实现方式中，所述结果指示单元，还用于在向所述第一计算节点发送的第二次超时检测指示消息之前，根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值包含在所述第二次超时检测指示消息中发送给所述第一计算节点。
[0049]结合本发明的第四方面，在第三种可能的实现方式中，该节点还包括:
[0050]结果发送单元，用于在所述全局检测单元根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，向所述第一计算节点反馈全局死锁检测结果。
[0051]本发明的第五方面，提供一种死锁检测系统，包括:控制节点以及多个计算节点，其中，
[0052]所述计算节点，用于根据运行在所述计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测；当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求；
[0053]所述控制节点，用于接收所述计算节点发送的全局死锁检测请求；根据所述多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0054]本发明实施例提供的死锁检测方法、节点及系统，通过计算节点进行计算节点上运行的多个事务之间的本地死锁检测，当本地死锁检测的结果表明本地多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
【专利附图】
【附图说明】
[0055]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0056]图1为本发明一实施例中的一种死锁检测方法流程图；
[0057]图2为本发明另一实施例中的一种死锁检测方法流程图；
[0058]图3为本发明另一实施例中的一种死锁检测方法流程图；
[0059]图4为三种常见的资源等待图的示意图；
[0060]图5为本发明另一实施例中的一种计算节点的组成示意图；
[0061]图6为本发明另一实施例中的另一种计算节点的组成示意图；
[0062]图7为本发明另一实施例中的一种控制节点的组成示意图；[0063]图8为本发明另一实施例中的另一种控制节点的组成示意图；
[0064]图9为本发明另一实施例中的一种计算节点的组成示意图；
[0065]图10为本发明另一实施例中的一种控制节点的组成示意图；
[0066]图11为本发明另一实施例中的一种具备死锁检测的数据库系统的组成示意图；
[0067]图12为本发明的一种数据库系统架构示意图。
【具体实施方式】
[0068]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0069]首先，以图12为例对本发明的应用场景进行介绍。在数据库系统中可以包含多个控制节点，并且每个控制节点下可以控制和管理多个计算节点，图12仅画出了其中一部分作为示例，控制节点A负责计算节点1、计算节点2和计算节点3的控制和管理，在控制节点A上记录有计算节点1、2和3所访问资源的信息。这样，每个计算节点分别维护有运行在自身节点上的事件所访问的资源之间的依赖关系，控制节点A维护有计算节点1、2和3所访问的资源之间的依赖关系。计算节点I可以根据运行在计算节点I上的多个事务所访问资源之间的依赖关系进行本地死锁检测。控制节点A可以根据计算节点1、2和3所访问的资源之间的依赖关系进行全局死锁检测。值得说明的是，本地死锁检测是指对一个计算节点而言，检测运行在该计算节点上的多个事务之间是否存在死锁。相应的，全局死锁检测则是指对于控制多个计算节点的控制节点而言，检测多个计算节点之间是否存在死锁。
[0070]本发明实施例提供一种死锁检测方法，如图1所示，该方法包括:
[0071]101、第一计算节点根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测。
[0072]其中，第一计算节点可以采用常规的事务死锁检测流程，该死锁检测无需发生节点间通信，不会带来节点间的通信开销。在每个事务的等待开始时，启动第一时钟，对所述第一计算节点上运行的多个事务进行第一次超时检测；当第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，则执行所述本地死锁检测。
[0073]102、当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0074]在本实施例中，计算节点本地的事务之间不存在死锁，并不代表多个计算节点之间不存在死锁，因此在本地死锁检测的结果表明本地事务之间不存在死锁之后，还需要出发第二阶段的全局死锁检测，以排查系统中是否存在死锁。
[0075]其中，一个控制节点可以管理两个或两个以上的计算节点，由于计算节点处理业务的需要，在访问资源时均在控制节点上进行注册以获得所访问资源的锁，在所需访问的资源空闲时，计算节点可以依据已获得的锁访问其对应的资源。也就是说，在控制节点上维护有其管理下每个计算节点所持有锁的信息，及记录有其管理下的每个计算节点所访问的资源之间的依赖关系。控制节点进行全局死锁检测时，可以不用每个计算节点提供事务所访问资源之间的依赖关系，而是采用已存储的每个计算节点所访问的资源之间的依赖关系进行全局死锁检测。
[0076]本发明实施例提供的死锁检测方法，通过计算节点进行运行在计算节点上的多个事务之间的本地死锁检测，当本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0077]本发明另一实施例提供一种死锁检测方法，如图2所示，包括:
[0078]201、控制节点接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明所述第一计算节点上运行的多个事务之间不存在死锁时进行发送。
[0079]202、根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0080]需要说明的是，本发明实施例中各步骤的具体描述可以参考图1对应实施例中的对应内容，本实施例这里不再重复赘述。
[0081]本发明实施例提供的死锁检测方法，通过计算节点进行计算节点上运行的多个事务之间的本地死锁检测，当本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0082]本发明另一实施例提供一种死锁检测方法，如图3所示，包括:
[0083]301、第一计算节点启动第一时钟，对运行在第一计算节点上的多个事务进行第一次超时检测；若第一时钟超时，则执行302 ;若第一时钟未超时，则事务正常运行。
[0084]其中，在每个事务开始等待时，启动该事务对应的第一时钟，当第一时钟超时表明该事务等待超时，若第一时钟未超时，则事务在可容忍的时间内得到了处理，属于正常运行。采用时钟的方式触发死锁检测，为本领域的常规手段，本实施例这里不再详细赘述。
[0085]302、第一计算节点根据运行在第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测；若本地不存在死锁，则执行303 ;若本地存在死锁，则执行步骤307。
[0086]其中，本地死锁检测可以通过构建资源等待图来实现。具体的，以事务为节点，一个事务等待其他事务持有的资源时，在两个节点之间用有向线连接，这样由两个或两个以上节点及若干有向线构成一个资源等待图。如果资源等待图中存在一个首位相连的环路，且没有多余的末端，则认为发生死锁。例如，如图4所示，给出了三种典型的资源等待图的示例，其中图4 (a)中认定为发生了死锁，图4 (b)和图4 (C)中认定为不存在死锁。
[0087]303、第一计算节点向控制节点发送全局死锁检测请求。
[0088]其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明所述运行在所述第一计算节点上运行的多个事务之间不存在死锁时进行发送，用于指示所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。[0089]304、控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测；若存在全局死锁，则执行305 ;若不存在全局死锁，则事务正常运行。
[0090]其中，全局死锁检测与本地死锁检测的方法类似，可以通过构建资源等待图的方式实现，不同的是，在这里通过计算节点所访问的资源之间的依赖关系构建的资源等待图中，包含两个或两个以上的节点以及连接节点的若干有向线。全局死锁检测时以节点为粒度，而不是以事务为粒度，因此可以复用控制节点上已有的计算节点所持有锁的信息，即计算节点所访问的资源之间的依赖关系完成，而不需要计算节点上传多个事务的资源等待信肩、O
[0091]可选的，在一种可能的实现方式中，当控制节点确定存在全局死锁时，可以直接将全局死锁检测结果反馈给计算节点。当存在全局死锁时，该全局死锁检测结果可以触发计算节点将发生死锁的事务进行回滚，即释放该事务所需访问的资源，放弃执行该事务。当然，基于业务需要或用户触发，可以重新加载已放弃的事务，从而为该事务重新分配所需访问的资源。
[0092]可以理解的是，由于控制节点根据计算节点所访问的资源之间的依赖情况构建资源等待图时，只能以节点为粒度，确定是否存在相互等待的情况。然而，当并发事务间存在死锁时，以节点为单位构造的资源等待图必然会体现出全局存在死锁；当以节点为单位构造的资源等待图体现出全局存在死锁时，并不能确定事务之间存在死锁。因此，在另一种实现方式中，为了避免全局死锁检测造成的死锁误判，本发明的方法还可以包括以下步骤:
[0093]305、控制节点向所述第一计算节点发送的第二次超时检测指示消息。
[0094]其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对多个事务进行第二次超时检测。步骤301中第一次超时检测的时钟与这里的第二次超时检测的时钟可以单独设置，从而解决了触发死锁检测的事务等待资源超时时钟(即第一时钟)对数据库集群的负载过于敏感的问题。通过二次设置超时时钟，降低了死锁误报情况的发生。
[0095]进一步可选的，在控制节点向所述第一计算节点发送的第二次超时检测指示消息之前，该方法还可以包括:控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值可以包含在所述第二次超时检测指示消息中发送给所述计算节点。其中，当节点之间消息传输时延过长或者事务处理时间较长时，应同时增大第二次超时时钟来避免对不存在死锁的事务进行回滚。
[0096]例如，第二次超时时钟的配置方法可以为:每10分钟各个计算节点采集10个事务的处理延迟，并计算出处理延迟ti。全局锁表所在的节点(即控制节点)每10分钟采集各个计算节点的消息传输延迟，并计算出传输延迟t2。控制节点的全局死锁检测部件设置第二次超期检测时钟t，并且根据计算得出的和t2进行更新，t的计算公式为t=ti+aXt2。其中，a是事务消息传输影响因子，用户可以根据实际需要进行设置，例如当网络延迟较高处理负荷较大时，可以将a值调高，以避免误报死锁。
[0097]306、第一计算节点启动第二时钟，对多个事务进行第二次超时检测；若第二时钟超时，则执行步骤307 ;若第二时钟未超时，则事务正常运行。
[0098]307、第一计算节点终止造成死锁的事务。[0099]在本实施例中，若步骤302计算节点进行本地死锁检测发现存在死锁时，为了解决死锁问题，可以终止造成死锁的事务，释放该事务所访问的资源，从而解除死锁。当然，也可以根据用户需要或业务需要重新加载该事务，也就是事务回滚，为该事务分配新的资源。
[0100]值得说明的是，本方法可以普遍适用于具备全局元数据管理节点并且该全局节点管理各个执行节点的资源持有和请求信息的各类分布式系统，包括但不限于:共享磁盘类集群数据库系统、大量平行处理(massively parallel processing,MPP)数据库系统、分布式文件系统、点对点(point to point, P2P)系统等需要提供死锁检测机制的系统。上述计算节点可以作为系统中的执行节点、业务节点或计算节点，上述控制节点可以作为系统中的全局节点、中心节点或管理节点等。
[0101]本实施例提供的死锁检测方法，通过计算节点进行运行在计算节点上的多个事务之间的本地死锁检测，当本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0102]并且，通过第二次超时检测和动态设置二次超时时钟，不仅降低了死锁误报情况的发生，还可以根据数据库集群环境中时延和负载情况合理调整死锁检测的敏感度。
[0103]本发明另一实施例提供一种计算节点，可以作为第一计算节点，如图5所示，该计算节点包括:
[0104]本地检测单元51，用于根据多个事务所访问的资源之间的依赖关系，进行运行在所述第一计算节点上的多个事务之间的本地死锁检测；
[0105]请求发送单元52，用于当所述本地检测单元51执行的本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0106]进一步可选的，该计算节点还包括:
[0107]结果接收单元53，用于在所述请求发送单元52向控制节点发送全局死锁检测请求之后，接收所述控制节点反馈的全局死锁检测结果。
[0108]进一步的,该计算节点还包括:
[0109]一次超时单元54，用于在所述本地检测单元51根据所述第一计算节点上运行的多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测之前，启动第一时钟，对所述第一计算节点上运行的多个事务进行第一次超时检测；
[0110]所述本地检测单元51，还用于当所述一次超时单元54执行的第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，执行所述根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测。
[0111]进一步可选的，如图6所示，该计算节点还可以包括:
[0112]指示接收单元55，用于在所述请求发送单元52向控制节点发送全局死锁检测请求之后，当所述全局死锁检测结果表明所述多个计算节点之间存在死锁时，接收所述控制节点发送的第二次超时检测指示消息；
[0113]二次超时单元56，用于启动第二时钟，对多个事务进行第二次超时检测；若第二次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待超时，则终止该等待超时的事务；若第二次超时检测的结果表明所述第一计算节点上运行的多个事务在等待超时前已被执行，则认定为系统内不存在死锁。
[0114]进一步的，所述控制节点发送的第二次超时检测指示消息中包含所述第二时钟的配置值；其中，所述第二时钟的配置值由所述控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定。
[0115]本发明实施例提供的计算节点，通过计算节点进行运行在计算节点上的多个事务之间的本地死锁检测，当本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0116]本发明另一实施例还提供一种控制节点，如图7所示，该节点包括:
[0117]请求接收单元61,用于接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明所述第一计算节点上运行的多个事务之间不存在死锁时进行发送；
[0118]全局检测单元62，用于在所述请求接收单元61接收到所述全局死锁检测请求后，根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0119]进一步可选的，该控制节点还包括:
[0120]结果发送单元63，用于在所述全局检测单元62根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，向所述计算节点反馈全局死锁检测结果。
[0121]进一步的可选的，如图8所示，该控制节点还可以包括:
[0122]结果指示单元64，用于在所述全局检测单元62根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，当全局死锁检测结果表明所述多个计算节点之间存在死锁时，向所述计算节点发送的第二次超时检测指示消息；
[0123]其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对多个事务进行第二次超时检测。
[0124]进一步的,所述结果指示单元64,还用于在向所述第一计算节点发送的第二次超时检测指示消息之前，根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值包含在所述第二次超时检测指示消息中发送给所述计算节点。
[0125]本发明实施例提供的控制节点，当计算节点本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0126]本申请另一实施例还提供一种计算节点,可以作为第一计算节点,如图9所示,该节点包括:
[0127]存储器71，用于存储运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系；
[0128]处理器72，用于根据所述存储器71中存储的所述多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测；
[0129]发射器73，用于当处理器进行的本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0130]进一步的,该计算节点还包括:
[0131]接收器74，用于在所述发射器73向控制节点发送全局死锁检测请求之后，接收所述控制节点反馈的全局死锁检测结果。
[0132]进一步的，所述处理器72还用于:
[0133]在根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测之前，启动第一时钟，对所述第一计算节点上运行的多个事务进行第一次超时检测；
[0134]当第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，执行所述根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测。
[0135]进一步的，所述接收器74，还用于在所述发射器73向控制节点发送全局死锁检测请求之后，当所述全局死锁检测结果表明所述多个计算节点之间存在死锁时，接收所述控制节点发送的第二次超时检测指示消息；
[0136]所述处理器72，还用于:启动第二时钟，对多个事务进行第二次超时检测；
[0137]若第二次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待超时，则终止该等待超时的事务；
[0138]若第二次超时检测的结果表明所述第一计算节点上运行的多个事务在等待超时前已被执行，则认定为系统内不存在死锁。
[0139]进一步的，所述控制节点发送的第二次超时检测指示消息中包含所述第二时钟的配置值；其中，所述第二时钟的配置值由所述控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定。
[0140]本发明实施例提供的计算节点，通过计算节点进行计算节点上运行的多个事务之间的本地死锁检测，当本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0141]本发明的另一实施例提供一种控制节点，如图10所示，该节点包括:
[0142]接收器81，接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明所述第一计算节点上运行的多个事务之间不存在死锁时进行发送；
[0143]存储器82，用于存储多个计算节点所访问的资源之间的依赖关系；[0144]处理器83，用于根据所述存储器82存储的多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
[0145]进一步的,该控制节点还包括:
[0146]发射器84，用于在所述处理器83进行所述多个计算节点之间的全局死锁检测之后，向所述第一计算节点反馈全局死锁检测结果。
[0147]进一步的，所述发射器84，还用于在所述处理器83进行所述多个计算节点之间的全局死锁检测之后，当全局死锁检测结果表明所述多个计算节点之间存在死锁时，向所述第一计算节点发送的第二次超时检测指示消息；
[0148]其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对多个事务进行第二次超时检测。
[0149]进一步的，所述处理器83，还用于在所述发射器84向所述第一计算节点发送的第二次超时检测指示消息之前，根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值包含在所述第二次超时检测指示消息中发送给所述计算节点。
[0150]本发明实施例提供的控制节点，当计算节点本地死锁检测的结果表明运行在计算节点上的多个事务之间不存在死锁时，触发控制节点进行多个计算节点之间的全局死锁检测，计算节点与控制节点之间的用于死锁检测的通信开销较小，并且计算节点承担了本地死锁检测的工作以减轻控制节点的死锁检测负担，从而均衡死锁检测造成的负荷。
[0151]本发明另一实施例还提供一种具备死锁检测功能的数据库系统，也可称为死锁检测系统，如图11所示，该系统可以包括:控制节点和多个计算节点。
[0152]计算节点91，用于根据运行在计算节点91上的多个事务所访问的资源之间的依赖关系，进行所述计算节点91的多个事务之间的本地死锁检测；当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点92发送全局死锁检测请求，以使所述控制节点92根据多个计算节点91所访问的资源之间的依赖关系进行所述多个计算节点91之间的全局死锁检测；
[0153]控制节点92，用于接收计算节点91发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述计算节点91在本地死锁检测的结果表明所述计算节点91的多个事务之间不存在死锁时进行发送；根据多个计算节点91所访问的资源之间的依赖关系进行所述多个计算节点91之间的全局死锁检测。
[0154]本发明实施例提供的死锁检测系统，通过计算节点91进行计算节点91的多个事务之间的本地死锁检测，当本地死锁检测的结果表明所述多个事务之间不存在死锁时，触发控制节点92进行多个计算节点91之间的全局死锁检测，计算节点91与控制节点92之间的用于死锁检测的通信开销较小，并且计算节点91承担了本地死锁检测的工作以减轻控制节点92的死锁检测负担，从而均衡死锁检测造成的负荷。
[0155]通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
[0156]以上所述，仅为本发明的【具体实施方式】，但本发明的保护范围并不局限于此，任何熟悉本【技术领域】的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。
【权利要求】
1.一种死锁检测方法，其特征在于，包括: 第一计算节点根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测； 当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
2.根据权利要求1所述的死锁检测方法，其特征在于，在所述根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测之前，该方法还包括: 启动第一时钟，对所述第一计算节点上运行的多个事务进行第一次超时检测； 当第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，执行所述根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测的步骤。
3.根据权利要求2所述的死锁检测方法，其特征在于，在向控制节点发送全局死锁检测请求之后，该方法还包括: 当所述全局死锁检测结果表明所述多个计算节点之间存在死锁时，接收所述控制节点发送的第二次超时检测指示消息； 启动第二时钟，对所述第一计算节点上运行的多个事务进行第二次超时检测； 若第二次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待超时，则终止该等待超时的事务； 若第二次超时检测的结果表明所述第一计算节点上运行的多个事务在等待超时前已被执行，则确定系统内不存在死锁。
4.根据权利要求3所述的死锁检测方法，其特征在于，所述控制节点发送的第二次超时检测指示消息中包含所述第二时钟的配置值；其中，所述第二时钟的配置值由所述控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定。
5.根据权利要求1所述的死锁检测方法，其特征在于，在向控制节点发送全局死锁检测请求之后，该方法还包括: 接收所述控制节点反馈的全局死锁检测结果。
6.一种死锁检测方法，其特征在于，包括: 控制节点接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明运行在所述第一计算节点上的多个事务之间不存在死锁时进行发送； 根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
7.根据权利要求6所述的死锁检测方法，其特征在于，在根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，该方法还包括: 当全局死锁检测结果表明所述多个计算节点之间存在死锁时，向所述第一计算节点发送的第二次超时检测指示消息； 其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对多个事务进行第二次超时检测。
8.根据权利要求7所述的死锁检测方法，其特征在于，在向所述第一计算节点发送的第二次超时检测指示消息之前，该方法还包括: 根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值包含在所述第二次超时检测指示消息中发送给所述第一计算节点。
9.根据权利要求6所述的死锁检测方法，其特征在于，在根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，该方法还包括: 向所述第一计算节点反馈全局死锁检测结果。
10.一种计算节点，作为第一计算节点，其特征在于，所述计算节点包括: 本地检测单元，用于根据运行在所述第一计算节点上的多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测； 请求发送单元，用于当所述本地检测单元执行的本地死锁检测的结果表明所述第一计算节点上运行的多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求，以使所述控制节点根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
11.根据权利要求10所述的计算节点,其特征在于,还包括: 一次超时单元，用于在所述本地检测单元根据运行在所述计算节点上的多个事务所访问的资源之间的依赖关系， 进行所述第一计算节点上运行的多个事务之间的本地死锁检测之前，启动第一时钟，对所述第一计算节点上运行的多个事务进行第一次超时检测； 所述本地检测单元，具体用于当所述一次超时单元执行的第一次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待资源超时，执行所述根据多个事务所访问的资源之间的依赖关系，进行所述第一计算节点上运行的多个事务之间的本地死锁检测的步骤。
12.根据权利要求11所述的计算节点，其特征在于，还包括: 指示接收单元，用于在所述请求发送单元向控制节点发送全局死锁检测请求之后，当所述全局死锁检测结果表明所述多个计算节点之间存在死锁时，接收所述控制节点发送的第二次超时检测指示消息； 二次超时单元，用于启动第二时钟，对多个事务进行第二次超时检测；若第二次超时检测的结果表明所述第一计算节点上运行的一个或多个事务等待超时，则终止该等待超时的事务；若第二次超时检测的结果表明所述第一计算节点上运行的多个事务在等待超时前已被执行，则认定为系统内不存在死锁。
13.根据权利要求12所述的计算节点，其特征在于，所述控制节点发送的第二次超时检测指示消息中包含所述第二时钟的配置值；其中，所述第二时钟的配置值由所述控制节点根据所述多个计算节点的消息传输时延和/或事物处理时长确定。
14.根据权利要求10所述的计算节点,其特征在于,还包括: 结果接收单元，用于在所述请求发送单元向控制节点发送全局死锁检测请求之后，接收所述控制节点反馈的全局死锁检测结果。
15.一种控制节点，其特征在于，包括:请求接收单元，用于接收第一计算节点发送的全局死锁检测请求；其中，所述全局死锁检测请求由所述第一计算节点在本地死锁检测的结果表明运行在所述第一计算节点上运行的多个事务之间不存在死锁时进行发送； 全局检测单元，用于在所述请求接 收单元接收到所述全局死锁检测请求后，根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
16.根据权利要求15所述的控制节点，其特征在于，还包括: 结果指示单元，用于在所述全局检测单元根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，当全局死锁检测结果表明所述多个计算节点之间存在死锁时，向所述计算节点发送的第二次超时检测指示消息； 其中，所述第二次超时检测指示消息用于指示所述第一计算节点启动第二时钟，对所述第一计算节点上运行的多个事务进行第二次超时检测。
17.根据权利要求16所述的控制节点，其特征在于， 所述结果指示单元，还用于在向所述第一计算节点发送的第二次超时检测指示消息之前，根据所述多个计算节点的消息传输时延和/或事物处理时长确定第二时钟的配置值；其中，所述第二时钟的配置值包含在所述第二次超时检测指示消息中发送给所述第一计算节点。
18.根据权利要求15所述的控制节点，其特征在于，还包括: 结果发送单元，用于在所述全局检测单元根据多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测之后，向所述第一计算节点反馈全局死锁检测结果。
19.一种死锁检测系统，其特征在于，包括:控制节点以及多个计算节点，其中， 所述计算节点，用于根据运行在所述计算节点上的多个事务所访问的资源之间的依赖关系，进行所述多个事务之间的本地死锁检测；当本地死锁检测的结果表明所述多个事务之间不存在死锁时，向控制节点发送全局死锁检测请求； 所述控制节点，用于在接收到所述计算节点发送的全局死锁检测请求后，根据所述多个计算节点所访问的资源之间的依赖关系进行所述多个计算节点之间的全局死锁检测。
【文档编号】G06F17/30GK103455368SQ201310379121
【公开日】2013年12月18日 申请日期:2013年8月27日 优先权日:2013年8月27日
【发明者】黄文龙, 文继军, 文雨 申请人:华为技术有限公司