信息处理方法及装置与流程

本发明涉及计算机技术领域，尤其涉及一种信息处理方法及装置。

背景技术：

当前，人们通常在淘宝上购买商品，并在选定了商品之后，用户需要将商品的金额打入商户的银行账户，以完成对商品进行支付。

其中，淘宝官方会设置一个担保交易中间账户，担保交易中间账户的账户信息集成在第三方服务器中。这样，当用户对某一商品进行在线支付时，用户可以利用自己终端先将商品的金额转入第三方服务器中的担保交易中间账户中。当用户确定收货之后，第三方服务器就会将该商品的金额从担保交易中间账户转至商户的银行账户中。

具体地，第三方服务器将转账请求发送至银行的服务器，转账请求携带商品的金额和商户的银行账户，银行的服务器接收该转账请求，将该商品的金额添加至商户的银行账户中，如此完成对转账请求的处理。之后银行的服务器再向第三方服务器返回该转账请求的处理状态，其中处理状态为处理完毕状态。

然而，有时候可能存在短时间内大量的用户分别确定收货的情况，这样第三方服务器在短时间内就会向银行的服务器发送大量的转账请求。由于银行的服务器并行处理能力有限，也即，银行的服务器同时处理转账请求的数量有限，则对于其中的一部分转账请求，可能等待很长时间都不会被银行的服务器处理，这就发生转账请求掉单的情况，如此导致第三方服务器就会长时间接收不到银行的服务器为这一部分转账请求返回的处理状态。

其中，为了明确对这一部分转账请求的处理状态，第三方服务器就会向银行的服务器发送掉单查询请求。

在现有技术中，第三方服务器会按照如下默认查询策略进行查询，其中，默认查询策略的最大查询次数为预设查询次数。具体地，当第三方服务器为某一转账请求向银行的服务器发送一次掉单查询请求后，如果在发送该一次掉单查询请求之后的固定时长内接收到银行的服务器返回的转账请求的处理状态，则不再为该转账请求向银行的服务器发送掉单查询请求；如果在发送该一次掉单查询请求之后的固定时长内未接收到银行的服务器返回的转账请求的处理状态，则会继续向银行的服务器发送另一次掉单查询请求。如果在发送该另一次掉单查询请求之后的固定时长内接收到银行的服务器返回的转账请求的处理状 态，则不再为该转账请求向银行的服务器发送掉单查询请求；如果在发送该另一次掉单查询请求之后固定时长内仍旧未接收到银行的服务器返回的转账请求的处理状态，则继续向银行的服务器发送又一掉单查询请求，重复上述步骤，直至为该转账请求向银行的服务器发送的掉单查询请求的发送次数到达预设查询次数为止。

然而，发明人发现，在发生掉单的转账请求的数量非常多的情况下，为每一发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询，则可能出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，并在银行的服务器并行处理能力有限的情况下会影响银行的服务器会其他转账请求的处理效率，从而形成恶性循环。

技术实现要素：

为克服相关技术中存在的问题，本发明提供一种信息处理方法及装置。

根据本发明实施例的第一方面，提供一种信息处理方法，应用于第三方服务器，所述方法包括：

每间隔第一预设时长获取在所述第三方服务器的当前时刻之前的、时长为预设时长的时间段内发生掉单的业务请求的总掉单数量；

对于每一次获取的在一个时间段内发生掉单的业务请求的总掉单数量，将所述总掉单数量分别与第一预设数量阈值、第二预设数量阈值相比较；所述第二预设数量阈值大于所述第一预设数量阈值；

当所述总掉单数量小于所述第一预设数量阈值时，对在所述时间段内发生掉单的业务请求按照默认查询策略进行掉单查询；所述默认查询策略的最大查询次数为预设查询次数；

当所述总掉单数量大于或等于所述第一预设数量阈值且小于所述第二预设数量阈值时，对在所述时间段内发生掉单的业务请求按照第一查询策略进行掉单查询，所述第一查询策略的最大查询次数小于所述预设查询次数。

进一步地，所述方法还包括：

当所述总掉单数量大于或等于所述第一预设数量阈值且小于所述第二预设数量阈值时，将所述总掉单数量的掉单级别设置为第一级别；将所述时间段与所述第一级别绑定；

当所述总掉单数量大于或等于所述第二预设数量阈值时，将所述总掉单数量的掉单级别设置为第二级别；将所述时间段与所述第二级别绑定；

当所述总掉单数量小于所述第一预设数量阈值时，将所述总掉单数量的掉单级别设置 为第三级别；将所述时间段与所述第三级别绑定。

进一步地，所述方法还包括：

对于在所述时间段内发生掉单的每一业务请求，当查询到业务服务器已经对所述业务请求处理完毕时，将所述业务请求的处理状态设置为处理完毕状态。

进一步地，所述方法还包括：

对于在所述时间段内发生掉单的每一业务请求，当为所述业务请求向所述业务服务器发送掉单查询请求的发送次数达到所述预设查询次数时，将所述业务请求的查询状态设置为查询完毕状态。

进一步地，所述方法还包括：

每间隔第二预设时长获取在所述第三方服务器的当前时刻之前的、且距离所述第三方服务器的当前时刻最近的时间段；所述第二预设时长大于所述第一预设时长；

获取与所述获取的时间段相绑定的掉单级别；

当所述掉单级别为第三级别时，获取与所述第一级别相绑定的时间段，对在与所述第一级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态以及查询状态为未查询完毕状态的业务请求按照第二查询策略进行掉单查询；所述第二查询策略的最大查询次数为所述默认查询策略的最大查询次数与所述第一查询策略的最大查询次数之间的差值；

和/或，

当所述掉单级别为第三级别时，获取与所述第二级别相绑定的时间段，对在与所述第二级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态的业务请求按照默认查询策略进行掉单查询。

其中，所述对在与所述第一级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态以及查询状态为未查询完毕状态的业务请求按照第二查询策略进行掉单查询，包括：

获取在与所述第一级别相绑定的每一个时间段内的所有发生掉单的业务请求；

在所述获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

从所述查找出的业务请求出选择出查询状态为未查询完毕状态的业务请求；

对所述选择出的业务请求按照所述第二查询策略进行掉单查询。

其中，所述对在与所述第二级别相绑定的每一个时间段内发生掉单的、处理状态为未 处理完毕状态的业务请求按照默认查询策略进行掉单查询，包括：

获取在与所述第二级别相绑定的每一个时间段内的所有发生掉单的业务请求；

在所述获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

对所述查找出的业务请求按照所述默认查询策略进行掉单查询。

根据本发明实施例的第二方面，提供一种信息处理装置，应用于第三方服务器，所述装置包括：

第一获取模块，用于每间隔第一预设时长获取在所述第三方服务器的当前时刻之前的、时长为预设时长的时间段内发生掉单的业务请求的总掉单数量；

比较模块，用于对于每一次获取的在一个时间段内发生掉单的业务请求的总掉单数量，将所述总掉单数量分别与第一预设数量阈值、第二预设数量阈值相比较；所述第二预设数量阈值大于所述第一预设数量阈值；

第一查询模块，用于当所述总掉单数量小于所述第一预设数量阈值时，对在所述时间段内发生掉单的业务请求按照默认查询策略进行掉单查询；所述默认查询策略的最大查询次数为预设查询次数；

第二查询模块，用于当所述总掉单数量大于或等于所述第一预设数量阈值且小于所述第二预设数量阈值时，对在所述时间段内发生掉单的业务请求按照第一查询策略进行掉单查询，所述第一查询策略的最大查询次数小于所述预设查询次数。

进一步地，所述装置还包括：

第一绑定模块，用于当所述总掉单数量大于或等于所述第一预设数量阈值且小于所述第二预设数量阈值时，将所述总掉单数量的掉单级别设置为第一级别；将所述时间段与所述第一级别绑定；

第二绑定模块，用于当所述总掉单数量大于或等于所述第二预设数量阈值时，将所述总掉单数量的掉单级别设置为第二级别；将所述时间段与所述第二级别绑定；

第三绑定模块，用于当所述总掉单数量小于所述第一预设数量阈值时，将所述总掉单数量的掉单级别设置为第三级别；将所述时间段与所述第三级别绑定。

进一步地，所述装置还包括：

第一设置模块，用于对于在所述时间段内发生掉单的每一业务请求，当查询到业务服务器已经对所述业务请求处理完毕时，将所述业务请求的处理状态设置为处理完毕状态。

进一步地，所述装置还包括：

第二设置模块，用于对于在所述时间段内发生掉单的每一业务请求，当为所述业务请求向所述业务服务器发送掉单查询请求的发送次数达到所述预设查询次数时，将所述业务请求的查询状态设置为查询完毕状态。

进一步地，所述装置还包括：

第二获取模块，用于每间隔第二预设时长获取在所述第三方服务器的当前时刻之前的、且距离所述第三方服务器的当前时刻最近的时间段；所述第二预设时长大于所述第一预设时长；

第三获取模块，用于获取与所述获取的时间段相绑定的掉单级别；

第四获取模块，用于当所述掉单级别为第三级别时，获取与所述第一级别相绑定的时间段；第三查询模块，用于对在与所述第一级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态以及查询状态为未查询完毕状态的业务请求按照第二查询策略进行掉单查询；所述第二查询策略的最大查询次数为所述默认查询策略的最大查询次数与所述第一查询策略的最大查询次数之间的差值；

和/或，

第五获取模块，用于当所述掉单级别为第三级别时，获取与所述第二级别相绑定的时间段；第四查询模块，用于对在与所述第二级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态的业务请求按照默认查询策略进行掉单查询。

其中，所述第三查询模块包括：

第一获取单元，用于获取在与所述第一级别相绑定的每一个时间段内的所有发生掉单的业务请求；

第一查找单元，用于在所述获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

选择单元，用于从所述查找出的业务请求出选择出查询状态为未查询完毕状态的业务请求；

第一查询单元，用于对所述选择出的业务请求按照所述第二查询策略进行掉单查询。

其中，所述第四查询模块包括：

第二获取单元，用于获取在与所述第二级别相绑定的每一个时间段内的所有发生掉单的业务请求；

第二查找单元，用于在所述获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

第二查询单元，用于对所述查找出的业务请求按照所述默认查询策略进行掉单查询。

本发明的实施例提供的技术方案可以包括以下有益效果：

在本发明实施例中，由于业务服务器的并行处理资源有限且是固定不变的。因此，当总掉单数量小于第一预设数量阈值时，说明在这个时间段内业务服务器需要处理的业务请求的数量较少，业务服务器的系统压力较小，对在这个时间段内发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询不会影响业务服务器对需要处理的业务请求进行处理的处理效率，也就不会形成恶性循环。也即，即使对在这个时间段内发生掉单的每一业务请求都向业务服务器发送预设查询次数次掉单查询请求也不会影响业务服务器对需要处理的业务请求进行处理的处理效率，不会形成恶性循环。

然而，当总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值时，说明在这个时间段内业务服务器需要处理的业务请求的数量较多，业务服务器的系统压力较大，业务服务器需要花费很多时间才能处理完需要处理的所有业务请求。如果此时对在这个时间段内发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询，则可能出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，这样业务服务器就需要将更多的处理资源用来处理掉单查询请求，由于业务服务器的并行处理资源有限且是固定不变的，因此就会占用业务服务器用来处理业务请求的处理资源，导致业务服务器就只能利用较少的处理资源用来处理需要处理的业务请求，在需要处理的业务请求的数量不变的情况下，就会使得业务服务器需要花费更多的时间才能处理完需要处理的所有业务请求，从而降低处理效率。其次，如果此时再接收到其他业务请求，由于对之前接收到的业务请求都没有处理完毕，则很可能导致新接收的该其他业务请求发生掉单，进而恶性循环。

因此，此时业务服务器需要利用更多的处理资源对需要处理的业务请求进行处理，所以，为了使得业务服务器能够利用更多的处理资源对需要处理的业务请求进行处理，当总掉单数量大于或等于第一预设数量阈值且小于或等于第二预设数量阈值时，第三方服务器需要对在这个时间段内发生掉单的业务请求按照最大查询次数小于预设查询次数的第一查询策略进行掉单查询，从而避免出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，进而避免调单查询请求过多的占用了业务服务器的处理资源，因此，相对于现有技术，本发明实施例可以提高对业务服务器对业务请求的处理效率，以及避免形成恶性循环。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例示出的一种信息处理方法的流程图；

图2是根据一示例性实施例示出的一种信息处理方法的流程图；

图3是根据一示例性实施例示出的一种信息处理方法的流程图；

图4是根据一示例性实施例示出的一种信息处理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种信息处理方法的流程图，如图1所示，该方法用于第三方服务器中，该方法包括以下步骤。

在步骤s101中，每间隔第一预设时长获取在第三方服务器的当前时刻之前的、时长为预设时长的时间段内发生掉单的业务请求的总掉单数量；

在本发明实施例中，业务请求可以为支付请求或转账请求等。

当第三方服务器的当前时刻与第三方服务器最近一次获取发生掉单的业务请求的总数量的获取时刻之间的时长为第一预设时长时，第三方服务器获取在当前时刻之前的、时长为第一预设时长的时间段内发生掉单的业务请求的总掉单数量。

其中，每当第三方服务器向业务服务器发送一个业务请求时，由于此时业务服务器对该业务请求还没有开始处理，因此第三方服务器可以将该业务请求的处理状态设置为未处理完毕状态，然后将该业务请求的请求标识、向业务服务器发送该业务请求的发送时刻与未处理完毕状态组成一条记录存储在本地存储的请求标识、发送时刻与处理状态三者之间的第一对应关系中。之后当业务服务器接收到第三方服务器发送的该业务请求并对该业务请求处理完毕时，会向第三方服务器通知已对该业务请求处理完毕；当第三方服务器接收到业务服务器返回的已对该业务请求处理完毕的通知时，就可以在第一对应关系中的该记录中，将处理状态由未处理完毕状态更新为未处理完毕状态。

然而，当业务服务器接收到第三方服务器发送的该业务请求时，如果此时还有其他业 务请求正在等待被业务服务器处理，由于业务请求需要按照被业务服务器接收的先后顺序排队，这样业务服务器可能不会立刻就对该业务请求进行处理，如果此时正在等待被业务服务器处理的其他业务请求的数量较多，由于业务服务器能够同时处理的业务请求的数量有限，且业务服务器需要优先对该其他业务请求进行处理，这样很可能导致很长一段时间内业务服务器都不会对该业务请求进行处理，这样就会导致该业务请求发生掉单，并导致第三方服务器在向业务服务器发送该业务请求之后的很长一段时间内都接收不到业务服务器返回的已对该业务请求处理完毕的通知，进而也就不会在第一对应关系中的该记录中，将处理状态由未处理完毕状态更新为未处理完毕状态。

因此，在本发明实施例中，第三方服务器可以根据业务请求的处理状态是否为未处理完毕状态来判断业务请求是否为发生掉单的业务请求。

在本步骤中，当第三方服务器需要获取在第三方服务器的当前时刻之前的、时长为第一预设时长的时间段内发生掉单的业务请求的总掉单数量时，可以在第一对应关系中查找位于该时间段内的发送时刻；并在第一对应关系中查找与查找到的每一个发送时刻相对应的处理状态，在查找到的所有处理状态中，统计处理状态为未处理完毕状态的处理状态的数量，并作为在第三方服务器的当前时刻之前的、时长为第一预设时长的时间段内发生掉单的业务请求的总掉单数量。

在步骤s102中，对于每一次获取的在一个时间段内发生掉单的业务请求的总掉单数量，将总掉单数量分别与第一预设数量阈值、第二预设数量阈值相比较；

其中，第一预设数量阈值可以为技术人员事先在第三方服务器上设置的阈值，可以为50、60或70等等，本发明对此不加以限定。第二预设数量阈值大于第一预设数量阈值。

在本发明实施例中，每当第三方服务器获取到一个时间段内的总掉单数量，第三方服务器就会将获取的总掉单数量分别与第一预设数量阈值、第二预设数量阈值相比较。如果总掉单数量小于第一预设数量阈值，则执行步骤s103。如果总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值，则执行步骤s104。

如果总掉单数量大于或等于第二预设数量阈值，说明在这个时间段内业务服务器需要处理的业务请求的数量较非常多，业务服务器的系统压力非常大，业务服务器需要花费很多时间才能处理完需要处理的所有业务请求。由于业务服务器的并行处理资源有限且是固定不变的，如果此时为在这个时间段内发生掉单的所有业务请求都向业务服务器发送掉单查询请求，则业务服务器就需要将更多的处理资源用来处理掉单查询请求，这样就会占用业务服务器用来处理业务请求的处理资源，导致业务服务器就只能利用较少的处理资源用来处理需要处理的业务请求，在需要处理的业务请求的数量不变的情况下，就会使得业务服务器需要花费更多的时间才能处理完需要处理的所有业务请求，从而降低处理效率。其 次，如果此时再接收到其他业务请求，由于对之前接收到的业务请求都没有处理完毕，则很可能导致新接收的该其他业务请求发生掉单，进而形成恶性循环。

因此，为了避免降低业务服务器对业务请求的处理效率以及避免形成恶性循环，如果总掉单数量大于或等于第二预设数量阈值，则此时不对在这个时间段发生掉单的业务请求进行掉单查询。具体在什么时候再对在这个时间段发生掉单的业务请求进行掉单查询可以参见图3所示的实施例，在此不做详述。

当总掉单数量小于第一预设数量阈值时，在步骤s103中，对在该时间段内发生掉单的业务请求按照默认查询策略进行掉单查询；默认查询策略的最大查询次数为预设查询次数；

当总掉单数量小于第一预设数量阈值时，说明在该时间段内的发生掉单的业务请求的数量较少，也即，在该时间段内业务服务器需要处理的业务请求的数量较少，此时可以对在该时间段内发生掉单的业务请求按照默认查询策略进行掉单查询。

具体地，第三方服务器向业务服务器发送携带该业务请求的请求标识的掉单查询请求。

如果在发送该掉单查询请求之后的固定时长内接收到业务服务器返回的该业务请求的处理状态；则不再向业务服务器发送携带该业务请求的请求标识的掉单查询请求。

如果在发送该掉单查询请求之后的固定时长内未接收到业务服务器返回的该业务请求的处理状态；则会再一次向业务服务器发送携带该业务请求的请求标识的掉单查询请求。

如果在再一次发送该掉单查询请求之后的固定时长内接收到业务服务器返回的该业务请求的处理状态；则不再向业务服务器发送携带该业务请求的请求标识的掉单查询请求。

如果在再一次发送该掉单查询请求之后的固定时长内未接收到业务服务器返回的该业务请求的处理状态；则继续向业务服务器发送携带该业务请求的请求标识的掉单查询请求，重复上述步骤，直至向业务服务器发送的携带该业务请求的请求标识的掉单查询请求的发送次数达到预设查询次数时，无论是否接收到业务服务器返回的该业务请求的处理状态，也不再向业务服务器发送携带该业务请求的请求标识的掉单查询请求，也即不再对该业务请求进行掉单查询。

当总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值时，在步骤s104中，对在该时间段内发生掉单的业务请求按照第一查询策略进行掉单查询，第一查询策略的最大查询次数小于预设查询次数。

当总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值时，说明在该时间段内的发生掉单的业务请求的数量较多，也即，在该时间段内业务服务器需要处理的业务请求的数量较多，此时为了避免出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，进而避免使调单查询请求过多的占用了业务服务器 的处理资源，此时就不能对在该时间段内发生掉单的业务请求按照最大查询次数等于预设查询次数的默认查询策略进行掉单查询，而需要对在该时间段内发生掉单的业务请求按照最大查询次数小于预设查询次数的第一查询策略进行掉单查询。

具体的查询流程可参见步骤s103中的具体流程，区别在于：在本步骤中，直至向业务服务器发送的携带该业务请求的请求标识的掉单查询请求的发送次数达到第一查询策略的最大查询次数时，无论是否接收到业务服务器返回的该业务请求的处理状态，也不再向业务服务器发送携带该业务请求的请求标识的掉单查询请求。

在本发明实施例中，由于业务服务器的并行处理资源有限且是固定不变的。因此，当总掉单数量小于第一预设数量阈值时，说明在这个时间段内业务服务器需要处理的业务请求的数量较少，业务服务器的系统压力较小，对在这个时间段内发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询不会影响业务服务器对需要处理的业务请求进行处理的处理效率，也就不会形成恶性循环。也即，即使对在这个时间段内发生掉单的每一业务请求都向业务服务器发送预设查询次数次掉单查询请求也不会影响业务服务器对需要处理的业务请求进行处理的处理效率，也不会形成恶性循环。

然而，当总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值时，说明在这个时间段内业务服务器需要处理的业务请求的数量较多，业务服务器的系统压力较大，业务服务器需要花费很多时间才能处理完需要处理的所有业务请求。如果此时对在这个时间段内发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询，则可能出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，这样业务服务器就需要将更多的处理资源用来处理掉单查询请求，由于业务服务器的并行处理资源有限且是固定不变的，因此就会占用业务服务器用来处理业务请求的处理资源，导致业务服务器就只能利用较少的处理资源用来处理需要处理的业务请求，在需要处理的业务请求的数量不变的情况下，就会使得业务服务器需要花费更多的时间才能处理完需要处理的所有业务请求，从而降低处理效率。其次，如果此时再接收到其他业务请求，由于对之前接收到的业务请求都没有处理完毕，则很可能导致新接收的该其他业务请求发生掉单，进而恶性循环。

因此，此时业务服务器需要利用更多的处理资源对需要处理的业务请求进行处理，所以，为了使得业务服务器能够利用更多的处理资源对需要处理的业务请求进行处理，当总掉单数量大于或等于第一预设数量阈值且小于或等于第二预设数量阈值时，第三方服务器需要对在这个时间段内发生掉单的业务请求按照最大查询次数小于预设查询次数的第一查询策略进行掉单查询，从而避免出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，进而避免调单查询请求过多的占用了业务服务器的处理资源，因此，相对于现有技术，本发明实施例可以提高对业务服务器对业务请求的处理 效率，以及避免形成恶性循环。

进一步地，在本发明图1所示的实施例的基础之上，在本发明另一实施例中，参见图2，该方法还包括：

当总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值时，在步骤s201中，将总掉单数量的掉单级别设置为第一级别，并将该时间段与第一级别绑定；

其中，当总掉单数量小于第二预设数量阈值时，第三方服务器可以将总掉单数量的掉单级别设置为第一级别；第一级别用于表示该时间段内的掉单数量的严重程度为“中等”；然后将该时间段与第一级别组成一条记录存储在时间段与掉单级别之间的第二对应关系中，以实现将该时间段与第一级别绑定。

当总掉单数量大于或等于第二预设数量阈值时，在步骤s202中，将总掉单数量的掉单级别设置为第二级别；将该时间段与第二级别绑定；

其中，当总掉单数量大于或等于第二预设数量阈值时，第三方服务器可以将总掉单数量的掉单级别设置为第二级别；第二级别用于表示该时间段内的严重程度为“严重”；然后将该时间段与第二级别组成一条记录存储在时间段与掉单级别之间的第二对应关系中，以实现将该时间段与第二级别绑定。

当总掉单数量小于第一预设数量阈值时，在步骤s203中，将总掉单数量的掉单级别设置为第三级别；将该时间段与第三级别绑定。

其中，当总掉单数量小于第一预设数量阈值时，第三方服务器可以将总掉单数量的掉单级别设置为第三级别；第三级别用于表示该时间段内的严重程度为“轻微”；然后将该时间段与第三级别组成一条记录存储在时间段与掉单级别之间的第二对应关系中，以实现将该时间段与第三级别绑定。

进一步地，对于在该时间段内发生掉单的每一业务请求，当业务服务器对该业务请求处理完毕时，会向第三方服务器通知已对该业务请求处理完毕；当第三方服务器接收到业务服务器返回的已对该业务请求处理完毕的通知时，也即，当第三方服务器查询到业务服务器已经对该业务请求处理完毕时，将该业务请求的处理状态设置为处理完毕状态。

其中，将该业务请求的处理状态设置为处理完毕状态，可以为：

第三方服务器可以获取本地存储的请求标识、发送时刻、处理状态三者之间的第一对应关系，在第一对应关系中，将该业务请求的请求标识对应的处理状态更新为处理完毕状 态。

进一步地，对于在该时间段内发生掉单的每一业务请求，当为该业务请求向业务服务器发送掉单查询请求的发送次数达到预设查询次数时，预设查询次数为默认查询策略的最大查询次数，也即，当向业务服务器发送携带该业务请求的请求标识的掉单查询请求的发送次数达到预设查询次数时，将该业务请求的查询状态设置为查询完毕状态。

其中，技术人员事先可以在本地设置一个预设请求标识列表，当第三方服务器为某一业务请求向业务服务器发送掉单查询请求的发送次数达到预设查询次数时就会将该某一业务请求的请求标识存储在预设请求标识列表中，以表示该业务请求的查询状态为查询完毕状态。

其中，将该业务请求的查询状态设置为查询完毕状态，可以为：将该业务请求的请标识存储在预设请求标识列表中。

在本发明实施例中，对于任意一个业务请求，当对该业务请求按照默认查询策略进行掉单查询之后，无论是否查询到该业务请求的处理状态，之后都不再对该业务请求进行掉单查询。

在前述实施例中，对于任意一个时间段，如果对该时间段内发生掉单的业务请求是按照第一查询策略进行掉单查询的，则可能存在仍旧未查询到在该时间段内发生掉单的业务请求中的某一部分业务请求的处理状态的情况，这就需要继续对这一部分发生掉单的业务请求的掉单查询次数进行补偿，并根据补偿的查询次数对这一部分发生掉单的业务请求进行掉单查询。对于其他每一个时间段，同样如此。

因此，在本发明图2所示的实施例的基础之上，在本发明又一实施例中，参见图3，该方法还包括：

在步骤s301中，每间隔第二预设时长获取在第三方服务器的当前时刻之前的、且距离第三方服务器的当前时刻最近的时间段；第二预设时长大于第一预设时长；

在本发明实施例中，每一个时间段的时长都为第一预设时长。第二预设时长可以为第一预设时长的5倍、10倍或15倍等，本发明对此不加以限定。

在步骤s302中，获取与该时间段相绑定的掉单级别；

具体地，第三方服务器可以获取本地存储的时间段与掉单级别之间的第二对应关系；然后在第二对应关系中查找与该时间段相对应的掉单级别。

在本发明实施例中，如果与该时间段相对应的掉单级别为第一级别或第二级别，则说明该时间段内发生掉单的业务请求的数量较多，也即，在该时间段内业务服务器需要处理的业务请求的数量较多，为了使得业务服务器能够利用更多的处理资源对需要处理的业务请求进行处理，此时就不向业务服务器发送掉单查询请求，也即不进行任何操作。

如果该时间段对应的掉单级别为第三级别，则说明该时间段内发生掉单的业务请求的数量较少，也即，在该时间段内业务服务器需要处理的业务请求的数量较少，因此此时可以执行步骤s303和/或执行步骤s304。

在步骤s303中，当该掉单级别为第三级别时，获取与第一级别相绑定的时间段，对在与第一级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态以及查询状态为未查询完毕状态的业务请求按照第二查询策略进行掉单查询；第二查询策略的最大查询次数为默认查询策略的最大查询次数与第一查询策略的最大查询次数之间的差值；

其中，对在与第一级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态以及查询状态为未查询完毕状态的业务请求按照第二查询策略进行掉单查询，包括：

3031、获取在与第一级别相绑定的每一个时间段内的所有发生掉单的业务请求；

获取本地存储的时间段与掉单级别之间的第二对应关系，在第二对应关系中查找与第一级别相对应的时间段。

3032、在获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

获取本地存储的请求标识、发送时刻与处理状态三者之间的第一对应关系，在第一对应关系中查找与获取的每一个业务请求的请求标识相对应的处理状态，从获取的所有业务请求中查找出处理状态为未处理完毕状态的业务请求。

3033、从查找出的业务请求出选择出查询状态为未查询完毕状态的业务请求；

然后获取本地存储的预设请求标识列表，在预设请求标识列表中查找是否存在每一个查找出的业务请求的请求标识，将请求标识不存在于预设请求标识列表中的业务请求确定为查询状态为未查询完毕状态的业务请求。

3034、对选择出的业务请求按照第二查询策略进行掉单查询。

其中，由于之前已经按照第一查询策略对选择出的业务请求进行了掉单查询，为了将查询次数补齐至预设查询次数，则需要对选择出的业务请求按照第二查询策略进行掉单查询。

在本发明实施例中，当掉单级别为第三级别时，说明在该时间段内的发生掉单的业务请求的数量较少，也即，在该时间段内业务服务器需要处理的业务请求的数量较少，业务 服务器的系统压力较小，此时对选择出的业务请求按照第二查询策略进行掉单查询不会影响业务服务器对需要处理的业务请求进行处理的处理效率，也就不会形成恶性循环。也即，即使此时对选择出的每一业务请求都向业务服务器发送该差值次掉单查询请求也不会影响业务服务器对需要处理的业务请求进行处理的处理效率，不会形成恶性循环。

其中，对选择出的业务请求按照最大查询次数为该差值的第二查询策略进行掉单查询具体的查询流程可参见步骤s103中的具体流程，区别在于：在本步骤中，直至向业务服务器发送的携带选择出的业务请求的请求标识的掉单查询请求的发送次数达到第二查询策略的最大查询次数时，无论是否接收到业务服务器返回的选择出的业务请求的处理状态，也不再向业务服务器发送携带选择出的业务请求的请求标识的掉单查询请求，也即不再对选择出的业务请求进行掉单查询。

在步骤s304中，当该掉单级别为第三级别时，获取与第二级别相绑定的时间段，对在与第二级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态的业务请求按照默认查询策略进行掉单查询。

其中，对在与第二级别相绑定的时间段内发生掉单的、处理状态为未处理完毕状态的业务请求按照默认查询策略进行掉单查询，包括：

3041、获取在与第二级别相绑定的每一个时间段内的所有发生掉单的业务请求；

3042、在获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

3043、对查找出的业务请求按照默认查询策略进行掉单查询。

其中，由于之前不曾对查找出业务请求进行掉单查询，因此，需要对查找出的业务请求按照默认查询策略进行掉单查询。

在本发明实施例中，当掉单级别为第三级别时，说明在该时间段内的发生掉单的业务请求的数量较少，也即，在该时间段内业务服务器需要处理的业务请求的数量较少，业务服务器的系统压力较小，此时对查找到的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询不会影响业务服务器对需要处理的业务请求进行处理的处理效率，也就不会形成恶性循环。也即，此时即使对查找到的每一业务请求都向业务服务器发送预设查询次数次掉单查询请求也不会影响业务服务器对需要处理的业务请求进行处理的处理效率，不会形成恶性循环。

其中，对查找到的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询具体的查询流程可参见步骤s103中的具体流程，区别在于：在本步骤中，直至向业务服务器发送的携带查找到的业务请求的请求标识的掉单查询请求的发送次数达到默认查询策略的最大查询次数时，无论是否接收到业务服务器返回的查找到的业务请求的处理状 态，也不再向业务服务器发送携带查找到的业务请求的请求标识的掉单查询请求，也即不再对查找到的业务请求进行掉单查询。

图4是根据一示例性实施例示出的一种信息处理装置的框图。参照图4，该装置包括：

第一获取模块11，用于每间隔第一预设时长获取在所述第三方服务器的当前时刻之前的、时长为预设时长的时间段内发生掉单的业务请求的总掉单数量；

比较模块12，用于对于每一次获取的在一个时间段内发生掉单的业务请求的总掉单数量，将所述总掉单数量分别与第一预设数量阈值、第二预设数量阈值相比较；所述第二预设数量阈值大于所述第一预设数量阈值；

第一查询模块13，用于当所述总掉单数量小于所述第一预设数量阈值时，对在所述时间段内发生掉单的业务请求按照默认查询策略进行掉单查询；所述默认查询策略的最大查询次数为预设查询次数；

第二查询模块14，用于当所述总掉单数量大于或等于所述第一预设数量阈值且小于所述第二预设数量阈值时，对在所述时间段内发生掉单的业务请求按照第一查询策略进行掉单查询，所述第一查询策略的最大查询次数小于所述预设查询次数。

进一步地，所述装置还包括：

第一绑定模块，用于当所述总掉单数量大于或等于所述第一预设数量阈值且小于所述第二预设数量阈值时，将所述总掉单数量的掉单级别设置为第一级别；将所述时间段与所述第一级别绑定；

第二绑定模块，用于当所述总掉单数量大于或等于所述第二预设数量阈值时，将所述总掉单数量的掉单级别设置为第二级别；将所述时间段与所述第二级别绑定；

第三绑定模块，用于当所述总掉单数量小于所述第一预设数量阈值时，将所述总掉单数量的掉单级别设置为第三级别；将所述时间段与所述第三级别绑定。

进一步地，所述装置还包括：

第一设置模块，用于对于在所述时间段内发生掉单的每一业务请求，当查询到业务服务器已经对所述业务请求处理完毕时，将所述业务请求的处理状态设置为处理完毕状态。

进一步地，所述装置还包括：

第二设置模块，用于对于在所述时间段内发生掉单的每一业务请求，当为所述业务请求向所述业务服务器发送掉单查询请求的发送次数达到所述预设查询次数时，将所述业务请求的查询状态设置为查询完毕状态。

进一步地，所述装置还包括：

第二获取模块，用于每间隔第二预设时长获取在所述第三方服务器的当前时刻之前的、且距离所述第三方服务器的当前时刻最近的时间段；所述第二预设时长大于所述第一预设时长；

第三获取模块，用于获取与所述获取的时间段相绑定的掉单级别；

第四获取模块，用于当所述掉单级别为第三级别时，获取与所述第一级别相绑定的时间段；第三查询模块，用于对在与所述第一级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态以及查询状态为未查询完毕状态的业务请求按照第二查询策略进行掉单查询；所述第二查询策略的最大查询次数为所述默认查询策略的最大查询次数与所述第一查询策略的最大查询次数之间的差值；

和/或，

第五获取模块，用于当所述掉单级别为第三级别时，获取与所述第二级别相绑定的时间段；第四查询模块，用于对在与所述第二级别相绑定的每一个时间段内发生掉单的、处理状态为未处理完毕状态的业务请求按照默认查询策略进行掉单查询。

其中，所述第三查询模块包括：

第一获取单元，用于获取在与所述第一级别相绑定的每一个时间段内的所有发生掉单的业务请求；

第一查找单元，用于在所述获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

选择单元，用于从所述查找出的业务请求出选择出查询状态为未查询完毕状态的业务请求；

第一查询单元，用于对所述选择出的业务请求按照所述第二查询策略进行掉单查询。

其中，所述第四查询模块包括：

第二获取单元，用于获取在与所述第二级别相绑定的每一个时间段内的所有发生掉单的业务请求；

第二查找单元，用于在所述获取的业务请求中查找出处理状态为未处理完毕状态的业务请求；

第二查询单元，用于对所述查找出的业务请求按照所述默认查询策略进行掉单查询。

在本发明实施例中，由于业务服务器的并行处理资源有限且是固定不变的。因此，当 总掉单数量小于第一预设数量阈值时，说明在这个时间段内业务服务器需要处理的业务请求的数量较少，业务服务器的系统压力较小，对在这个时间段内发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询不会影响业务服务器对需要处理的业务请求进行处理的处理效率，也就不会形成恶性循环。也即，即使对在这个时间段内发生掉单的每一业务请求都向业务服务器发送预设查询次数次掉单查询请求也不会影响业务服务器对需要处理的业务请求进行处理的处理效率，不会形成恶性循环。

然而，当总掉单数量大于或等于第一预设数量阈值且小于第二预设数量阈值时，说明在这个时间段内业务服务器需要处理的业务请求的数量较多，业务服务器的系统压力较大，业务服务器需要花费很多时间才能处理完需要处理的所有业务请求。如果此时对在这个时间段内发生掉单的业务请求按照最大查询次数为预设查询次数的默认查询策略进行掉单查询，则可能出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，这样业务服务器就需要将更多的处理资源用来处理掉单查询请求，由于业务服务器的并行处理资源有限且是固定不变的，因此就会占用业务服务器用来处理业务请求的处理资源，导致业务服务器就只能利用较少的处理资源用来处理需要处理的业务请求，在需要处理的业务请求的数量不变的情况下，就会使得业务服务器需要花费更多的时间才能处理完需要处理的所有业务请求，从而降低处理效率。其次，如果此时再接收到其他业务请求，由于对之前接收到的业务请求都没有处理完毕，则很可能导致新接收的该其他业务请求发生掉单，进而恶性循环。

因此，此时业务服务器需要利用更多的处理资源对需要处理的业务请求进行处理，所以，为了使得业务服务器能够利用更多的处理资源对需要处理的业务请求进行处理，当总掉单数量大于或等于第一预设数量阈值且小于或等于第二预设数量阈值时，第三方服务器需要对在这个时间段内发生掉单的业务请求按照最大查询次数小于预设查询次数的第一查询策略进行掉单查询，从而避免出现为每一个发生掉单的业务请求都向业务服务器发送预设查询次数次掉单查询请求的情况，进而避免调单查询请求过多的占用了业务服务器的处理资源，因此，相对于现有技术，本发明实施例可以提高对业务服务器对业务请求的处理效率，以及避免形成恶性循环。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由所附的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。