1.本公开涉及数据库
技术领域：
：，具体涉及用于数据库负载控制的方法、系统、存储介质及计算机程序产品。
背景技术：
：：2.数据库是按照数据结构存储和管理数据的软件系统，可以接受其它应用的数据存储和搜索请求，并对这些请求进行响应。数据库接受和处理请求的能力被称为负载，受制于操作系统的性能上限限制，数据库的处理能力不可能无限提高。由于性能上限的存在，任一时间数据库每多接受一个请求，都会减少此时其剩余的处理能力，直到该请求被处理完毕。3.因此，需要对数据库进行负载控制。负载控制，是指控制数据库接受和处理请求的能力，例如使得可以根据实际情况进行动态调配，避免由于过多接受那些相对较为消耗资源的请求，反而降低了对于资源消耗低的请求的处理能力(表现为数据库性能下降，甚至失去响应能力等)。4.数据库代理层，相当于数据处理请求的中转服务。数据处理请求从客户端/应用被发送给数据库代理层，由数据库代理层将数据处理请求中转到底层数据库和对底层数据库进行操作，并将结果返回给客户端/应用。可以对数据库代理层添加例如负载控制、流量控制、权限管理等各种功能，以对数据处理请求进行统一管理。通用数据访问层(universaldataaccesslayer，udal)是中国电信信息化研发中心研发的一款数据访问代理中间件，该中间件接收来自客户端/应用的数据处理请求，然后将该数据处理请求转发到底层的数据存储数据库(例如mysql后端存储等)中。5.数据库代理层作为调用者和实际存储数据库的代理层，如果缺乏数据库负载控制机制，将可能无限制地接收数据处理请求，造成数据库处理请求的能力变差等问题。这些问题包括例如：1)数据库代理层的客户端提交了大量耗时较长的数据处理请求，这些请求都无限制地直接发往了底层的数据存储数据库，造成底层数据库响应能力下降甚至失去响应；2)数据库代理层的某个客户端发起了高频率的数据处理请求，造成单个客户端占用大多数资源，挤占了其它客户端，造成其它客户端的数据处理请求无法被处理或者数据库的处理能力下降等问题。6.对于此类问题，在传统的技术方案中，通常采用以下方式解决上述问题。参考图1，对于问题1)通常让数据库管理员109综合使用统计监控工具，在数据库代理层105将要向用户101返回响应111时，收集已被响应的请求的耗时信息104，人工找出耗时相对较长的请求，然后人工通过管理连接对该请求进行销毁(例如，选择性删除耗时最长的sql语句107)，再通知客户端/应用/用户101对此语句进行优化和调整，保证以后不再出现。仍然参考图1，对于问题2)一般是增加数据库集群节点，保证数据库处理能力充足；另一方面还可以通过熔断器或者流控模块110根据数据库负载信息103对数据处理请求102进行无差别熔断、限流等限制106，优先保证系统稳定。这种方案需人工介入，而且或者针对单个请求或者进行无差别限制，不够通用和精确。7.而在阿里云数据库自治服务das的技术方案中，系统根据机器学习的结果，对数据处理请求进行分析，对数据处理请求的负载流量进行控制，并持续将新的请求响应结果加入到机器学习的训练数据当中，用于形成下一阶段的负载控制策略。持续监控负载控制策略的效果，用于进行下一次迭代计算。但是，机器学习会综合分析各类指标因素，训练、迭代所需的时间周期比较长，实时性较差，无法及时解决系统的负载问题。技术实现要素：8.在下文中给出了关于本公开的简要概述，以便提供关于本公开的一些方面的基本理解。但是，应当理解，这个概述并不是关于本公开的穷举性概述。它并不是意图用来确定本公开的关键性部分或重要部分，也不是意图用来限定本公开的范围。其目的仅仅是以简化的形式给出关于本公开的某些概念，以此作为稍后给出的更详细描述的前序。9.根据本公开的一方面，提供了用于数据库负载控制的方法，包括：获得第一请求事件；根据由第一请求事件中包括的语句表示的执行计划，将第一请求事件分类到对应的类型的事件组中；利用该事件组的所有已被响应的请求事件的历史数据和当前数据以及该事件组的尚未被响应的请求事件的当前数据来计算该事件组的一个或多个指标；判断该事件组是否存在指标满足预定规则；响应于该事件组存在指标满足预定规则，判断系统性能是否超过第一阈值；以及响应于系统性能超过第一阈值，对第一请求事件进行拦截。10.根据一个实施例，上述方法还包括，针对每个事件组，周期性地利用该事件组的所有已被响应的请求事件的历史数据和当前数据以及该事件组的尚未被响应的请求事件的当前数据来计算该事件组的一个或多个指标；判断该事件组是否存在指标满足预定规则；响应于该事件组存在指标满足预定规则，判断系统性能是否超过第一阈值；以及响应于系统性能超过第一阈值，对存在指标满足预定规则的事件组中的正在执行的请求事件进行销毁。11.根据一个实施例，在上述方法中，所述事件组的所有已被响应的请求事件的历史数据a包括：所述事件组在过去的t时间段内的所有已被响应的请求事件的数量的总和a.num，和所述事件组在过去的t时间段内的所有已被响应的请求事件的总耗时的总和a.csm。在上述方法中，将所述事件组的所有已被响应的请求事件的历史数据a按时间顺序划分成m个子时间段，每个子时间段的时间段长度均为每个子时间段的数据记为ai，i＝1,2,…,m；以堆栈形式存储数据a1,a2,…,am，其中，a1,a2,…,am为按照时间顺序从最接近当前时间到最早历史时间的每个子时间段的数据；其中，ai包括：所述事件组在第i个子时间段内的所有已被响应的请求事件的数量ai.num，和所述事件组在第i个子时间段内的所有已被响应的请求事件的总耗时ai.csm；根据以下公式得出所述事件组的所有已被响应的请求事件的历史数据a：以及其中，所述事件组的所有已被响应的请求事件的当前数据a0涉及的当前时间段的长度也为当前数据a0包括：所述事件组在当前时间段内的所有已被响应的请求事件的数量a0.num，和所述事件组在当前时间段内的所有已被响应的请求事件的总耗时a0.csm；其中，所述事件组的尚未被响应的请求事件的当前数据aun包括：所述事件组在当前时间尚未被响应的请求事件的数量aun.num，和所述事件组在当前时间尚未被响应的请求事件的总耗时aun.csm。12.根据一个实施例，在上述方法中，计算该事件组的一个或多个指标包括：针对该事件组，执行来获得该事件组的请求事件的平均耗时；或者针对该事件组，执行a.num+a0.num+aun.num来获得该事件组的请求事件的总数量；或者针对该事件组，获得当前时间段内该事件组的请求事件的并发处理数。13.根据一个实施例，在上述方法中，判断该事件组是否存在指标满足预定规则包括：判断该事件组的请求事件的平均耗时是否超过所有事件组的请求事件的平均耗时；或者判断该事件组的请求事件的总数量占所有事件组的请求事件的总数量是否超过预定比例；或者判断该事件组的请求事件的并发处理数是否超过第二阈值。14.根据一个实施例，上述方法还包括，在第一请求事件未被拦截的情况下：记录第一请求事件的请求信息，其中请求信息包括请求时间；在第一请求事件已被响应后，记录第一请求事件的响应信息，其中响应信息包括响应时间，第一请求事件的耗时等于响应时间与请求时间的差；将第一请求事件的数据添加到对应的类型的事件组的当前数据。15.根据一个实施例，上述方法还包括，针对每个事件组，利用该事件组的所有已被响应的请求事件的当前数据来更新历史数据，其中利用当前数据来更新历史数据包括：对于以堆栈形式存储的数据a1,a2,…,am，删除最早的子时间段所包括的数据am，插入当前数据中未被拦截的请求事件的数据a′0，以进行栈的更新；以及执行a.num-am.num+a′0.num，以及a.csm-am.csm+a′0.csm来分别作为用于下一时间段的计算操作的历史数据，其中，a′0.num以及a′0.csm分别是所述事件组的所有已被响应的请求事件的当前数据中未被拦截的请求事件的数量以及总耗时。16.根据本公开另一方面，提供一种用于数据库负载控制的系统，包括：至少一个处理器，和与所述至少一个处理器耦接的存储器，所述存储器中存储有可执行指令，所述指令在被所述至少一个处理器执行时执行本公开的方法。17.根据本公开又一方面，提供一种非暂态计算机可读存储介质，其上存储有可执行指令，所述指令在由处理器执行时，使所述处理器可以执行本公开的方法。18.根据本公开又一方面，提供一种用于数据库负载控制的计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现本公开的方法的操作。19.根据本公开的一个或多个实施例，通过对监听到的请求事件进行分类，并利用每个类型的请求事件的历史数据和当前数据来计算指标；在系统性能较差时，根据关键指标对部分请求事件进行拦截和销毁，能够自动控制数据库的负载情况。根据本公开的一个或多个实施例，能够实现高效实时(纳秒级)的指标计算和历史数据的动态更新，使得控制结果能够及时反应到下一阶段的指标计算结果和下一阶段的负载控制机制当中，形成数据库负载控制自治机制的闭环，能够根据当前数据库的负载情况进行负载控制机制的实时自适应调整，使得数据库始终保持较高的数据处理能力。20.从参考附图的以下描述中，本公开其他特征和优点将变得清楚。附图说明21.并入说明书中并构成说明书的一部分的附图图示了本公开的实施例，并且与说明书一起用于解释本公开的原理而没有限制。在各图中，类似的标号用于表示类似的项目。22.图1是示出用于数据库负载控制的现有技术。23.图2是示出根据本公开实施例的用于数据库负载控制的系统环境。24.图3是示出根据本公开实施例的用于数据库负载控制的方法的流程图。25.图4是示出根据本公开另一实施例的用于数据库负载控制的方法的流程图。26.图5是示出根据本公开实施例的用于判断事件组是否存在指标满足预定规则的方法的流程图。27.图6是示出根据本公开实施例的用于事件组的数据结构。28.图7是示出可以实现根据本公开实施例的系统的一般硬件环境的示意图。具体实施方式29.现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其他示例可以具有不同的值。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。30.应注意到，相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。31.图2是示出根据本公开实施例的用于数据库负载控制的系统环境200。在该系统环境200中，数据库代理层205接收来自用户201(例如，客户端、应用等)的请求事件202，将请求事件转发到底层的数据存储分片208a、208b、208c(以下简便起见，统称为数据存储分片208)。其中数据库代理层例如可以是采用java编写的udal，请求事件202例如可以是，用sql语句表示的数据处理请求。32.根据一个实施例，每当用户201向数据库代理层205发送请求事件202时，数据库负载控制模块209获得请求事件202，通过本公开的数据库负载控制机制，在该请求事件超出系统性能限制的情况下对该请求事件进行拦截206；在请求事件没有被拦截的情况下，记录请求事件202的请求信息203，并在数据存储分片208完成对该请求的处理后，在数据库代理层205将要向用户201返回响应211时，记录该请求事件的响应信息204，以便于实时更新用于数据库负载控制机制的数据。33.根据本公开的又一实施例，数据库负载控制模块209周期性地调用各请求事件的数据(例如，耗时数据)，通过本公开的数据库负载控制机制对其进行分析，以对超出系统性能限制的一个或多个正在执行的请求事件进行销毁207，使得数据库始终保持较高的数据处理能力。34.下面将结合图3-图6对本公开的数据库负载控制方法进行示例性说明。35.图3是示出根据本公开实施例的用于数据库负载控制的方法300的流程图。方法300可以每当用户向数据库代理层发送请求事件时触发执行，以对数据库负载进行控制。方法300例如可以是针对新提交到udal的、尚未被数据库执行的数据处理请求进行的处理。36.如图3所示，方法300包括操作m301，在该操作中，获得第一请求事件。该操作可以在用户向数据库代理层205发送请求事件202时，由例如图2的数据库负载控制模块209来获得。37.方法300还包括，在操作m302中，根据由该第一请求事件中包括的语句表示的执行计划，将第一请求事件分类到对应的类型的事件组中。38.以sql语句为例，在数据库负载控制模块209收到请求事件202时，将sql摘出，经过词法解析、规整化、参数化后，作为请求事件的标识进行记录，使得该请求事件被分类到对应的类型的事件组中，即每个事件组内的请求事件视为同一类型的请求事件。如果尚不存在对应的类型的事件组，则创建对应的类型的事件组；如果已存在对应的类型的事件组则直接获取。同一类型的事件组可以被视为性能消耗指标大致相同的请求事件的集合。在一些示例中，可以根据sql语句涉及的数据量(例如表的大小)、或其语法结构表示的操作等，对请求事件进行分类。例如，selectx,y,zfromtable_afulljointable_b与selectx,y,zfromtable_cfulljointable_d属于不同类型的事件组；而select1fromtest_tablewherex＝3与select*fromtest_tablewherex＝9同属于select*fromtest_tablewherex＝？这样的类型。此处仅为例示，能够将性能消耗指标大致相同的请求事件分类到同一类型的事件组中的其他分类方法也属于本公开的范围。39.继续参考方法300，在操作m303中，利用该事件组的所有已被响应的请求事件的历史数据和当前数据以及该事件组的尚未被响应的请求事件的当前数据来计算该事件组的一个或多个指标。例如，若接收到被分类到第一事件组的第一请求事件，可以针对第一事件组利用所有被分类到第一事件组的请求事件的历史数据和当前数据，来计算第一事件组的请求事件的平均耗时、请求事件的总数量或请求事件的并发处理数等一个或多个指标。该操作能够在第一请求事件到达的瞬间就获得对应的类型的事件组的指标情况。40.继续参考方法300，在操作m304中，判断该事件组是否存在指标满足预定规则。若存在，则继续操作m305；若不存在，则继续操作m307。其中，指标满足预定规则表征该事件组中的请求事件对系统整体性能产生一定的影响。以接收到的第一请求事件被分类到第一事件组为例，若第一事件组存在平均耗时、请求的总数量或并发处理数中任一项满足关于该指标的预定规则，则对第一事件组进行标记，以指示第一事件组存在指标满足预定规则。41.后文将参考图5-图6对操作m303-m304做进一步例示性说明。42.继续参考方法300，在操作m305中，实时判断系统性能是否超过第一阈值；若为是，则继续操作m306；若为否，则继续操作m307。其中，系统性能超过第一阈值表征系统性能受到较大影响，需要进行调整。例如，在udal的例子中，可以判断udal的线程数使用率是否超过80％；若超过80％，则视为系统负载过高，需要进行调整。43.继续参考方法300，在操作m306中，对第一请求事件进行拦截。被拦截的请求事件后续不再进入数据库被处理。44.如果操作m306中对请求事件的拦截成功执行，那么相应事件组的指标就会对应地有所体现，形成自适应动态调整的数据库负载控制机制。例如，如果经过操作m306后，系统性能恢复了正常，那么直接体现就是过度消耗资源的请求事件的数量下降了，在随后分析异常请求事件的时候，就停止对此类请求事件的拦截；如果经过操作m306后，系统性能仍未恢复正常，那么随后会继续对此类请求事件进行拦截直到系统性能恢复正常。45.在方法300中，还包括操作m307，在第一请求事件未被拦截的情况下，记录第一请求事件的请求信息。在一些实施例中，请求信息至少包括请求时间。46.第一请求事件随后被中转到数据存储分片208被处理，在该请求事件被处理完成后，再由数据库代理层向用户返回响应。47.方法300还包括操作m308，在第一请求事件已被响应后，记录第一请求事件的响应信息。在一些实施例中，响应信息至少包括响应时间，则第一请求事件的耗时等于响应时间与请求时间的差。48.可以通过埋点的方式或网络流量探测的方式来获取请求信息、响应信息等相关信息，以用于实时收集和更新请求事件的信息。例如，在使用udal作为数据库代理层服务的情况下，分别在udal接收请求事件202(例如sql语句)的代码位置和将要发出响应的代码位置处发出相关信息，然后由数据库负载控制模块209接收相关信息。再例如，可以监听客户端/服务器处的网卡的流量数据，并将网络流量发送给另一服务器以获取相关信息，该获取信息的方式实时性略逊于埋点的方式。49.可以通过第一请求事件的请求信息、响应信息等来获得第一请求事件的耗时等数据，并可以将第一请求事件的数据添加到对应的类型的事件组的在当前时间段的当前数据。随后，可以利用包含了新增的请求事件的数据的当前数据来更新历史数据，该更新可以是周期性的(例如，每当预定的当前时间段结束时)，该操作可以几乎瞬时完成，使得数据的更新是近乎实时的。将在后文参考图6详述。50.然后该方法可以重复，以获得下一请求事件(例如，第二请求事件)。对于下一请求事件，可以类似于操作m301-m308，利用更新后的历史数据和下一时间段的当前数据进行数据库负载控制。51.图4是示出根据本公开另一实施例的用于数据库负载控制的方法400的流程图。方法400可以是周期性执行的，例如可以每秒钟调用该方法来对数据库负载情况进行控制。该方法400可以是针对先前未被拦截因而已被提交到数据库的、在数据存储分片208处正在执行的事件所涉及的事件组而进行的处理。52.如图4所示，方法400包括操作m401，在该操作中，针对每个事件组，周期性地利用该事件组的所有已被响应的请求事件的历史数据和当前数据以及该事件组的尚未被响应的请求事件的当前数据来计算该事件组的一个或多个指标。例如，针对每个事件组，可以利用所有被分类到该事件组的请求事件的历史数据和当前数据，来计算该事件组的请求事件的平均耗时、请求事件的总数量或请求事件的并发处理数等一个或多个指标。针对每个事件组，均可通过类似操作来获得该事件组的一个或多个指标。53.继续参考方法400，在操作m402中，判断该事件组是否存在指标满足预定规则。若存在，则继续操作m403；若每个事件组均不存在，则返回，待下一周期时再执行该方法。其中，指标满足预定规则表征该事件组中的请求事件对系统整体性能产生一定的影响。以第一事件组为例，若第一事件组存在平均耗时、请求的总数量或并发处理数中任一项满足关于该指标的预定规则，则对第一事件组进行标记，以指示第一事件组存在指标满足预定规则。通过对每个事件组执行类似操作，可以对每个事件组均做出是否存在指标满足预定规则的标记。54.后文将参考图5-图6对操作m401-m402做进一步示例性说明。55.继续参考方法400，在操作m403中，实时判断系统性能是否超过第一阈值；若为是，则继续操作m404；若为否，则返回，待下一周期时再执行该方法。其中，系统性能超过第一阈值表征系统性能受到较大影响，需要进行调整。例如，在udal的例子中，可以判断udal的线程数使用率是否超过80％；若超过80％，则视为系统负载过高，需要进行调整。56.继续参考方法400，在操作m404中，对存在指标满足预定规则的事件组中的正在执行的请求事件进行销毁。在一些实施例中，该操作包括按比例对请求事件进行销毁。57.例如，假设第一、第二事件组均已被标记为存在指标满足预定规则，则对于第一、第二事件组中正在执行(已被提交)的请求事件，按第一、第二事件组的平均耗时比例来对第一、第二事件组中的请求事件进行销毁，最多剩余系统对该第一、第二事件组允许的并发处理数。58.随后，针对每个事件组，可以利用该事件组的未被拦截的当前数据来更新历史数据，该操作可以几乎瞬时完成，使得数据的更新是近乎实时的。然后系统进行到下一周期，对于下一周期内的请求事件，可以类似于操作m401-m404，利用更新后的历史数据和下一时间段的当前数据进行数据库负载控制。59.该系统对于指标超过预定规则的部分请求事件按平均耗时按比例进行拦截和销毁，高效实时地解决了较高耗时的请求事件带来的问题，避免了数据库长期处于高负载情况下。系统对于新增的耗时指标在预定阈值以上的类型的请求事件进行了拦截，使此类请求事件的数量占比保持在警戒线以内，能够优先保证占用资源较少的请求事件的可用性，解决了高频请求事件挤占其他请求的问题。该系统能够较好地解决数据库代理层可能存在的问题。60.而且，该系统能够实时地计算指标、分析性能、调整请求事件，并实时更新请求事件的数据，因此能够避免短时期进行过量调整导致的过度限制，避免使得一些原本可能出现瞬时高并发的正常请求无法稳定访问；也能够有效避免短时期调整不足导致系统短期内仍处于高负载状态而排挤了其他请求。61.下面将结合图5-图6对高效实时计算事件组的指标并对其进行判断做出示例性说明。62.图5是示出根据本公开实施例的用于判断事件组是否存在指标满足预定规则的方法500的流程图。63.如图5所示，在操作m501a中，利用该事件组的所有已被响应的请求事件的历史数据和当前数据以及该事件组的尚未被响应的请求事件的当前数据来计算该事件组的请求事件的平均耗时。在操作m501b中，利用该事件组的所有已被响应的请求事件的历史数据和当前数据以及该事件组的尚未被响应的请求事件的当前数据来计算该事件组的请求事件的总数量。在操作m501c中，获得当前时间段内该事件组的请求事件的并发处理数。64.结合图6的用于事件组的数据结构来示例性描述上述操作。参考图6，以图示事件组为例，例如经过词法解析、规整化、参数化后属于select*fromtest_tablewherex＝？的语句的请求事件被分类到该事件组中，则该事件组所有已被响应的请求事件的历史数据a包括：该事件组在过去的t时间段内的所有已被响应的请求事件的数量的总和a.num，和该事件组在过去的t时间段内的所有已被响应的请求事件的总耗时的总和a.csm。在其他一些实施例中，历史数据还包括该事件组在过去的t时间段内的请求事件的并发处理数。65.其中，在本公开示例的数据结构中，将每个事件组的所有已被响应的请求事件的历史数据a按时间顺序划分成m个子时间段，每个子时间段的时间段长度均为每个子时间段的数据记为ai，i＝1,2,…,m；并且以堆栈形式存储数据a1,a2,…,am，其中，a1,a2,…,am为按照时间顺序从最接近当前时间到最早历史时间的每个子时间段的数据；其中，ai包括：该事件组在第i个子时间段内的所有已被响应的请求事件的数量ai.num，和所述事件组在第i个子时间段内的所有已被响应的请求事件的总耗时ai.csm。在其他一些实施例中，每个子时间段的数据还包括该子时间段内的请求事件的并发处理数。66.根据以下公式得出该事件组的所有已被响应的请求事件的历史数据a：以及67.其中，该事件组的所有已被响应的请求事件的当前数据a0涉及的当前时间段的长度也为当前数据a0包括：该事件组在当前时间段内的所有已被响应的请求事件的数量a0.num，和该事件组在当前时间段内的所有已被响应的请求事件的总耗时a0.csm。在其他一些实施例中，当前数据还包括当前时间段内的该请求事件的并发处理数。68.其中，该事件组的尚未被响应的请求事件的当前数据aun包括：所述事件组在当前时间尚未被响应的请求事件的数量aun.num，和所述事件组在当前时间尚未被响应的请求事件的总耗时aun.csm。69.在一些实施例中，其中请求信息包括请求时间，响应信息包括响应时间。每个请求事件的耗时可以如下定义：在数据库代理层对该请求事件做出响应的情况下，该请求事件的耗时等于响应时间与请求时间的差；在数据库代理层尚未对请求事件做出响应的情况下，该请求事件的耗时等于当前时间与请求时间的差。其中，若请求事件被执行了销毁命令，则该请求事件在数据库处理完成后，也会产生相应的响应，因而也具有响应信息或响应时间。70.返回参考图5，利用图6所示的数据结构，在操作m501a中，通过计算来获得该事件组的请求事件的平均耗时。在操作m501b中，通过执行a.num+a0.num+aun.num来获得该事件组的请求事件的总数量。71.在本公开的实施例中，过去的时间段t可以优选地为59秒(59s)，m优选地为59个，则每个子时间段的时间长度均为1s，并且当前数据a0涉及的当前时间段的长度也为1s。也就是说，在该优选示例中，针对每个事件组，利用该事件组一分钟内(即过去的59s和当前1s)内的已被响应的请求事件的数据以及未被响应的数据来计算该事件组的请求事件的各项指标。72.按照每秒钟作为一个子时间段来进行统计计算，可以实现在时间每前进一秒的时候，把过时的历史数据清出统计序列中而无须进行全局数据的更新，同时把新一秒的当前数据加入到历史数据中，形成在一秒以内较为稳定的近期指标统计结果。73.另外，在每一秒的子时间段内只统计每个事件组的请求事件的总耗时和请求事件的数量，而不是直接统计平均耗时，这样做的好处是，需要计算平均耗时的时候，直接使用总耗时和数量相除即可获得，可以反映该事件组的请求事件在这这一子时间段内的平均耗时指标如何。另一方面，在新增请求事件的数据的时候，可以直接把请求事件的耗时和请求事件的数量通过非阻塞线程同步计算的方式(compareandset)以几乎无损耗的方式叠加到已有数据上，而不像在线程安全的情况下更新平均耗时那样复杂。例如，在新增请求事件的数据的时候，将新增请求事件的耗时通过compareandset叠加到当前数据的总耗时a0.csm上，并给当前数据的请求事件的数量a0.num加1，即可通过非常有限步骤的数据运算在几乎无时间损耗的情况下完成新增请求事件的数据记录。74.compareandset，是在多线程编程中常用的一种高效的线程数据同步方法，传统多线程数据同步的时候会先对目标进行锁定然后进行数据同步，因此在同步的时间段内只能有一个线程进行数据同步，效率较低；compareandset方法则是先记录同步前的数值，然后直接进行数据同步，在更新同步结果的时候对比一下数值有没有改变，如果没有改变则进行更新，否则重复操作同步流程，这种方法把需要锁定目标的时间几乎缩减为0，效率较高。75.利用上述数据结构进行的请求事件分类、指标计算操作，在每次需要使用指标来分析数据的时候，只要把历史数据与实时变动的当前数据进行综合计算，即可在几乎无性能损耗的情况下获得总耗时、平均耗时、请求事件的总数量等关键指标。不难看出，通过这个数据结构，可以把所有关键操作都分解为几乎无时间损耗的高效操作，这也是高效实时地对每个事件组进行分析的关键之一。76.返回参考图5，继续方法500，在操作m502a中，判断该事件组的请求事件的平均耗时是否超过所有事件组的请求事件的平均耗时。其中，所有事件组的请求事件的平均耗时，可以通过执行来获得，其中，b表示另一事件组的相应数据。以优选示例为例，可以通过将过去一分钟内所有事件组的已响应/未响应的请求事件的总耗时的累加除以所有事件组的已响应/未响应的请求事件的总数量的累加，来获得所有事件组的请求事件的平均耗时。在其他实施例中，针对每个事件组，可以判断该事件组的请求事件的平均耗时处于所有事件组的平均耗时的什么位置中，例如是否超过中位数所在位置。77.在操作m502b中，判断该事件组的请求事件的总数量占所有事件组的请求事件的总数量是否超过预定比例。其中，所有事件组的请求事件的总数量可以通过执行∑i∈{a,b,..}(i.num+i0.num+iun.num)来获得。在一些实施例中，预定比例可以为80％，表征该类型的请求事件占比超过80％，视为影响系统性能，有可能是大规模攻击或其他过于频繁的请求。78.在操作m502c中，判断该事件组的请求事件的并发处理数是否超过第二阈值。系统针对每个事件组，根据平均耗时等指标，有对应的并发处理数限制。sql请求事件按分类把任一事件组的并发处理数限制在1000以内，并且根据平均耗时的增加逐渐控制到并发处理数为1以内。例如，平均耗时超过5秒的请求事件最多只能并发处理1条sql语句，视为相当消耗资源的sql类型。79.若针对某事件组，操作m502a-c中任一个判定为是，则在操作m503中，将该事件组标记为存在指标满足预定规则。80.下面参考图6描述方法300、400中利用当前数据更新历史数据的操作。方法300、400还包括，针对每个事件组，周期性地利用该事件组的所有已被响应的请求事件的当前数据来更新所有已被响应的请求事件的历史数据。参考图6，其中利用当前数据来更新历史数据包括：对于以堆栈形式存储的数据a1,a2,…,am，删除最早的子时间段所包括的数据am，插入当前数据中未被拦截的请求事件的数据a′0，以进行栈的更新；以及执行a.num-am.num+a′0.num，以及a.csm-am.csm+a′0.csm来分别作为用于下一时间段的计算操作的历史数据，其中，a′0.num以及a′0.csm分别是所述事件组的所有已被响应的请求事件的当前数据中未被拦截的请求事件的数量以及总耗时。并且以同样方式更新所有事件组的请求事件的总耗时的累加、所有事件组的请求事件的总数量的累加。81.以m＝59且每个子时间段的时间长度为1s为例，创建一个新的当前时间点的当前数据，替换原有的当前数据；把原有的当前数据a′0压栈入历史数据，排在原有的a1之前作为新的a1；弹出最旧的a59丢弃；把历史数据中的总耗时a.csm和数量a.num分别减去旧的a59的总耗时a59.csm和数量a59.num，并且加上新的a1(即原有的a′0)的总耗时a′0.csm和数量a′0.num，形成新的1秒以内稳定的指标统计结果；同时把新的a1,b1…和旧的a59,b59…的数据增量以同样的方式叠加到所有事件组的总耗时和总请求数量中。82.根据本公开的实施例，通过对监听到的请求事件进行分类，并利用每个类型的请求事件的历史数据和当前数据来计算指标；在系统性能较差时，根据关键指标对部分请求事件进行拦截、销毁，能够自动控制数据库的负载情况。根据本公开的实施例，能够实现高效实时(纳秒级)的指标计算和历史数据的动态更新，使得控制结果能够及时反应到下一阶段的指标计算结果和下一阶段的负载控制机制当中，形成数据库负载控制自治机制的闭环，能够根据当前数据库的负载情况进行负载控制机制的实时自适应调整，使得数据库始终保持较高的数据处理能力。83.图7是示出可以实现根据本公开实施例的系统600的一般硬件环境的示意图。84.在一些实施例中，系统600可以包括至少一个处理器601和存储器602。85.处理器601提供用于数据库负载控制的系统600的各种功能。在一些实施例中，处理器601被配置为执行本公开的方法。处理器601可以是诸如微处理器、数字信号处理器、微控制器、多核处理器、专用处理器、用于通信的接口等的任何处理器。处理器601可以运行存储器602中所存储的各种程序指令，以执行相应的操作。86.在一些实施例中，存储器602中存储有可执行指令，这些可执行指令在由处理器601执行时实现本公开的功能。存储器602可以是各种类型的存储器或存储设备中的任何一种。例如，存储器602可以包括安装介质(例如cd-rom、软盘或磁带设备)、随机存取存储器(诸如dram、ddrram、sram、edoram、rambusram等)、非易失性存储器(诸如闪存、磁介质或光学存储装置)、寄存器或其他类似类型的存储器元件等。存储器602还可以包括其他类型的存储器或其组合。在本公开的实施例中，存储器602可以存储程序指令(例如用于执行相应操作的指令)，以便以软件、硬件或软件硬件相结合的方式来实现基于本公开实施例的方法。87.本说明书中公开的所有特征，或公开的所有方法或过程中的步骤，除了互相排斥的特征和/或步骤以外，均可以以任何方式组合。88.本公开可以被实施为系统、方法和/或计算机程序产品。该计算机程序产品可以包括(一个或多个)计算机可读存储介质，其上具有计算机可读程序指令，用于使处理器执行本公开的方面。89.本公开的各方面可以呈现完全硬件实施例、完全软件实施例(包括固件、常驻软件、微代码等)或组合软件和硬件方面的实施例的形式，所有前述的各项在本文中都可以一般性地称为“电路”、“模块”或“系统”。可以使用一个或多个计算机可读存储介质的任何组合。计算机可读存储介质可以是计算机可读信号介质或计算机可读存储介质。90.计算机可读存储介质可以是例如但不限于电子的、磁性的、光学的、电磁的、红外的或半导体系统、装置或设备，或前述的各项的任何适当的组合。计算机可读存储介质的更具体的实例(非穷举列表)将包括以下内容：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或闪存)、光纤、便携式光盘只读存储器(cd-rom)、光存储设备、磁存储设备或前述的各项的任何适当组合。在本文档的上下文中，计算机可读存储介质可以是任何包含或存储由指令执行系统、装置或设备使用或与其结合使用的程序的有形介质。91.本公开在各种实施例、配置和方面中包括基本上如本文描绘和描述的组件、方法、过程、系统和/或装置，包括各种实施例，子组合和其子集。本领域技术人员将理解在理解本公开之后如何制造和使用本文公开的系统和方法。在各种实施例、配置和方面中，本公开包括提供不存在本文未描绘和/或描述的项目的装置和过程，或在本文的各种实施例、配置或方面中，包括不存在可能已经在以前的装置或过程中使用的项目，例如用于提高性能、实现简易性和/或降低实现成本。92.本说明书(包括任何附加权利要求、摘要)中公开的任一特征，除非特别叙述，均可被其他等效或具有类似目的的替代特征加以替换。即，除非特别叙述，每个特征只是一系列等效或类似特征中的一个例子而已。93.此外，虽然对本公开的描述已经包括了对一个或多个实施例、配置或方面的描述，但是某些变型和修改、其他变型、组合和修改也在本公开的范围内，例如，在本领域技术人员理解了本公开之后，这可能在他们的技术和知识范围内。本公开旨在获得权利，该权利应当包括在允许范围内的替代实施例、配置或方面，包括与所要求保护的那些结构、功能、范围或步骤的替代的、可互换的和/或等效的结构、功能、范围或步骤，无论这些替代的、可互换的和/或等效的结构、功能、范围或步骤是否在本文中具体说明。本文不旨在公开地贡献任何可取得专利的技术方案。当前第1页12当前第1页12