CN104331461B - 语句长度的控制方法及装置 - Google Patents

Abstract

本发明公开了一种语句长度的控制方法及装置，涉及互联网技术领域，为解决较长语句请求被拒的问题而发明。本发明的方法包括：在接收到访问请求后，检测所述访问请求的语句长度及剩余缓存大小；判断所述剩余缓存大小是否小于所述语句长度；若所述剩余缓存大小不小于所述语句长度，则对所述访问请求进行处理。本发明主要应用于SQL数据库系统中。

Description

语句长度的控制方法及装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种语句长度的控制方法及装置。

背景技术

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

通常，为了限制同时发起的访问请求数量，应用服务器会对请求的并发数进行设定。设定并发数的方式一般为：确定一个固定的语句长度，根据缓存空间的大小以及固定的语句长度计算允许同时进行处理的访问请求数量，获得请求并发数。

在实际应用中，访问请求的语句长度从几Kb到几Mb不等，上述根据固定语句长度获得并发数的方式会导致长度超过固定语句长度的访问请求被拒，无法得到处理。而如果按照访问请求的语句长度上限设定固定语句长度，则又会造成较为严重的缓存浪费。例如，如果按照2Mb的固定语句长度设定请求并发数，那么对于32Mb的缓存空间而言，服务器能够同时处理的请求数量为16条，当网内请求的长度大多为几十Kb时，受请求并发数的限制，会有大量的缓存空间空闲，无法处理其他的访问请求。

随着数据库功能的不断提升，实际应用中几十Mb甚至上百Mb的访问请求越来越常见，在现有控制语句长度的方式中，这些访问请求很容易被较短的语句长度所限制，无法满足客户端的业务需求。

发明内容

鉴于上述问题，本发明提供了一种语句长度的控制方法及装置，能够解决较长语句请求被拒的问题。

为解决上述技术问题，一方面，本发明提供了一种语句长度的控制方法，包括：

在接收到访问请求后，检测访问请求的语句长度及剩余缓存大小；

判断剩余缓存大小是否小于语句长度；

若剩余缓存大小不小于语句长度，则对访问请求进行处理。

另一方面，本发明还提供了一种语句长度的控制装置，包括：

接收单元，用于接收访问请求；

检测单元，用于检测接收单元接收的访问请求的语句长度及剩余缓存大小；

判断单元，用于判断检测单元检测的剩余缓存大小是否小于语句长度；

处理单元，用于当判断单元判断剩余缓存大小不小于语句长度时，对接收单元接收的访问请求进行处理。

借由上述技术方案，本发明提供的语句长度的控制方法及装置，能够在剩余缓存大小足够处理接收的访问请求时，直接对该访问请求进行处理。与现有技术相比，本发明不对访问请求的语句长度进行限制，只要剩余缓存足够大，就可以对任意长度的访问请求进行处理，能够满足客户端的各种业务需求。

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

附图说明

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

图1示出了本发明实施例中语句长度的控制方法的流程图；

图2示出了本发明实施例中另一种语句长度的控制方法的流程图；

图3示出了本发明实施例中语句长度的示意图；

图4示出了本发明实施例中另一种语句长度的示意图；

图5示出了本发明实施例中又一种语句长度的控制方法的流程图；

图6示出了本发明实施例中语句长度的控制装置的结构示意图；

图7示出了本发明实施例中另一种语句长度的控制装置的结构示意图。

具体实施方式

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

为实现对任意长度请求的及时处理，本发明的一个实施例提供了一种语句长度的控制方法，如图1所示，该方法包括：

101、在接收到访问请求后，服务器检测访问请求的语句长度及剩余缓存大小。

本实施例中，在接收到客户端上报的访问请求后，应用服务器(后续简称服务器)需要检测该请求的长度，同时，作为对缓存空间的占用状态进行检测，还需要获得剩余缓存大小。本实施例不对服务器检测语句长度及剩余缓存大小的执行顺序进行限制，服务器可以先检测访问请求的语句长度，然后再检测剩余缓存大小，或者也可以先检测剩余缓存大小，然后再检测访问请求的语句长度。而在另一种实现方式中，服务器还可以通过不同协程同时完成两项操作的执行。

其中，服务器获得的剩余缓存大小可以是具体的数据量值，例如剩余 32Mb缓存、1.5Gb缓存等，也可以是一个缓存占比，例如缓存占比为26％、 79％等，对应的，服务器可以计算出剩余缓存占比(例如74％、21％)。本实施例不对用于表征剩余缓存大小的具体形式进行限制。但是，对于使用缓存占比的实现方式而言，服务器还需要根据已知的缓存总大小计算得出剩余缓存大小的数据量。

实际应用中，服务器可以通过不同的方式对剩余缓存进行检测。例如，服务器可以在每次接收到访问请求时，对内存进行一次扫描，获得剩余缓存大小的结果；或者服务器也可以单独建立一个进程对内存状态进行实施监听，当接收到访问请求时，服务器直接调取该进程获得剩余缓存大小的结果，本实施例不对服务器检测缓存空间的具体实现方式进行限定。

此外，上述示例是以在内存中开辟缓存为基础实现的，实际应用中当服务器在外部存储区域中(例如磁盘)开辟用于处理访问请求的缓存时，其检测缓存空间的实现方式与上述扫描/监听内存的方式相似，此处不再赘述。

需要说明的是，本实施例中服务器需要单独建立进程(当然也可以建立协程)执行步骤101及步骤102。服务器可以预先在内存中开辟出一块独立与前述缓存的逻辑存储区域以用于运行该进程。与前述缓存空间不同的是，本实施例中所指的逻辑存储区域是按照访问请求的接收顺序依次对不同访问请求进行检测和判断的，无需如前述缓存空间一样并行处理大量的访问请求，因此该逻辑存储区域的划定通常可以小于前述缓存的大小，例如设定为1Mb或3Mb等。当然，考虑到一些情况下服务器可能会同时接收到几条访问请求，在对逻辑存储区域进行划定时也可做适当冗余处理，以使服务器可以分别对多条访问请求同时执行图1所示流程，例如可以将逻辑存储区域设定为5Mb至10Mb。

以上具体数值仅为示例性说明，不作为对实际应用的具体限制。

102、服务器判断剩余缓存大小是否小于语句长度。

在获得请求语句长度以及剩余缓存大小之后，服务器对两者进行比对。本实施例中所指的比对是指对两者数据量大小的比对，若剩余缓存大小小于访问请求的语句长度，则表明当前剩余的缓存空间不足以对该访问请求进行处理，若剩余缓存大小大于或等于访问请求的语句长度，则表明当前剩余的缓存空间可以对该访问请求进行处理，服务器执行步骤103，对接收的访问请求进行处理。

与步骤101相似的，本步骤的执行也是在事先设定好的逻辑存储区域中完成的，服务器在执行步骤101和步骤102时，可以共用一个逻辑存储区域，也可以开辟不同的逻辑存储区域分别对应执行步骤101和步骤102，本实施例对此不做限制。

103、若剩余缓存大小不小于语句长度，则服务器对访问请求进行处理。

服务器将能够处理的访问请求发送给数据库服务器，由数据库服务器根据该请求中携带的关键信息查找对应的数据内容，并通过服务器将查找到的数据内容下发给客户端。

本实施例提供的语句长度的控制方法，能够在剩余缓存大小足够处理接收的访问请求时，直接对该访问请求进行处理。与现有技术相比，本实施例不对访问请求的语句长度进行限制，只要剩余缓存足够大，就可以对任意长度的访问请求进行处理，能够满足客户端的各种业务需求。

进一步的，在对图1所示实施例进行实现时，实际应用中可能会遇到这样的问题：当局域网中的客户端数量较多时(例如1000台甚至更多)，服务器接收访问请求的频率往往较高。如果服务器在每次接收到访问请求时均对请求的语句长度以及缓存空间进行一次检测和判断，那么将会占用服务器大量的处理资源，使得服务器的运行效率降低。为节省服务器执行上述步骤101和步骤102所耗费的处理资源，在本发明的另一实施例中，服务器还可以对接收到的多条访问请求进行批量操作，从而降低服务器执行检测操作及判断操作的频率。具体的，如图2所示，本实施例涉及的方法包括：

201、服务器收集多条访问请求。

本实施例中，服务器可以一次性对多条访问请求进行批量处理，因此该方案所基于的前提为服务器接收多条访问请求。实际应用中，上述多条访问请求可以由不同客户端分别上报得到，也可以由一个客户端先后上报得到，本实施例不对访问请求与客户端之间的对应关系进行限定。

此外，上述多条访问请求可以是服务器在某一时刻上同时接收得到的，也可以是服务器在一段预设时间内先后接收得到的。前者实现方式适用于较大规模的局域网中(例如规模在中上等企业或县级机关单位)，而后者实现方式则更加适用于中小规模的局域网中(例如中小规模企业)。对于后者实现方式而言，在实现过程中，服务器可以按照网管人员设定的、或根据预设策略自行计算获得的时间间隔，周期性收集访问请求，并集中对一段时间间隔内收集的访问请求进行检测和判断。但需要说明的是，由于实际应用中服务器接收访问请求的时间点是 随机的，因此服务器接收访问请求的过程不应当是周期性的。服务器可以保持对访问请求的连续接收，并对接收的访问请求进行缓存，在每到达一段时间间隔的结束时间点时，服务器读取一次缓存的访问请求，即服务器收集一段时间间隔内接收的访问请求。

如前所述，由于服务器是按照一定时间间隔对访问请求进行收集的，因此较早上报的访问请求需要进行一段时间的等待(极端情况下最长等待时间为一个时间间隔的时长)。此种情况下，为保证对客户端请求的及时响应，实际应用中上述收集访问请求的时间间隔不应设置过长。较为适宜的时间间隔可以取值于1s至10s的闭区间中，而其中又以3s、5s、8s的间隔长度为典型时间间隔。

202、服务器对收集的多条访问请求进行语句长度的批量检测。

对于每一批访问请求而言，服务器在进行收集之后对其语句长度进行批量检测。本实施例中所指的批量检测语句长度包含两种实现方式：

1、服务器对每条访问请求的语句长度分别进行检测

2、服务器对所有访问请求的语句总长度进行一次性检测

对于方式1，服务器可以建立多条协程对所有访问请求同时进行长度检测，或者也可以建立少量协程(极端情况为仅建立1条协程)对访问请求先后进行长度检测。无论采用何种检测方式，服务器获得的检测结果数量与访问请求的数量应当都是一致的，即服务器分别得到每个访问请求的语句长度。

对于方式2，由于服务器是对所有访问请求的语句总长度进行的检测，因此服务器仅建立一条协程即可实现。与方式1不同的是，方式2中得到的检测结果只有一个，即所有访问请求的语句总长度，而非对应访问请求数量的多个语句长度。例如，假设服务器对一批共9条访问请求执行步骤 202，那么对于方式1而言，服务器获得9条检测结果，如图3所示，这9条检测结果分别为9条访问请求的语句长度。而对于方式2而言，服务器仅获得1条检测结果，如图4所示，该检测结果为9条访问请求的语句总长度，该长度应当与图3中各请求的语句长度之和相同。

203、服务器检测剩余缓存大小。

如前所述，本步骤可以在执行步骤202前后执行，也可以与步骤202 同时执行，本实施例对两步骤分配序号仅为便于表述。

在图1中，服务器每接收到一条访问请求时都需要进行一次缓存查询，缓存查询的次数与接收的访问请求数量相同。而在本实施例中，服务器对一批访问请求进行批量检测，因此仅需进行一次缓存查询即可。相对图1 所示方式，本实施例能够节省大量因频繁查询缓存所产生的处理资源消耗。

示例性的，假设一段时间内服务器接收并处理了450条访问请求，按照图1所示方式进行实现，服务器每接收到一条访问请求都需要进行一次缓存查询，服务器共进行了450次缓存查询；而按照图2所示方式进行实现，服务器在对450条访问请求的语句长度进行批量查询时，仅需进行一次缓存查询，相对图1所示方式能够节省449次缓存查询。

204、服务器判断剩余缓存大小是否小于多条访问请求的语句长度。

205、若剩余缓存大小不小于语句长度，则服务器对访问请求进行处理。

步骤204和步骤205的实现方式分别与图1中步骤102和步骤103的实现方式对应相同，此处不再赘述。但需要说明的是，结合步骤202中2 种不同的批量检测方式，步骤204和步骤205的实现方式略有差异。具体的：

对于上述检测方式1，由于服务器是对每条访问请求分别进行的检测，因此在执行步骤204、步骤205时，服务器针对每条访问请求分别判断剩余缓存大小是否小于其语句长度，并根据判断结果对每条访问请求分别进行处理。而对于上述检测方式2，由于服务器仅对所有访问请求的语句总长度进行了一次性检测，因此在执行步骤204时，服务器只需进行一次判断操作，即判断判断剩余缓存大小是否小于语句总长度，并且在执行步骤205 时，只进行一次处理操作。

示例性的，对于一批共9条访问请求而言，按照方式1进行实现时，服务器需要分别针对9条访问请求独立执行步骤204和步骤205，即服务器需要进行9次判断操作和9次处理操作；而按照方式2进行实现时，服务器只需要针对9条访问请求执行一次步骤204和步骤205，仅通过1次判断操作和处理操作即可完成一批访问请求的处理。

本实施例提供的方案，相对图1所示方案而言，能够在处理一批多条访问请求时，仅进行一次缓存查询，可以节省服务器因查询缓存所产生的处理资源消耗。此外，当采用上述方式2对一批访问请求进行统一处理时，相对上述方式1而言，方式2所述方案还可以节省服务器查询语句长度的次数、执行判断操作的次数以及处理访问请求的次数，进一步节省上述各操作所产生的处理资源消耗。

进一步的，当服务器的剩余缓存大小不足以对访问请求进行处理时，为保证访问请求能够在最大程度上获得响应，服务器还可以将访问请求加入到队列中进行等待，当缓存释放后，对队列中的访问请求进行及时处理。

具体的，作为与上述各实施例的结合，在本发明的另一实施例中，服务器可以在磁盘中开辟一段缓存以建立待处理队列，该待处理队列用于保存未得到及时处理的访问请求。对于这些访问请求，服务器按照接收的先后顺序将其加入到待处理队列中。当缓存释放后，服务器从待处理队列中选取一条或多条访问请求进行处理。进入处理的访问请求需要从待处理队列中清除。

在本实施例中，服务器可以根据网络规模以及请求语句长度的统计值自行设定待处理队列所需的缓存大小。一般情况下，客户端上报访问请求的响应时长不宜过长(容易降低QoS)因此待处理队列的缓存也不宜设置过大。本方案中，访问请求在待处理队列中等待的时间是由队列的空闲状态决定的，当队满时，如果有新的访问请求加入，则较早加入的访问请求将会被挤出队列遭到丢弃。过大的队列缓存会使较早加入的访问请求不易被挤出队列，增加了待处理请求过度等待的几率。因此适当降低队列缓存可以及时将队列中未处理的请求丢弃并向客户端反馈拒绝请求的响应，这种处理结果虽然未能成功响应访问请求，但是也好过客户端长时间无法获得响应。

上述方案中，访问请求在待处理队列中等待的时间是由队列的空闲状态决定的，除此之外，考虑到当待处理队列未占用满时，其中的访问请求也有可能等待较长的时间，在本实施例的一种改进方案中，服务器还可以为每一个加入到待处理队列的访问请求建立一条计时协程。无论访问请求在队列中的位置如何，只要计时超时服务器就将该访问请求进行丢弃，并清除出缓存，由此保证对客户端的及时响应。实际应用中该计时时长的设定应当参考客户端等待响应的最大容忍时长，一般情况下，该计时时长可以设定为1s至10s之间。

在释放已处理访问请求的缓存后，服务器优选对待处理队列中的访问请求进行处理。在访问请求于待处理队列中等待处理的过程中，服务器还会不断接收到客户端新上报的访问请求。当释放已处理访问请求的缓存后，对于待处理队列中的访问请求以及接收的访问请求，服务器可以予以同等的机会进行处理。但实际应用中，如果两种访问请求被加入处理的机会是均等的，那么会存在刚接收的访问请求被立即处理、而待处理队列中的访问请求还需继续等待的情况。因此，为平衡不同访问请求的等待时间，在本实施例的一种实现方式中，服务器可以优选对待处理队列中的访问请求进行处理，对于新接收的访问请求，则可以加入到待处理队列中等待处理。

在从待处理队列中选取访问请求进行处理时，服务器可以通过下述2 种方式对缓存释放的监听：

1、服务器周期性检测剩余缓存大小

该种实现方式与图1中的实现方式相似，此处不再赘述。

2、服务器建立协程监听访问请求的处理过程

服务器对所有正在处理的访问请求的处理过程进行监听，当有访问请求处理完毕时，服务器接收到特定指令，对释放该条访问请求后的缓存大小进行检测。

在检测到释放部分缓存后，服务器从待处理队列中选取一条或多条访问请求进行处理。本实施例不对服务器一次性选取的访问请求数量进行限制，但实际应用中该选取数量应当与检测缓存释放的时间间隔成正比，即 时间间隔越长(对应的，释放较多缓存的可能性越大)，服务器一次性选取的访问请求数量也应当越多。

此外，服务器还可以采用不同的方式对访问请求进行选取。一种较为简便的实现方式为，服务器按照待处理队列中先进先出的顺序，对队列中的访问请求顺序进行选取，即服务器按照访问请求的出队顺序选取待处理队列中队首的访问请求。这种选取方式的优势在于，服务器可以保证各条访问请求的等待时间不会出现较大差异，能够平衡各个客户端的响应速度。而在另一种选取方式中，服务器还可以采用随机抢占的方式在待处理队列中选取访问请求。在这种方式中，访问请求在队列中不再以先进先出的方式进行排序，当服务器释放缓存时，待处理队列中各条访问请求具有均等的被选取机会。后者选取方式的优势在于，管理访问请求的逻辑较为简单，能够节省队列管理的资源开销。

在选取一条或多条访问请求后，服务器检测其语句长度，并检测得到的语句长度与当前的剩余缓存大小(即释放缓存后的剩余缓存大小)进行比对。若选取的访问请求的语句长度小于或等于当前的剩余缓存大小，则服务器对该访问请求进行处理，向客户端返回相应的数据内容；若选取的访问请求的语句长度大于当前的剩余缓存大小，则丢弃该访问请求，并从待处理队列中重新选取新的访问请求进行处理。

进一步的，考虑到实际应用中，如果访问请求在待处理队列中等待一段时间后仍然被拒绝，那么客户端侧的服务质量会比直接拒绝该访问请求还要差，因此为保证本实施例的实现效果不劣于现有技术，在本实施例的一种改进方式中，服务器需要确保待处理队列中的访问请求能够得到处理。具体的，当当前剩余缓存大小无法处理选取出的访问请求时，服务器可以将选取出的访问请求重新加入到待处理队列中，等待下次处理(当然，访问请求在队列中的累计等待时长不应超过前述计时时长)。同时，服务器按照前述选取方式，在待处理队列中重新选取其他访问请求进行处理。

再进一步的，在二次选取的过程中，存在服务器再次选取到同一访问请求的小概率事件，因此作为对上述方式的替换，服务器也可以首先在待处理队列中二次选取访问请求，然后再将无法处理的访问请求重新加入到待处理队列中。

可选的，为避免因前述二次选取过程对请求处理资源及时长的消耗，在本实施例的另一种实现方式中，作为对上述二次选取方式的替换，服务器还可以在检测当前剩余缓存大小后，以该剩余缓存大小作为限制条件，在待处理队列中选取语句长度不大于该剩余缓存大小的访问请求进行处理，由此可以节省后续反复出队入队所产生的资源消耗。

除上述各实施例所示方案之外，本发明还提供了另一实施例，在该实施例中，服务器可以对访问请求语句长度进行限制，以提高不同网络条件下数据库访问的效率。具体的，如图5所示，该方法包括：

501、服务器获取作为长度限制条件的预设语句长度。

在接收客户端上报的访问请求之前，服务器可以获取针对不同网络条件制定的预设语句长度。该预设语句长度可以由网管人员通过特定的设置指令输入得到，也可以由服务器基于不同的预设条件自行计算得到。

在本实施例的一种实现方式中，上述预设条件包括：访问请求的实际并发数、网内客户端数量、缓存总大小以及忙闲时段。服务器可以根据一种预设条件(例如实际并发数量多少)计算预设语句长度，也可以根据至少两种任意预设条件的组合(例如实际并发数+忙闲时段)计算预设语句长度。

本实施例中，服务器对语句长度进行限制的目的在于结合不同的网络条件选择不同的目标访问请求进行优先处理。与现有技术中单纯规定语句长度值上限、以拒绝较大访问请求的目的不同，本实施例不仅针对较大的访问请求进行限制，同时也包括针对较小访问请求的限制。例如，当进行全网客户端的病毒查杀时，此类任务访问请求的语句长度通常较大，为将有限的处理资源优先应用到此类任务中，服务器可以仅对大于某一语句长度访问请求进行处理，由此暂停对诸如网页查询等较小访问请求的处理。

502、服务器接收客户端上报的访问请求。

本步骤中服务器接收所有客户端上报的访问请求，不对访问请求的语句长度进行甄别。

503、服务器检测访问请求的语句长度。

本步骤的实现方式与图1步骤101的实现方式相同，此处不再赘述。

504、服务器根据预设语句长度选择作为处理对象的访问请求。

根据不同的任务需求，服务器可以选择语句长度大于预设语句长度的访问请求作为待处理对象，也可以选择语句长度小于预设语句长度的访问请求作为待处理对象。

505、服务器判断剩余缓存大小是否小于选择的访问请求的语句长度。

506、若剩余缓存大小不小于语句长度，则服务器对选择的访问请求进行处理。

步骤505至步骤506的实现方式分别与图1中步骤102和步骤103的实现方式相同，此处不再赘述。

进一步的，作为对上述各实施例的改进，服务器还可以对用于处理访问请求的缓存大小进行自由分配。以图5所示方案为例，在执行步骤501 之前，服务器可以根据此前已处理过的访问请求的语句长度设置缓存大小。例如，服务器可以对此前一段时间内处理过的访问请求的语句长度进行统计，获得所有访问请求的平均语句长度，然后将该平均语句长度与要求的并发数上限相乘，计算得出所需的缓存大小。或者，作为对平均语句长度的替换，服务器也可以以所有访问请求中的最大语句长度计算所需缓存大小。

需要说明的是，本实施例中计算得出的缓存大小为处理访问请求分配的专用缓存空间，该缓存大小能够决定服务器处理访问请求的能力高低，其大小不以当前访问请求的实际并发数为转移。服务器分配的缓存大小与前述剩余缓存大小的关系为：剩余缓存大小+当前正在占用的缓存大小＝分配的缓存大小。

进一步的，作为对上述各方法实施例的实现，本发明的另一实施例还提供了一种语句长度的控制装置。该装置可以位于局域网中的应用服务器中，或者独立于应用服务器并与应用服务器之间具有数据交互关系。而在另一种实现方式中，该装置位于应用服务器的ngx模块中。如图6所示，该装置包括：接收单元61、检测单元62、判断单元63以及处理单元64，其中，

接收单元61，用于接收访问请求；

检测单元62，用于检测接收单元61接收的访问请求的语句长度及剩余缓存大小；

判断单元63，用于判断检测单元62检测的剩余缓存大小是否小于语句长度；

处理单元64，用于当判断单元63判断剩余缓存大小不小于语句长度时，对接收单元61接收的访问请求进行处理。

进一步的，检测单元62，用于对多条访问请求的语句长度进行批量检测。

进一步的，如图7所示，该装置还包括存储单元65，用于当判断单元 63判断剩余缓存大小不小于语句长度时，将接收单元61接收的访问请求加入待处理队列；

处理单元64，用于在释放已处理访问请求的缓存后，优选对存储单元 65保存的待处理队列中的访问请求进行处理。

进一步的，处理单元64，用于按照出队顺序选取待处理队列中队首的访问请求进行处理；

处理单元64，还用于按照随机抢占的方式选取待处理队列中的访问请求进行处理。

进一步的，存储单元65，用于当处理单元64选取的访问请求的语句长度大于当前的剩余缓存大小时，将处理单元64选取的访问请求重新加入到待处理队列中；

处理单元64，用于在待处理队列中重新选取其他访问请求进行处理。

进一步的，处理单元64，用于在预设条件下，优先对预设语句长度的访问请求进行处理，其中，不同预设条件对应不同的预设语句长度。

进一步的，处理单元64依据的预设条件包括：访问请求的实际并发数、网内客户端数量、缓存总大小以及忙闲时段。

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

设置单元66，用于在接收单元61接收访问请求之前，根据处理单元 64已处理访问请求的语句长度设置缓存大小。

本实施例提供的语句长度的控制装置，能够在剩余缓存大小足够处理接收的访问请求时，直接对该访问请求进行处理。与现有技术相比，本实施例不对访问请求的语句长度进行限制，只要剩余缓存足够大，就可以对任意长度的访问请求进行处理，能够满足客户端的各种业务需求。

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

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

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

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

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

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

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

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

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

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

Claims (12)

1.一种语句长度的控制方法，其特征在于，所述方法包括：

预先在内存中开辟出一块独立于逻辑存储区域以用于运行进程，所述逻辑存储区域是按照访问请求的接收顺序依次对不同访问请求进行检测和判断；

在接收到访问请求后，检测所述访问请求的语句长度及剩余缓存大小；

判断所述剩余缓存大小是否小于所述语句长度；

若所述剩余缓存大小不小于所述语句长度，则对所述访问请求进行处理；

若所述剩余缓存大小小于所述语句长度，则将所述访问请求加入待处理队列；

在释放已处理访问请求的缓存后，优选对所述待处理队列中的访问请求进行处理；

其中，优选对所述待处理队列中的访问请求进行处理具体包括：

按照随机抢占的方式选取所述待处理队列中的访问请求进行处理；

若选取的访问请求的语句长度大于当前的剩余缓存大小，则将所述选取的访问请求重新加入到所述待处理队列中；

在所述待处理队列中重新选取其他访问请求进行处理。

2.根据权利要求1所述的方法，其特征在于，所述检测所述访问请求的语句长度，包括：

对多条访问请求的语句长度进行批量检测。

3.根据权利要求1所述的方法，其特征在于，所述优选对所述待处理队列中的访问请求进行处理，包括：

按照出队顺序选取所述待处理队列中队首的访问请求进行处理。

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

在预设条件下，优先对预设语句长度的访问请求进行处理；

其中，不同预设条件对应不同的预设语句长度。

5.根据权利要求4所述的方法，其特征在于，所述预设条件包括：访问请求的实际并发数、网内客户端数量、缓存总大小以及忙闲时段。

6.根据权利要求1所述的方法，其特征在于，在接收所述访问请求之前，所述方法进一步包括：

根据已处理访问请求的语句长度设置缓存大小。

7.一种语句长度的控制装置，其特征在于，所述装置包括：

接收单元，用于预先在内存中开辟出一块独立于逻辑存储区域以用于运行进程，所述逻辑存储区域是按照访问请求的接收顺序依次对不同访问请求进行检测和判断，并接收访问请求；

检测单元，用于检测所述接收单元接收的所述访问请求的语句长度及剩余缓存大小；

判断单元，用于判断所述检测单元检测的所述剩余缓存大小是否小于所述语句长度；

处理单元，用于当所述判断单元判断所述剩余缓存大小不小于所述语句长度时，对所述接收单元接收的所述访问请求进行处理；

存储单元，用于当所述判断单元判断所述剩余缓存大小小于所述语句长度时，将所述接收单元接收的所述访问请求加入待处理队列；

所述处理单元，用于在释放已处理访问请求的缓存后，优选对所述存储单元保存的所述待处理队列中的访问请求进行处理；

所述处理单元，还用于按照随机抢占的方式选取所述待处理队列中的访问请求进行处理；

所述存储单元，用于当所述处理单元选取的访问请求的语句长度大于当前的剩余缓存大小时，将所述处理单元所述选取的访问请求重新加入到所述待处理队列中；

所述处理单元，用于在所述待处理队列中重新选取其他访问请求进行处理。

8.根据权利要求7所述的装置，其特征在于，所述检测单元，用于对多条访问请求的语句长度进行批量检测。

9.根据权利要求7所述的装置，其特征在于，所述处理单元，用于按照出队顺序选取所述待处理队列中队首的访问请求进行处理。

10.根据权利要求7所述的装置，其特征在于，所述处理单元，用于在预设条件下，优先对预设语句长度的访问请求进行处理，其中，不同预设条件对应不同的预设语句长度。

11.根据权利要求10所述的装置，其特征在于，所述处理单元依据的所述预设条件包括：访问请求的实际并发数、网内客户端数量、缓存总大小以及忙闲时段。

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

设置单元，用于在所述接收单元接收所述访问请求之前，根据所述处理单元已处理访问请求的语句长度设置缓存大小。