CN104408088B - 并发请求的控制方法及装置 - Google Patents

Abstract

本发明公开了一种并发请求的控制方法及装置，涉及互联网技术领域，为解决因并发数限制导致的部分访问请求被拒的问题而发明。本发明的方法包括：当访问请求的实际并发数达到预设的并发数上限时，对超出部分的访问请求进行缓存；定期查询当前的实际并发数；若所述当前的实际并发数小于所述并发数上限，则加入所述缓存的访问请求以进行处理。本发明主要应用于SQL数据库系统中。

Description

并发请求的控制方法及装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种并发请求的控制方法及装置。

背景技术

在PostgresQL、MySQL等数据库系统中，客户端访问数据库的请求由介于客户端与数据库服务器之间的应用服务器代为转发。应用服务器将客户端发送的访问请求发送给数据库服务器，接收并向客户端下发数据库服务器返回的数据内容。

通常，网内客户端的访问请求是随机发起的，当同时发起访问请求的客户端过多时(例如同时发起500个请求)，数据库负荷较重，容易发生崩溃。因此，对访问请求数量进行合理控制就成为保障数据库运行效率的一种必然手段。

目前，实际应用中主要通过设置并发数上限的方式对客户端的访问请求进行限制。在数据库系统启动运行时，网络侧加载人工设定的并发数上限(例如180)，当同一时刻上访问请求的并发数超过并发数上限时，应用服务器对超出部分的访问请求予以拒绝。这种方式虽然可以对数据库负荷进行有效调节，但是访问请求被拒的客户端将无法获得请求的数据内容。

发明内容

鉴于上述问题，本发明提供了一种并发请求的控制方法及装置，能够解决现有技术中因并发数限制导致的部分访问请求被拒的问题。

为解决上述技术问题，一方面，本发明提供了一种并发请求的控制方法，包括：

当访问请求的实际并发数达到预设的并发数上限时，对超出部分的访问请求进行缓存；

定期查询当前的实际并发数；

若所述当前的实际并发数小于所述并发数上限，则加入所述缓存的访问请求以进行处理。

另一方面，本发明还提供了一种并发请求的控制装置，包括：

存储单元，用于当访问请求的实际并发数达到预设的并发数上限时，对超出部分的访问请求进行缓存；

查询单元，用于定期查询当前的实际并发数；

处理单元，用于当所述查询单元查询所述当前的实际并发数小于所述并发数上限时，加入所述存储单元缓存的访问请求以进行处理。

借由上述技术方案，本发明提供的并发请求的控制方法及装置，能够对超出并发数上限的访问请求进行缓存，当并发数空闲时，将缓存的访问请求发送给数据库服务器进行处理。与现有技术中拒绝超出部分的访问请求相比，本发明能够将并行处理的大量访问请求分解到时序上进行串行处理，从而保障每个客户端的数据访问权利。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例中一种并发请求的控制方法的流程图；

图2示出了本发明实施例中SQL语句列表的示意图；

图3示出了本发明实施例中另一种并发请求的控制方法的流程图；

图4示出了本发明实施例中访问请求随机抢占的示意图；

图5示出了本发明实施例中随机选取访问请求的示意图；

图6示出了本发明实施例中又一种并发请求的控制方法的流程图；

图7示出了本发明实施例中不同类型队列的示意图；

图8示出了本发明实施例中一种并发请求的控制装置的结构示意图；

图9示出了本发明实施例中另一种并发请求的控制装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为防止超出并发数上限的访问请求被拒绝，本发明实施例提供了一种并发请求的控制方法，如图1所示，该方法包括：

101、当访问请求的实际并发数达到预设的并发数上限时，服务器对超出部分的访问请求进行缓存。

本方法的执行主体为应用服务器，后续简称服务器。在客户端访问数据库的过程中，服务器查询当前时刻上的同时处理的访问请求数量，获得实际并发数。当实际并发数达到预设的并发数上限时，表明数据库的处理能力已达到饱和，此时服务器对超出部分的访问请求进行本地缓存。

示例性的，假设预设的并发数上限为180，即同一时刻上数据库最多允许对不超过180条访问请求同时进行访问。当某一时刻上同时发起的访问请求为210条时，服务器将其中的180条访问请求转发给数据库进行响应，而对于剩下的30条访问请求，服务器将其保存在本地缓存中。

本实施例中所谓的数据库处理能力饱和主要是指数据库为处理访问请求分配的处理资源(例如缓存)已被用满。通常数据库除响应访问请求外还具有数据读写、数据分析等其他功能，在分配处理资源时一般不会将数据库的所有处理资源都分配给响应访问请求之用，因此本实施例中所指的处理能力饱和程度并不是真正意义上能够使数据库瘫痪的饱和程度。

本实施例中，在客户端访问数据库之前，服务器需要首先开辟出专用于保存访问请求的缓存空间。服务器可以在内存中开辟该缓存空间，也可以在硬盘中开辟该缓存空间，本实施例对此不作限制。此外，缓存空间的大小可以由网管人员根据经验值设定，也可以由服务器根据对局域网内的日常请求数量或请求语句大小的统计结果，自行设定得出，本实施例对此同样不做限制。

在缓存超出部分的访问请求时，服务器可以依据不同的算法对超出部分的访问请求进行选取。一种可行的实现方式为，服务器从当前的访问请求中随机选取并发数上限数量的访问请求进行处理，例如从210条访问请求中随机选择180条访问请求进行处理，并对剩余30条访问请求进行缓存。或者，服务器也可以根据访问请求的优先级高低、语句长度或请求的数据类型对所有访问请求进行排序，并从排序后的访问请求中选取并发数上限数量的访问请求进行处理。本实施例不对服务器选取访问请求的规则进行限定。

实际应用中，各个客户端上报访问请求的时间点通常是随机的，鲜有大量客户端同时上报访问请求的情况，因此更加适用于实际的请求选取方式为：服务器在接收到某条访问请求时，只要当前的实际并发数未达到并发数上限，服务器就对接收的访问请求进行处理，而当当前的实际并发数达到并发数上限时，服务器对接收的访问请求进行缓存，即服务器按照发起先后顺序对访问请求进行处理缓存。

需要说明的是，服务器接收到的访问请求是由不同客户端上报而来的，通常同一时刻上的一个客户端只上报一条访问请求，但实际应用中也不排除客户端启动多线程同时上报多个访问请求的情况，因此本实施例中访问请求与客户端之间的关系并非一定为一一映射。

102、服务器定期查询当前的实际并发数。

在对超出部分的访问请求进行缓存后，服务器定期查询当前的实际并发数。由于在执行完步骤101后实际并发数已达到并发数上限，服务器无法及时对超出部分的访问请求进行加入处理，因此服务器需要定期对并发数的“饱和状态”进行检查，即定期查询当前的实际并发数。如果当前的实际并发数仍等于并发数上限，则服务器重复执行步骤102，在下一时刻继续进行查询，如果当前的实际并发数小于并发数上限(例如因某些访问请求响应完毕或响应失败而释放对应的处理资源)，则服务器执行步骤103，利用释放的处理资源对缓存的访问请求进行处理。

本实施例中所谓的定期查询可以有不同的实现方式，例如服务器按照预设的时间间隔周期性查询，或者根据网管人员下发的查询指令进行查询，或者在缓存的访问请求数量超过一定阈值时进行查询等。其中，对于周期性查询的方式而言，本实施例并不对具体的时间间隔进行限制，当该时间间隔被设置为趋近于0时，服务器可以实现对实际并发数的实时查询。

103、若当前的实际并发数小于并发数上限，则服务器加入缓存的访问请求以进行处理。

若步骤102中查询的实际并发数小于并发数上限，则表明本次查询时数据库释放了部分处理资源，因此服务器执行步骤103，从缓存中选取保存的访问请求进行处理。在从缓存中选取访问请求后，服务器将其从缓存中清除。

在选取缓存的访问请求时，服务器可以根据释放的处理资源大小选取部分或全部访问请求进行处理。通常，数据库在处理完一条访问请求后，会立即释放该访问请求占用的处理资源，处理完的访问请求越多释放的处理资源也越多。因此从本质上讲，服务器从缓存中选取的访问请求数量由服务器查询实际并发数的间隔时间长短决定，间隔时间越长，数据库释放的处理资源越多，服务器从缓存中选取的访问请求数量也就越多。

与步骤101类似的，在从缓存中选取访问请求时，服务器也可以采用随机选取或排序选取的方式进行实现，本步骤对此不再进行赘述。

在执行完本步骤之后，服务器重复执行步骤102及步骤103，对缓存中的剩余访问请求先后进行处理，直至缓存中未再保存任何访问请求为止。

实际应用中，服务器在执行上述步骤101至步骤103时，局域网内的客户端还会不断上报新的访问请求。对于此种情况，服务器将新接收的访问请求直接保存到缓存中等待后续处理。

本实施例中处理访问请求的过程涉及：将访问请求转发给数据库，由数据库对该请求进行响应，查找其所请求的数据内容，接收并向客户端下发数据库返回的数据内容等。

本实施例提供的并发请求的控制方法，能够对超出并发数上限的访问请求进行缓存，当并发数空闲时，将缓存的访问请求发送给数据库服务器进行处理。与现有技术中拒绝超出部分的访问请求相比，本实施例能够将并行处理的大量访问请求分解到时序上进行串行处理，从而保障每个客户端的数据访问权利。

进一步的，作为图1所示方法的一种实现方式，在本发明的另一实施例中，上述步骤101至步骤103的执行可以由应用服务器上的ngx模块(ngx_lua_module)完成。ngx模块中内嵌有lua解析器，支持高并发数、高性能、支持非阻塞的数据库操作，可以用于Windows系统或Linux系统中。

在接收到客户端上报的访问请求后，ngx模块为每个访问请求分别建立一个协程，后续对请求的缓存及处理均基于协程进行。与现有技术中通过线程发起访问请求不同的是，本实施例中采用协程发起访问请求，相对线程而言，协程只涉及一个主进程，没有额外的线程，不会像线程一样占用服务器或数据库的CPU资源，因此本实施例相对现有技术而言，不会因并发数的增加而影响到数据库的处理效率。

进一步的，作为对图1步骤102的细化，在本发明的另一实施例中，服务器可以通过不同的方式实现对当前实际并发数的查询，具体的：

方式一

通过请求列表查询

在对访问请求进行处理时，服务器会将访问请求的语句写入到请求列表中，当该访问请求处理完毕后，将该请求对应的语句从请求列表中清除。因此服务器可以定期对请求列表中的语句数量进行统计，通过请求列表中记录的语句数量获得当前的实际并发数。

实际应用中，不同数据库的请求语句通常不同，以PostgresQL或MySQL数据库使用的SQL语句为例，服务器记录的请求列表可以如图2所示。需要说明的是，图2仅用于对一种可能的实现方式进行说明，其中的格式或具体参数均为示例性的，不作为对请求列表实际形式的限定。

方式二

通过计数器查询

服务器可以为访问请求的处理增加一个计数器，该计数器用于在实际并发数发生变化时进行增减计数。当一个新的访问请求被加入处理时，该计数器加1，当一个访问请求处理完成时，该计数器减1。服务器可以通过对计数器的定期读取，获得当前的实际并发数。

下面，本发明将通过其他几个实施例对图1中步骤103进行说明。

在本发明的一个实施例中，当数据库释放处理资源时，服务器可以通过随机抢占的方式将缓存的访问请求加入处理。如图3所示，该方案包括：

301、服务器为每个缓存的访问请求独立查询当前的实际并发数。

作为对图1步骤102的细化，服务器为缓存的每一个访问请求分别单独进行定期查询。如前所述，服务器为每一个访问请求都单独建立一个协程，本步骤中服务器即是基于各个访问请求的协程实现查询的，因此，实际并发数的查询是以访问请求为单位独立进行的。示例性的，假设服务器缓存有12条访问请求，那么服务器每次需要分别进行12次查询。

对于周期性查询的方式，服务器可以针对不同的访问请求采用不同的时间间隔，也可以针对所有的访问请求采用统一的时间间隔。本实施例中查询时间间隔的取值范围可以为1ms至100ms，其中，较为典型的取值包括：5ms、10ms、30ms、50ms、90ms等。

需要说明的是，对于不同的访问请求，虽然服务器按照相同的时间间隔查询，但是每个访问请求的查询时间点并不一定相同，这是由于：不同客户端上报访问请求的时间是随机的，因此服务器接收不同访问请求的时间点也是随机的，由此各条访问请求起始查询的时间点就会有所不同。

302、当当前的实际并发数小于并发数上限时，服务器加入最先查询实际并发数的访问请求。

如前所述，每条访问请求的查询时间点是随机确定的，因此在数据库释放处理资源后，服务器将最先进行查询的访问请求进行加入处理。采用这种实现方式加入的访问请求完全是随机的，因此这种方式也称为随机抢占。实际应用中随机抢占的加入方式无需建立队列，相应的，也就无需为队列分配缓存和计数器等资源，因此实现起来较为简单。

举例进行说明，如图4所示，服务器按照50ms秒的时间间隔对2条访问请求进行抢占处理。在以0ms为起点的时间轴上，请求1分别在第0ms、第50ms、第100ms、第150ms、第200ms上进行查询，请求2则分别在第20ms、第70ms、第120ms、第170ms、第220ms上进行查询。如果数据库在第95ms释放一条请求，则在此之后最先进行查询的是请求1(第100ms查询)，因此服务器对请求1进行加入处理。而如果数据库在第160ms释放一条请求，则服务器对请求2(第170ms查询)进行加入处理。

需要说明的是，上述示例仅以数据库释放一条请求为例进行的说明，这种情况下服务器随机抢占的机会为一条请求。而在实际应中，数据库可能在几乎相同的时刻上对多条请求进行处理，如果这多条请求的处理时长相近，那么服务器可能会在几乎相同的时刻上释放多条请求。这种情况下缓存中会有多条访问请求“抢占”成功。例如在图4所示示例中，如果数据在第95ms释放了2条请求，那么分别在第100ms和第120ms进行查询的请求1及请求2均可以被加入处理。但需要注意的是，2条请求虽然都被服务器加入处理，但是两者的起始处理时间仍由各自的查询时刻决定，即请求1在第100ms被加入处理，而请求2则是在第120ms被加入处理。

同样作为对图1步骤103的说明，在本发明的另一实施例中，当数据库释放处理资源时，服务器还可以通过随机选取的方式将缓存的访问请求加入处理。具体的，当当前的实际并发数小于并发数上限时，服务器加入从缓存的访问请求中随机选取出的访问请求。例如，如图5所示，当数据库释放了4条请求时，服务器在对实际并发数进行查询后，可以在缓存的15条访问请求中随机选取请求2、请求5、请求9及请求13进行处理。

实际应用中，服务器可以采用诸如哈希(Hash)算法等规则实现访问请求的选取，或者服务器也可以对排序后的访问请求进行抽样选取，例如“逢五抽一”或“逢时抽一”等，本实施例不对服务器采用的随机算法进行限制。

与上述实施例类似的，本实施例中服务器定期查询的时间间隔也可被设置为1ms至100ms中的任一数值，其中，较为典型的取值包括：5ms、10ms、30ms、50ms、90ms等。但是与上述实施例不同的是，本实施例中，服务器不再针对访问请求进行查询，而是进行统一查询。例如，在上述实施例中，对于12条访问请求而言，服务器需要一次性进行12次查询操作(当然并非一定是在同一时刻上完成)；而在本实施例中，无论缓存了多少条访问请求，服务器在每次时间间隔到达时仅进行1次查询操作。

同样作为对图1步骤103的说明，在本发明的再一实施例中，当数据库释放处理资源时，服务器还可以根据访问请求的排序对访问请求进行顺次选取。具体的，如图6所示，该方案包括：

601、对缓存的访问请求进行排队。

本实施例中，服务器选取访问请求的基础在于，缓存的访问请求能够以一定的规则进行排序。因此与前述实施例不同的是，本实施例中服务器首先需要按照一定的排序规则对访问请求进行排序。

在本实施例的一种实现方式中，服务器可以按照访问请求优先级由高到低的顺序对缓存的访问请求进行排序，或者也可以按照请求语句由长到短的顺序对缓存的访问请求进行排序，再或者，服务器还可以按照缓存的先后顺序对缓存的访问请求进行排序。本实施例不对服务器采用的排序规则进行具体限制。

在进行排序时，服务器在内存中开辟一块缓存空间，建立一个足够长的队列(当然也可以建立多个队列)，在对缓存的访问请求做好排序后，服务器按照排序结果对访问请求顺序进行入队。

602、当当前的实际并发数小于并发数上限时，加入缓存队列队首的访问请求。

当数据库释放请求对应处理资源时，服务器从队列的队首开始，顺次选择一条或多条访问请求(由数据库释放的处理资源大小决定)进行处理。

当有新的访问请求上报时，服务器可以采用两种方式将其加入队列：第一种，服务器对包括新请求在内的所有请求重新进行排序，获得新的请求队列。第二种，服务器不再进行二次排序，直接将新请求加入到队尾(本质相当于按照请求先后顺序进行排序)。

可选的，在本实施例的另一种实现方式中，服务器还可以从不同的维度对缓存的访问请求分别进行分类，并针对每种分类分别进行排队。例如，对于7条数据请求而言，服务器从“优先级”、“语句长度”以及“请求发起顺序”3个维度对7条访问请求独立进行排序，得到如图7所示的3条队列。

在进行实际并发数查询时，服务器按照前述“随机抢占”的方式分别为3条队列发起查询，当数据库释放一条请求时，服务器对最先抢占到的队列的队首请求加入进行处理操作。需要说明的是，由于3条队列是对同一批访问请求在不同纬度上的分类，因此为避免不同队列对同一访问请求的重复处理，在某条队列中的某个访问请求出队进行处理后，服务器需要删除其他队列中的相同访问请求。例如在如7中，当队列1中的访问请求5出队进行处理时，服务器需要分别删除队列2和队列3中的访问请求5。

进一步的，作为与上述各实施例的结合，在本发明的另一实施例中，服务器还可以对访问请求的缓存时间进行限制。实际应用中，如果访问请求缓存时间过长，则客户端侧请求响应的时间也会相应延长，过长的响应时间会降低客户端侧的服务质量(Quality ofService，简称QoS)。同时，访问请求缓存过久也会对服务器有限的内存空间造成过度占用，增加服务器的负荷。因此在缓存超过一定时间后，对访问请求进行及时处理，对于服务器的稳定运行就显得至关重要。在本实施例中，服务器可以预先获取设定的计时时长，在对访问请求进行缓存后，服务器启动对访问请求的计时。若访问请求在计时超时前得到处理，则服务器从缓存清除该访问请求，并对计时器进行清零。若访问请求在计时超时时仍未得到处理，则服务器直接对缓存的访问请求进行清除，其作用相当于现有技术中的请求被拒，同时，服务器通知客户端数据请求失败。

需要说明的是，本方案是以客户端侧的响应时长为首要因素进行的设计，而当首要因素发生改变时，服务器也可以对应改变相应的策略。例如，当首要因素改变为访问请求的成功率时，服务器可以在计时超时时，对访问请求进行计时清零，使其重新进行计时，由此保证访问请求在得到处理前不会被清除出缓存。当然，针对后者实现方式而言，更为简便的做法可以是直接取消对访问请求的计时。

此外，当缓存的访问请求加入失败时，服务器也可以对缓存的访问请求进行计时清零，以保证缓存的剩余访问请求有足够长的时间等待处理。本方式是针对访问请求加入失败时进行的计时清零，例如在随机抢占失败时，服务器对缓存中剩余的访问请求进行计时清零。与上述计时超时清零不同，服务器在对请求进行计时清零时，访问请求的计时尚未超时。

实际应用中，上述计时时长的设定范围可以是1s至10s，其中较为典型的设定包括3s、5s及8s。

进一步的，作为与上述各实施例的结合，在本发明的另一实施例中，服务器还可以对并发数上限进行设置。现有技术中的并发数上限通常时固定的，当并发数上限过大时，服务器与数据库的资源占用过多，会降低系统的运行效率；当并发数上限过小时，无法满足网络的业务需求，数据请求的失败率会大大增加。而在本实施例中，服务器可以根据不同的参数获得合适的并发数上限，由此在保证系统运行效率的基础上降低请求访问的失败率。

在本实施例的一种实现方式中，服务器可以根据后端的处理参数设置并发数上限。本实现方式中的后端主要是指数据库服务器，其处理参数包括但不限于是：CPU占例、内存占例、内存大小、网卡速度、硬盘速度、硬盘大小、网络带宽、CPU缓存大小及CPU寄存器宽度。当数据库的处理负荷较大(例如内存占例过高或CPU寄存器宽度较小)时，可以适当调小并发数上限。

在本实施例的另一种实现方式中，服务器还可以根后端处理访问请求的时长设置并发数上限。数据库响应访问请求的时间长短也可以反映数据库的负荷大小(或处理能力大小)。当数据库响应请求的时长过长时，服务器可以适当调小并发数上限。

实际应用中，可以根据随机抽样出的访问请求的响应时长设定并发数上限，也可以对多个访问请求的响应时长取平均值，并据此均值设定并发数上限。

在本实施例的另一种实现方式中，服务器还可以根据后端的缓存大小及访问请求的语句长度设置并发数上限。通常数据库会为访问请求的响应分配一定的缓存空间，而不同语句长度的访问请求会占用不同大小的缓存空间，因此，服务器可以据此计算出并发数上限。示例性的，若数据库分配的缓存大小为32M、每条访问请求的语句长度均为500K，则服务器设置的并发数上限为32M/500K＝64。当然，实际应用中，为使数据库缓存保持一定冗余，设定的并发数上限也可以稍少于64。

通常，客户端上报访问请求的语句长短不尽相同，从几K到几百M不等。因此在设置并发数上限时，服务器可以采用较为典型的语句长度进行计算，例如绝大多数访问请求的语句长度处于百K级别，因此可以采用该级别长度数值进行计算；或者，服务器也可以对一段时间内处理过的访问请求进行统计，获得其语句长度的平均值，参与上述计算。

以上几种实现方式仅作为对设置并发数上限的示例性说明，实际应用中，服务器还可以但不限于根据网络中的客户端数量或其他具体参数设置并发数上限，本实施例对此不作限制。

此外，在设置并发数上限的时机上，服务器可以在系统启动运行时对并发数上限进行初始化设置，也可以在系统运行过程中对并发数上限进行动态设置，本实施例对此同样不作限制。

本实施例提供的用于设置并发数上限的方案，能够根据网络的实际参数对并发数上限进行设定，在保证满足客户端业务需求的同时尽量减小数据库的负荷。并且，与现有技术中并发数上限过大相比，本实施例由于降低了并发数上限，因此能够节省数据库的处理资源，缩短数据库响应访问请求的时间，进而在并发数上限降低的情况下提高系统处理访问请求的吞吐量。

进一步的，作为对上述各方法实施例的实现，本发明另一实施例还提供了一种并发请求的控制装置。如图8所示，该装置包括：存储单元81、查询单元82以及处理单元83，其中，

存储单元81，用于当访问请求的实际并发数达到预设的并发数上限时，对超出部分的访问请求进行缓存；

查询单元82，用于定期查询当前的实际并发数；

处理单元83，用于当查询单元82查询当前的实际并发数小于并发数上限时，加入存储单元81缓存的访问请求以进行处理。

进一步的，如图9所示，该装置还包括：

建立单元84，用于在存储单元81对超出部分的访问请求进行缓存之前，为每个访问请求独立建立协程。

进一步的，如图9所示，查询单元82包括：

第一查询模块821，用于定期对请求列表中的语句数量进行统计，请求列表用于记录当前正在处理的访问请求。

进一步的，如图9所示，查询单元82包括：

第二查询模块822，用于定期读取当前计数器中记录的实际并发数，计数器用于在实际并发数发生变化时进行增减计数。

进一步的，如图9所示，处理单元83，包括：第一处理模块831；

查询单元82，用于为每个缓存的访问请求独立查询当前的实际并发数；

第一处理模块831，用于当当前的实际并发数小于并发数上限时，加入最先查询实际并发数的访问请求。

进一步的，如图9所示，处理单元83，包括：

第二处理模块832，用于当当前的实际并发数小于并发数上限时，加入从缓存的访问请求中随机选取出的访问请求。

进一步的，如图9所示，处理单元83，包括：

第三处理模块833，用于对缓存的访问请求进行排队，当当前的实际并发数小于并发数上限时，加入缓存队列队首的访问请求。

进一步的，如图9所示，该装置还包括：

计时单元85，用于在存储单元81对超出部分的访问请求进行缓存之后，启动对存储单元81缓存的访问请求的计时；

存储单元81，还用于当计时单元85检测到缓存的访问请求的计时超时时，清除缓存的访问请求。

进一步的，计时单元85，用于当处理单元83对缓存的访问请求加入失败时，对存储单元81缓存的访问请求进行计时清零。

进一步的，如图9所示，该装置还包括：

设置单元86，用于设置并发数上限。

进一步的，如图9所示，设置单元86，包括：

第一设置模块861，用于根据后端的处理参数设置并发数上限；

第二设置模块862，用于根据后端处理访问请求的时长设置并发数上限；

第三设置模块863，用于根据后端的缓存大小及访问请求的语句长度设置并发数上限。

进一步的设置单元86，用于在系统启动运行时，对并发数上限进行初始化设置；

设置单元86，还用于在系统运行过程中，对并发数上限进行动态设置。

本实施例提供的并发请求的控制装置，能够对超出并发数上限的访问请求进行缓存，当并发数空闲时，将缓存的访问请求发送给数据库服务器进行处理。与现有技术中拒绝超出部分的访问请求相比，本实施例提供的并发请求的控制装置能够将并行处理的大量访问请求分解到时序上进行串行处理，从而保障每个客户端的数据访问权利。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (20)

1.一种并发请求的控制方法，其特征在于，所述方法包括：

当访问请求的实际并发数达到预设的并发数上限时，对超出部分的访问请求进行缓存，其中，所述预设的并发数上限是在系统运行过程中动态设置的并发数上限；

定期查询当前的实际并发数，至少可以包括：定期读取当前计数器中记录的实际并发数，所述计数器用于在所述实际并发数发生变化时进行增减计数；

若所述当前的实际并发数小于所述并发数上限，则加入所述缓存的访问请求以进行处理，包括：

从不同的维度对缓存的访问请求进行分类，并对每个维度对应的访问请求进行排序得到对应的请求队列；

为多个所述请求队列分别发起查询当前的实际并发数的操作；

当所述当前的实际并发数小于所述并发数上限时，根据随机抢占原则加入最先查询实际并发数的所述请求队列内的队首请求；

当所述队首请求出队进行处理之后，删除其他队列中与所述队首请求相同的访问请求。

2.根据权利要求1所述的方法，其特征在于，在所述对超出部分的访问请求进行缓存之前，所述方法进一步包括：

为每个访问请求独立建立协程。

3.根据权利要求1所述的方法，其特征在于，所述定期查询当前的实际并发数，包括：

定期对请求列表中的语句数量进行统计，所述请求列表用于记录当前正在处理的访问请求。

4.根据权利要求1或3所述的方法，其特征在于，所述加入所述缓存的访问请求以进行处理，包括：

当所述当前的实际并发数小于所述并发数上限时，加入从所述缓存的访问请求中随机选取出的访问请求。

5.根据权利要求1或3所述的方法，其特征在于，所述加入所述缓存的访问请求以进行处理，包括：

对所述缓存的访问请求进行排队；

当所述当前的实际并发数小于所述并发数上限时，加入所述缓存队列队首的访问请求。

6.根据权利要求1所述的方法，其特征在于，在所述对超出部分的访问请求进行缓存之后，所述方法进一步包括：

启动对所述缓存的访问请求的计时；

当所述缓存的访问请求的计时超时时，清除所述缓存的访问请求。

7.根据权利要求6所述的方法，其特征在于，当所述缓存的访问请求加入失败时，所述方法进一步包括：

对所述缓存的访问请求进行计时清零。

8.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

设置所述并发数上限。

9.根据权利要求8所述的方法，其特征在于，所述设置所述并发数上限，包括：

根据后端的处理参数设置所述并发数上限；

或者，根据后端处理访问请求的时长设置所述并发数上限；

或者，根据后端的缓存大小及访问请求的语句长度设置所述并发数上限。

10.根据权利要求8或9所述的方法，其特征在于，所述设置所述并发数上限，包括：

在系统启动运行时，对所述并发数上限进行初始化设置；

或者，在系统运行过程中，对所述并发数上限进行动态设置。

11.一种并发请求的控制装置，其特征在于，所述装置包括：

存储单元，用于当访问请求的实际并发数达到预设的并发数上限时，对超出部分的访问请求进行缓存，其中，所述预设的并发数上限是在系统运行过程中动态设置的并发数上限；

查询单元，用于定期查询当前的实际并发数；

所述查询单元，包括：第二查询模块，用于定期读取当前计数器中记录的实际并发数，所述计数器用于在所述实际并发数发生变化时进行增减计数；

处理单元，用于当所述查询单元查询所述当前的实际并发数小于所述并发数上限时，加入所述存储单元缓存的访问请求以进行处理，包括：从不同的维度对缓存的访问请求进行分类，并对每个维度对应的访问请求进行排序得到对应的请求队列，为多个所述请求队列分别发起查询当前的实际并发数的操作，当所述当前的实际并发数小于所述并发数上限时，根据随机抢占原则加入最先查询实际并发数的所述请求队列内的队首请求，当所述队首请求出队进行处理之后，删除其他队列中与所述队首请求相同的访问请求。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

建立单元，用于在所述存储单元对超出部分的访问请求进行缓存之前，为每个访问请求独立建立协程。

13.根据权利要求11所述的装置，其特征在于，所述查询单元包括：

第一查询模块，用于定期对请求列表中的语句数量进行统计，所述请求列表用于记录当前正在处理的访问请求。

14.根据权利要求11或13所述的装置，其特征在于，所述处理单元，包括：

第二处理模块，用于当所述当前的实际并发数小于所述并发数上限时，加入从所述缓存的访问请求中随机选取出的访问请求。

15.根据权利要求11或13所述的装置，其特征在于，所述处理单元，包括：

第三处理模块，用于对所述缓存的访问请求进行排队，当所述当前的实际并发数小于所述并发数上限时，加入所述缓存队列队首的访问请求。

16.根据权利要求11所述的装置，其特征在于，所述装置还包括：

计时单元，用于在所述存储单元对超出部分的访问请求进行缓存之后，启动对所述存储单元缓存的访问请求的计时；

所述存储单元，还用于当所述计时单元检测到所述缓存的访问请求的计时超时时，清除所述缓存的访问请求。

17.根据权利要求16所述的装置，其特征在于，所述计时单元，用于当所述处理单元对所述缓存的访问请求加入失败时，对所述存储单元缓存的访问请求进行计时清零。

18.根据权利要求11所述的装置，其特征在于，所述装置还包括：

设置单元，用于设置所述并发数上限。

19.根据权利要求18所述的装置，其特征在于，所述设置单元，包括：

第一设置模块，用于根据后端的处理参数设置所述并发数上限；

第二设置模块，用于根据后端处理访问请求的时长设置所述并发数上限；

第三设置模块，用于根据后端的缓存大小及访问请求的语句长度设置所述并发数上限。

20.根据权利要求18或19所述的装置，其特征在于：

所述设置单元，用于在系统启动运行时，对所述并发数上限进行初始化设置；

所述设置单元，还用于在系统运行过程中，对所述并发数上限进行动态设置。

Images