数据库事务的死锁检测方法、装置及电子设备

技术领域

本发明涉及数据库技术领域，尤其是涉及一种数据库事务的死锁检测方法、装置及电子设备。

背景技术

死锁检测是一个成本较高的工作，其涉及到持有锁系统互斥锁、获取处于挂起状态的事务、构建事务等待图、计算是否出现环和释放锁系统互斥锁。

在实际操作中，只要数据库锁系统的后台线程发现有事务挂起，就会触发死锁检测。但是，实际上大部分事务冲突都不会出现死锁，在传统数据库中，通过上述死锁检测方式的有效死锁检测概率大概在3%左右，因而导致大量的死锁检测没有实际意义。并且，大量的死锁检测不但消耗了数据库系统CPU资源，由于死锁检测持有锁系统互斥锁，其还降低了锁系统的并发处理能力，以及增加了真正需要死锁检测的响应耗时。

整体而言，现有数据库的死锁检测方式，会导致大量无意义的死锁检测，浪费了数据库系统CPU资源，降低了锁系统的并发处理能力，死锁检测效率较低。

发明内容

有鉴于此，本发明的目的在于提供一种数据库事务的死锁检测方法、装置及电子设备，可以减少数据库锁系统的无意义死锁检测的数量，提升死锁检测效率，节约数据库系统的CPU资源，并提高锁系统的并发处理能力。

第一方面，本发明实施例提供了一种数据库事务的死锁检测方法，包括：如果目标事务处于挂起状态，判断该目标事务是否满足预设的发生死锁的必要条件；其中，当该目标事务被阻塞时，该目标事务处于挂起状态；如果该目标事务满足该发生死锁的必要条件，触发死锁检测。

在本发明可选的实施例中，上述判断该目标事务是否满足预设的发生死锁的必要条件的步骤，包括：检测阻塞该目标事务的第一事务是否处于挂起状态，以及是否存在被该目标事务阻塞的第二事务；如果阻塞该目标事务的第一事务处于挂起状态，且存在被该目标事务阻塞的第二事务，确定该目标事务满足该发生死锁的必要条件。

在本发明可选的实施例中，上述检测是否存在被该目标事务阻塞的第二事务的步骤，包括：获取预设计数参数的计数值，其中，该计数参数用于对被该目标事务阻塞的第二事务进行计数；判断该计数值是否为零，如果否，则确定存在被该目标事务阻塞的第二事务。

在本发明可选的实施例中，通过原子递增的方式对该预设计数参数进行计数。

在本发明可选的实施例中，上述方法还包括：如果该计数值不为零，则在检测到该目标事务完成提交的情况下，对该计数值清零。

在本发明可选的实施例中，上述检测阻塞该目标事务的第一事务是否处于挂起状态的步骤，包括：读取阻塞该目标事务的第一事务的状态信息；根据该状态信息判断该第一事务是否处于挂起状态。

在本发明可选的实施例中，在如果阻塞该目标事务的第一事务处于挂起状态，且存在被该目标事务阻塞的第二事务，触发死锁检测的步骤之后，上述方法还包括：如果死锁检测的结果为存在死锁，则撤销该目标事务。

第二方面，本发明实施例还提供了一种数据库事务的死锁检测装置，包括：必要条件判断模块，用于在目标事务处于挂起状态的情况下，判断该目标事务是否满足预设的发生死锁的必要条件；其中，当该目标事务被阻塞时，该目标事务处于挂起状态；死锁检测触发模块，用于在该目标事务满足该发生死锁的必要条件的情况下，触发死锁检测。

第三方面，本发明实施例还提供了一种电子设备，该电子设备包括处理器和存储器，该存储器存储有能够被该处理器执行的计算机可执行指令，该处理器执行该计算机可执行指令以实现上述数据库事务的死锁检测方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令在被处理器调用和执行时，计算机可执行指令促使处理器实现上述数据库事务的死锁检测方法。

本发明实施例带来了以下有益效果：

本发明实施例提供的一种数据库事务的死锁检测方法、装置及电子设备，如果检测到目标事务处于挂起状态，判断该目标事务是否满足预设的发生死锁的必要条件；其中，当该目标事务被阻塞时，该目标事务处于挂起状态；如果该目标事务满足该发生死锁的必要条件，触发死锁检测。该方式中，通过设置发生死锁的必要条件，只在满足该必要条件时才进行死锁检测，排除了一部分不可能发生死锁的目标事务被挂起的情况，从而减少了死锁检测的次数，提高了死锁检测的效率，节约了数据库系统的CPU资源，并提高锁系统的并发处理能力。

本公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本公开的上述技术即可得知。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的一种数据库事务的死锁检测方法的流程示意图；

图2为本发明实施例提供的另一种数据库事务的死锁检测方法的流程示意图；

图3为本发明实施例提供的一种数据库事务的死锁检测装置的结构示意图；

图4为本发明实施例提供的一种电子设备的结构示意图。

图标：31-必要条件判断模块；32-死锁检测触发模块；41-处理器；42-存储器；43-总线；44-通信接口。

具体实施方式

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

写冲突是数据库在联机事务处理过程（On-Line Transaction Processing，OLTP）中常见的现象，为了避免在事务写冲突场景下出现死锁，数据库通常会进行死锁检测。其中，死锁检测的大致流程如下：

（1）持有本事务的事务级别互斥锁；

（2）判断本事务是否和其他事务出现行锁冲突；

（3）如果出现冲突，挂起本事务，设置挂起状态；

（4）进行死锁检测；

（5）释放本事务的事务级别互斥锁。

考虑到现有数据库的死锁检测方式会导致大量无意义的死锁检测，造成死锁检测效率低的问题，本发明实施例提供的一种数据库事务的死锁检测方法、装置及电子设备，该技术可以应用于需要进行死锁检测的各种应用场景中。为便于对本实施例进行理解，首先对本发明实施例所公开的一种数据库事务的死锁检测方法进行详细介绍。

参见图1，所示为一种数据库事务的死锁检测方法的流程示意图，由图1可见，该方法包括下述步骤：

步骤S102：如果目标事务处于挂起状态，判断该目标事务是否满足预设的发生死锁的必要条件；其中，当该目标事务被阻塞时，该目标事务处于挂起状态。

在本实施例中，该死锁检测方法应用于数据库系统，用于优化数据库系统中的锁系统。例如，该锁系统可以是MySQL Innodb存储引擎的关于行锁、表锁的子系统。并且，上述事务是指访问并可能更新数据库中各种数据项的一个程序执行单元，它是恢复和并发控制的基本单位，并且，事务通常由事务开始(begin transaction)和事务结束(endtransaction)之间执行的全体操作组成。

这里，死锁是指两个或两个以上的事务在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，他们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。

其中，发生死锁的必要条件可以包括：

（1）互斥条件：事务对于所分配到的资源具有排它性，即一个资源只能被一个事务占用，直到被该事务释放；

（2）占有且等待：一个事务因请求被占用资源而发生阻塞时，对已获得的资源保持不放；

（3）不可抢占条件：任何一个资源在没被事务释放之前，任何其他事务都无法对他剥夺占用；

（4）循环等待条件：当发生死锁时，所等待的事务必定会形成一个环路（类似于死循环），造成永久阻塞。

也即，当同时满足上述四个条件时，才会出现死锁。而在实际操作中，只要数据库锁系统的后台线程发现有事务挂起，就会触发死锁检测。但是，实际上大部分事务冲突都不会出现死锁，从而造成检测资源的浪费。

为了缓解上述实际不会出现死锁但仍进行死锁检测的问题，本申请提供的死锁检测方案，在检测到目标事务处于挂起状态时，并不会立刻进行死锁检测，而是先判断该目标事务是否满足预设的发生死锁的必要条件，只有在满足该预设的必要条件时，才出发死锁检测。其中，上述预设的发生死锁的必要条件可以是上述四个必要条件中的任意一个或多个。

步骤S104：如果该目标事务满足该发生死锁的必要条件，触发死锁检测。

通过设置发生死锁的必要条件，并基于该必要条件对目标事务进行判断，筛选出满足该必要条件的目标事务，仅在目标事务满足条件时触发死锁检测，从而筛除了一部分不会发生死锁的情况，减少了死锁检测的次数，提高了死锁检测的命中率和效率，也节省了系统资源。

在至少一种可能的实施方式中，上述步骤S102中判断该目标事务是否满足预设的发生死锁的必要条件的步骤，可以通过下述步骤11-12实现：

（11）如果检测到目标事务处于挂起状态，检测阻塞该目标事务的第一事务是否处于挂起状态，以及是否存在被该目标事务阻塞的第二事务。

在其中一种可能的实施方式中，可以按下述步骤21-23判断目标事务是否需要被挂起：

（21）如果接收到用户针对目标事务的处理请求，为该目标事务分配对应的处理线程。

（22）持有该目标事务的事务级别的互斥锁。

这里，该互斥锁是为了解决在多线程访问共享资源时，多个线程同时对共享资源操作产生的冲突而提出的一种解决方法。在执行时，哪个线程持有互斥锁，并对共享资源进行加行锁后，才能对共享资源进行操作，此时其它线程不能对共享资源进行操作。只有在持有行锁的线程将该共享资源的行锁解锁释放后，其它线程才能对该共享资源进行抢行锁和加行锁的操作。

例如，事务T1为修改某条记录R1，在T1提交前，T1持有R1的行锁（具有互斥特性）。此时，假设另外一个事务T2也要修改R1这条记录，T2会尝试获取R1的行锁。如果T1此时尚未提交，则T2无法获取R1的行锁，此时，数据库会挂起T2，即让T2进入挂起等待状态。当T1提交后，数据库会唤醒T2，T2再去获取R1的行锁，并进行修改和相关后续工作。

（23）判断该目标事务是否与数据库中除该目标事务之外的数据库事务有行锁冲突；如果是，挂起该目标事务。

其中，由于每个行都可以有行锁（互斥性质的锁），当一个事务持有某行的行锁时，如果另外一个事务也尝试获取该行的行锁，就会出现行锁冲突。

这里，如果该目标事务与数据库中的其他事务有行锁冲突，表明该目标事务尝试获取的目标行的行锁被其他事务占用，需要等待该目标行的行锁被释放后才能获取，然后对目标行进行相应的操作，此时，挂起该目标事务。

另外，如果该目标事务与其他事务没有行锁冲突，则表明其可以获取到目标行的互斥锁，并对目标行进行相应操作。

（12）如果阻塞该目标事务的第一事务处于挂起状态，且存在被该目标事务阻塞的第二事务，触发死锁检测。

在本实施例中，仅在同时满足阻塞该目标事务的第一事务处于挂起状态，并且，存在被该目标事务阻塞的第二事务时，才触发死锁检测。并且，如果不存在被该目标事务阻塞的第二事务，或者，阻塞该目标事务的第一事务不是处于挂起状态，都不会触发死锁检测。

这里，上述步骤11-12是发生死锁的四个必要条件中循环等待条件的一种具体形式，因此也是发生死锁的必要条件之一。即当发生死锁时，必然出现目标事务处于挂起状态，且阻塞该目标事务的第一事务处于挂起状态，且存在被该目标事务阻塞的第二事务的情况。发明人通过对比发现，通过该发生死锁的必要条件可以排除很大部分的不可能发生死锁的情况，有效降低死锁检测量。并且该发生死锁的必要条件中的各检测项均易于检测，因此即便在死锁检测前增加了判断是否满足该必要条件的步骤，也不会过多占用CPU等数据库系统资源。因此，在减少数据库锁系统的死锁检测量、提升死锁检测效率的同时，也节约了数据库系统的CPU资源，并提高了锁系统的并发处理能力。

可以理解的是，在其他可能的实施方式中，还可以基于其他发生死锁的必要条件来减少死锁检测量，在此不作限定。

在至少一种可能的实施方式中，当触发死锁检测后，如果死锁检测的结果为存在死锁，则撤销该目标事务，以避免因死锁而导致该目标事务不能及时处理。

相比于现有的死锁检测方式，本实施例提供的死锁检测方法通过发生死锁的必要条件排除一部分不可能发生死锁的情况，从而减少死锁检测的次数。例如，按照现有的技术方案，后台线程一旦发现有挂起事务，就会进行死锁检测，比如，事务T1要获取事务T2已持有的锁时，此时出现了锁冲突，线程将会挂起T1，从而触发死锁检测。而对于这种情形，实际并没有产生死锁，属于无效的死锁检测，而这种情形占比实际死锁检测的数量极高，从而导致浪费数据库系统CPU资源，降低了锁系统的并发处理能力。而本申请中的死锁检测方式，则可以避免上述情形的发生，当目标事务被挂起时，不会马上触发死锁检测，而唯有满足预设的发生死锁的必要条件时，才触发死锁检测，可见，该方式可以减少大量无效的死锁检测，提高了死锁检测的效率，节约了数据库系统的CPU资源，并提高锁系统的并发处理能力。

在图1所示数据库事务的死锁检测方法的基础上，本实施例还提供了另一种死锁检测方法，该方法通过一可选实施例重点描述了确定是否满足死锁检测触发条件的实现过程，也即，描述了检测是否存在被目标事务阻塞的第二事务，以及检测阻塞目标事务的第一事务是否处于挂起状态的具体实现过程。

如图2所示，其为一种可选的数据库事务的死锁检测方法的流程示意图，由图2可见，该方法包括下述步骤：

步骤S202：判断目标事务是否处于挂起状态；如果是，执行步骤S204；如果否，执行步骤S212；其中，当该目标事务被阻塞时，该目标事务处于挂起状态。

这里，当目标事务与数据库中的其他事务存在锁冲突时，该目标事务会被挂起，此时，也表明有其他事务阻塞了该目标事务。在其中一种可能的实施方式中，可以通过该目标事务的状态信息判断其是否处于挂起状态。其中，如果目标事务处于挂起状态，则进一步判断阻塞该目标事务的第一事务是否处于挂起状态；如果该目标事务没有处于挂起状态，则不进行死锁检测。

步骤S204：判断阻塞该目标事务的第一事务是否处于挂起状态；如果是，执行步骤S206；如果否，执行步骤S212。

在其中一种可能的实施方式中，可以通过读取阻塞该目标事务的第一事务的状态信息，并根据该状态信息判断该第一事务是否处于挂起状态。其中，如果该第一事务也处于挂起状态，则获取预设计数参数的计数值，这里，该计数参数用于对被目标事务阻塞的第二事务进行计数；如果该第一事务没有处于挂起状态，则不进行死锁检测。

步骤S206：获取预设计数参数的计数值，其中，该计数参数用于对被目标事务阻塞的第二事务进行计数。

如果存在被目标事务阻塞的第二事务，则该计数值必然不为零。

步骤S208：判断该计数值是否为零；如果否，执行步骤S210；如果是，执行步骤S212。

如果该计数值为零，则表明当前没有被目标事务阻塞的第二事务，则认为不构成死锁，此时，不进行死锁检测。

如果该计数值不为零，确定当前存在被目标事务阻塞的第二事务，此时，触发死锁检测。由于目标事务被挂起，且阻塞目标事务的第一事务也被挂起，以及存在被目标事务阻塞的第二事务，此时，已经形成了死锁，因而触发死锁检测。

步骤S210：确定存在被该目标事务阻塞的第二事务，触发死锁检测。

步骤S212：不进行死锁检测。

这样，通过上述步骤S202至S212，即可以确定是否满足死锁检测触发条件，进而触发死锁检测。

在实际操作中，上述死锁检测方式可以通过建模来实现，其中，设置挂起事务为from，其等待的事务为to，并设置出现死锁充分条件为：事务to处于挂起状态，且事务from阻塞了其他事务。通过建立的该模型处理目标事务时，事务挂起逻辑如下：

1) 持有目标事务的事务级别互斥锁；

2) 判断目标事务是否和其他事务出现行锁冲突；

3) 如果出现冲突，挂起目标事务，设置挂起状态；

4) 记录目标事务阻塞到哪个事务，即记录from\to的逻辑关系；

5) 对to事务的阻塞计数进行原子递增；

6) 如果from事务的阻塞计数大于0，且to事务是挂起状态，则进行死锁检测，否则直接返回；

7) 释放目标事务的事务级别互斥锁。

并且，通过建立的上述模型处理目标事务时，事务提交逻辑如下：

1) 持有目标事务互斥锁；

2) 释放目标事务的行锁；

3) 获取阻塞到目标事务行锁的事务；

4) 持有目标事务所阻塞的对应事务的互斥锁；

5) 唤醒对应事务；

6) 释放对应事务的互斥锁；

7) 释放目标事务互斥锁；

8) 重置阻塞计数；

9) 释放事务资源。

这样，通过上述对死锁检测进行建模的方式，使用极低的开销，实现减少大量无效的死锁检测。上述死锁检测方式应用于秒杀等高冲突的场景中时，可以大幅提升数据库系统并发处理能力，缩短死锁检测的响应耗时。

对应于图1中所示的数据库事务的死锁检测方法，本发明实施例还提供了一种数据库事务的死锁检测装置，参见图3，所示为一种数据库事务的死锁检测装置的结构示意图，由图3可见，该装置包括彼此相连的必要条件判断模块31和死锁检测触发模块32，其中，各个模块的功能如下：

必要条件判断模块31，用于在目标事务处于挂起状态的情况下，判断该目标事务是否满足预设的发生死锁的必要条件；其中，当该目标事务被阻塞时，该目标事务处于挂起状态；

死锁检测触发模块32，用于在该目标事务满足该发生死锁的必要条件的情况下，触发死锁检测。

在其中一种可能的实施方式中，上述必要条件判断模块31还用于：检测阻塞该目标事务的第一事务是否处于挂起状态，以及是否存在被该目标事务阻塞的第二事务；如果阻塞该目标事务的第一事务处于挂起状态，且存在被该目标事务阻塞的第二事务，确定该目标事务满足该发生死锁的必要条件。

在另一种可能的实施方式中，上述必要条件判断模块31还用于：获取预设计数参数的计数值，其中，该计数参数用于对被该目标事务阻塞的第二事务进行计数；判断该计数值是否为零，如果否，则确定存在被该目标事务阻塞的第二事务。

在另一种可能的实施方式中，通过原子递增的方式对该预设计数参数进行计数。

在另一种可能的实施方式中，上述装置还包括清零模块，用于：如果该计数值不为零，则在检测到该目标事务完成提交的情况下，对该计数值清零。

在另一种可能的实施方式中，上述必要条件判断模块31还用于：读取阻塞该目标事务的第一事务的状态信息；根据该状态信息判断该第一事务是否处于挂起状态。

在另一种可能的实施方式中，上述装置还包括事务撤销模块，用于：如果死锁检测的结果为存在死锁，则撤销该目标事务。

本发明实施例提供的数据库事务的死锁检测装置，其实现原理及产生的技术效果和前述数据库事务的死锁检测方法实施例相同，为简要描述，数据库事务的死锁检测装置的实施例部分未提及之处，可参考前述数据库事务的死锁检测方法实施例中相应内容。

本发明实施例还提供了一种电子设备，如图4所示，为该电子设备的结构示意图，其中，该电子设备包括处理器41和存储器42，该存储器42存储有能够被该处理器41执行的机器可执行指令，该处理器41执行该机器可执行指令以实现上述数据库事务的死锁检测方法。

在图4示出的实施方式中，该电子设备还包括总线43和通信接口44，其中，处理器41、通信接口44和存储器42通过总线连接。

其中，存储器42可能包含高速随机存取存储器（RAM，Random Access Memory），也可能还包括非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器。通过至少一个通信接口44（可以是有线或者无线）实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器41可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器41中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器41可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessing，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器41读取存储器42中的信息，结合其硬件完成前述实施例的数据库事务的死锁检测方法的步骤。

本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述数据库事务的死锁检测方法，具体实现可参见前述方法实施例，在此不再赘述。

本发明实施例所提供的数据库事务的死锁检测方法、数据库事务的死锁检测装置和电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的数据库事务的死锁检测方法，具体实现可参见方法实施例，在此不再赘述。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。