CN105577958B - 用于调整分流策略和分流用户请求的方法、装置及*** - Google Patents

Abstract

本申请公开了一种用于调整分流策略的方法和装置，一种用于分流用户请求的方法、装置和***，以及另一种用于分流用户请求的方法和装置。其中用于调整分流策略的方法包括：获取处于等待队列中的用户请求的相关信息；根据所述用户请求的相关信息选择分流策略，所述分流策略是指，将所述等待队列中的用户请求分流到服务队列所采用的策略；判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略。采用本申请提供的技术方案，解决了现有技术只能固定地采用单一分流策略、以及需要人工介入才能改变分流策略的弊端，可以在不同的应用场景下自动、及时地调整分流策略，并采用相应的分流策略对用户请求进行分流。

Description

用于调整分流策略和分流用户请求的方法、装置及***

技术领域

本申请涉及对用户请求的分流处理领域，具体涉及一种用于调整分流策略的方法和装置。本申请同时提供一种用于分流用户请求的方法、装置和***，以及另一种用于分流用户请求的方法和装置。

背景技术

热线客户服务平台(也称为电话客服***)通常是指利用电话通讯技术，通过接听客户来电，快捷地为客户提供咨询服务或者有效地处理客户投诉的***。该***可以同时接入大量来话，将来电自动分配给具备相应技能的客服人员处理，并能记录和储存所有来话信息。一个典型的热线客户服务平台不仅能够处理客户的信息查询、咨询、投诉等业务，还可以进行顾客回访、满意度调查等附加业务。热线客户服务平台的种类很多，例如：IT行业中的技术支持中心，保险行业中的电话理赔中心等。

随着互联网技术的发展，为了加强与客户的交流，很多网站推出了自己的在线客服***(也称网站客服***)。所谓在线客服***是一种网页版即时通讯软件的统称，相对于传统的电话客服***，在线客服***具有易部署，低成本，易管理的特点，网站访客无需安装任何软件，即可在浏览器窗口中与网站的客服人员进行交流。

上述两种客户服务***，虽然在物理层面采用的传输介质不同，但是其内部对客户请求的处理流程是类似的：考虑到客户发起请求的速度和***处理请求的速度可能并不匹配，通常在***内部采用等待队列来缓存客户发出的请求，并将等待队列中的用户请求依次分流到每个客服资源(例如：客服人员)的服务队列中，等待客服资源进行处理，处理完毕，客户还可以按照提示，通过电话按键或者输入文本的方式对本次请求的处理过程进行评价。

上述实现方式简便易行，始终使用一种固定的分流策略，将等待队列中的客户请求依次分流到每个服务队列中，从而可以充分体现公平性，使客服资源得到均等利用。在常规情况下这种分流方式可以满足***的需求，但是在应用场景发生变化(例如：用户请求量增大)的情况下，采用上述单一的分流策略可能会导致客服资源无法得到有效的调配利用，用户的平均等待时长和服务时长都会相应增加，从而影响用户体验。

针对上述问题，现有技术通常在人为判断***处于繁忙状态(即：用户请求量比较大)的情况下，采用人工介入的方式改变分流策略，例如：通过设置分流参数等方式给处理能力强的客服资源分流相对比较多的客户请求，当客户请求总量恢复正常水平后，再通过人工方式恢复原有的分流策略。上述方法可以暂时解决问题，实现客服资源的有效调配，但是每当用户请求量发生较大变化时，都需要人工介入进行调整。由此可见，这种调整方式不灵活，耗时耗力，而且由于人工介入的滞后性，通常很难做到及时调整，不仅无法有效利用***资源，而且会影响用户体验。

发明内容

本申请提供一种用于调整分流策略的方法和装置，以解决现有技术无法根据应用场景的变化自适应地采用相应的分流策略对用户请求进行分流的问题。本申请另外提供一种用于分流用户请求的方法和装置，一种用于分流用户请求的***，以及另一种用于分流用户请求的方法和装置。

本申请提供一种用于调整分流策略的方法，包括：

获取处于等待队列中的用户请求的相关信息；

根据所述用户请求的相关信息选择分流策略，所述分流策略是指，将所述等待队列中的用户请求分流到服务队列所采用的策略；

判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略。

可选的，所述当前采用的分流策略以及所述所选的分流策略分别包括：应急策略、或者普通策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流；所述普通策略则将所述用户请求依次分流到每个服务队列。

可选的，所述用户请求的相关信息包括：用户请求数以及每个用户请求对应的用户等级。

可选的，所述根据所述用户请求的相关信息选择分流策略包括：

根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

判断所述表征***繁忙程度的数值是否不小于预先设定的应急阈值；

若是，将所述应急策略作为所选的分流策略；

若否，将所述普通策略作为所选的分流策略。

可选的，如果所述当前采用的分流策略为普通策略，在将所述当前采用的分流策略调整为所述所选的分流策略之前，在预先设定的第一时间段内，定期执行下述操作：

根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

判断所述数值是否不小于预先设定的应急阈值；

若“否”，终止所述定期执行的操作，并且不执行所述将所述当前采用的分流策略调整为所述所选的分流策略的步骤。

可选的，如果所述当前采用的分流策略为应急策略，在将所述当前采用的分流策略调整为所述所选的分流策略之前，在预先设定的第二时间段内，定期执行下述操作：

根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

判断所述数值是否小于预先设定的应急阈值；

若“否”，终止所述定期执行的操作，并且不执行所述将所述当前采用的分流策略调整为所述所选的分流策略的步骤。

可选的，按照预先设定的时间间隔，定期执行所述获取处于等待队列中的用户请求的相关信息的步骤、所述根据所述用户请求的相关信息选择分流策略的步骤、以及所述判断和调整分流策略的步骤。

相应的，本申请还提供一种用于调整分流策略的装置，包括：

等待队列信息获取单元，用于获取处于等待队列中的用户请求的相关信息；

分流策略选择单元，用于根据所述用户请求的相关信息选择分流策略，所述分流策略是指，将所述等待队列中的用户请求分流到服务队列所采用的策略；

分流策略调整单元，用于判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；

所述分流策略调整单元包括：

策略调整判断子单元，用于判断当前采用的分流策略与所选的分流策略是否不同；

策略调整执行子单元，用于当所述策略调整判断子单元的输出为“不同”时，将所述当前采用的分流策略调整为所述所选的分流策略。

可选的，所述分流策略选择单元包括：

参数计算子单元，用于根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

策略选择执行子单元，用于判断所述表征***繁忙程度的数值是否不小于预先设定的应急阈值；若是，将所述应急策略作为所选的分流策略；若否，将所述普通策略作为所选的分流策略。

可选的，所述分流策略调整单元还包括：

第一调整迟滞子单元，用于当所述当前采用的分流策略为普通策略，并且所述策略调整判断子单元的输出为“不同”时，在预先设定的第一时间段内，定期执行下述操作：根据所述用户请求的相关信息计算表征***繁忙程度的数值，并判断所述数值是否不小于预先设定的应急阈值；若其中有一次所述判断结果为“否”，则终止本子单元的执行，并且不触发所述策略调整执行子单元工作，否则当所述第一时间段结束后，触发所述策略调整执行子单元工作。

可选的，所述分流策略调整单元还包括：

第二调整迟滞子单元，用于当所述当前采用的分流策略为应急策略，并且所述策略调整判断子单元的输出为“不同”时，在预先设定的第二时间段内，定期执行下述操作：根据所述用户请求的相关信息计算表征***繁忙程度的数值，并判断所述数值是否小于预先设定的应急阈值；若其中有一次所述判断结果为“否”，则终止本子单元的执行，并且不触发所述策略调整执行子单元工作，否则当所述第二时间段结束后，触发所述策略调整执行子单元工作。

可选的，所述装置还包括：

定期执行控制单元，用于按照预先设定的时间间隔，定期触发所述等待队列信息获取单元、所述分流策略选择单元、以及所述分流策略调整单元工作。

此外，本申请还提供一种用于分流用户请求的方法，包括：

获取根据等待队列的情况进行自适应调整得到的分流策略；

根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列。

可选的，所述分流策略包括：应急策略、或者普通策略。

可选的，根据等待队列的情况对分流策略进行自适应调整包括：

获取处于等待队列中的用户请求的相关信息；

根据所述用户请求的相关信息选择分流策略；

判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；

上述当前采用的分流策略即为所述根据等待队列的情况进行自适应调整得到的分流策略。

可选的，当所述分流策略为应急策略时，所述根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列，包括：

获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱；

根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

可选的，所述方法还包括：

按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述计算每个服务队列的服务能力值，包括：

针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

计算所有服务队列的权重总和；

用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

可选的，所述与服务队列对应的服务资源处理用户请求的历史数据包括：在特定时间段内处理用户请求的总数、处理用户请求的总时长、和/或用户对处理过程的满意度评价。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述计算所有服务队列的权重总和是指，分别计算每个分组中的所有服务队列的权重总和；

所述用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值是指，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流是指，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

可选的，当所述分流策略为普通策略时，所述根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列是指，将处于等待队列中的用户请求依次分流到每个服务队列中。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述将处于等待队列中的用户请求依次分流到每个服务队列中是指，将所述用户请求依次分流到与其业务类型对应的分组中的每个服务队列中。

相应的，本申请还提供一种用于分流用户请求的装置，包括：

自适应分流策略获取单元，用于获取根据等待队列的情况进行自适应调整得到的分流策略；

用户请求分流单元，用于根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列。

可选的，所述自适应分流策略获取单元获取的分流策略是由策略调整单元生成的，所述策略调整单元包括：

等待队列信息获取子单元，用于获取处于等待队列中的用户请求的相关信息；

分流策略选择子单元，用于根据所述用户请求的相关信息选择分流策略；

分流策略调整子单元，用于判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；所述当前采用的分流策略即为所述策略调整单元生成的分流策略。

可选的，当所述自适应分流策略获取单元获取的分流策略为应急策略时，所述用户请求分流单元包括：

服务能力值获取子单元，用于获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱；

第一分流执行子单元，用于根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

可选的，所述装置还包括：

服务能力值定期计算单元，用于按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述服务能力值定期计算单元包括：

定期计算控制子单元，用于按照预先设定的时间间隔，触发下列队列权重计算子单元、权重总和计算子单元和服务能力值计算子单元工作；

队列权重计算子单元，用于针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

权重总和计算子单元，用于计算所有服务队列的权重总和；

服务能力值计算子单元，用于用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述权重总和计算子单元具体用于，分别计算每个分组中的所有服务队列的权重总和；

所述服务能力值计算子单元具体用于，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述第一分流执行子单元具体用于，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

可选的，当所述自适应分流策略获取单元获取的分流策略为普通策略时，所述用户请求分流单元包括：

第二分流执行子单元，用于将处于等待队列中的用户请求依次分流到每个服务队列中。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述第二分流执行子单元具体用于，将所述用户请求依次分流到与其业务类型对应的分组中的每个服务队列中。

此外，本申请还提供一种用于分流用户请求的***，包括：根据上述任意一项所述的用于调整分流策略的装置；和根据上述任意一项所述的用于分流用户请求的装置；和服务状态监控装置，用于提供等待队列中的用户请求的相关信息；以及等待队列和服务队列。

此外，本申请还提供另一种用于分流用户请求的方法，包括：

获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱；

根据每个服务队列的服务能力值的大小，对用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

可选的，所述方法还包括：

按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述计算每个服务队列的服务能力值，包括：

针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

计算所有服务队列的权重总和；

用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

可选的，所述与服务队列对应的服务资源处理用户请求的历史数据包括：在特定时间段内处理用户请求的总数、处理用户请求的总时长、和/或用户对处理过程的满意度评价。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述计算所有服务队列的权重总和是指，分别计算每个分组中的所有服务队列的权重总和；

所述用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值是指，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述根据每个服务队列的服务能力值的大小，对用户请求进行分流是指，根据每个服务队列的服务能力值的大小，按照用户请求的业务类型将其分流到对应分组的服务队列中。

相应的，本申请还提供另一种用于分流用户请求的装置，包括：

服务能力值获取单元，用于获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱；

用户请求分流执行单元，用于根据每个服务队列的服务能力值的大小，对用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

可选的，所述装置还包括：

服务能力值定期计算单元，用于按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述服务能力值定期计算单元包括：

定期计算控制子单元，用于按照预先设定的时间间隔，触发下列队列权重计算子单元、权重总和计算子单元和服务能力值计算子单元工作；

队列权重计算子单元，用于针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

权重总和计算子单元，用于计算所有服务队列的权重总和；

服务能力值计算子单元，用于用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述权重总和计算子单元具体用于，分别计算每个分组中的所有服务队列的权重总和；

所述服务能力值计算子单元具体用于，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述用户请求分流执行单元具体用于，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

与现有技术相比，本申请具有以下优点：

本申请提供的用于调整分流策略的方法，通过获取处于等待队列中的用户请求的相关信息，根据所述相关信息选择与当前应用场景相适应的分流策略，并对当前采用的分流策略进行必要的调整，从而实现了在不同的应用场景下自动、及时地调整分流策略，解决了现有技术只能固定地采用单一分流策略、以及需要人工介入才能改变分流策略的弊端，为在不同应用场景下自动采用相应的分流策略进行用户请求的分流提供了可能性。

本申请提供的用于分流用户请求的方法，通过获取根据等待队列的情况进行自适应调整得到的分流策略，并根据所述分流策略将处于等待队列中的用户请求分流到相应的服务队列，从而能够自适应地根据不同的分流策略进行分流，尤其应用于在线/热线客户服务***中，通过在设计分流策略时，将客服资源的处理能力及变化纳入考量范围，可以有效利用客服资源、减少用户等待时间和服务处理时间，提升用户满意度。

本申请提供的另一种用于分流用户请求的方法，通过获取表征服务资源处理用户请求能力强弱的服务能力值，并根据所述服务能力值的大小将用户请求分流到相应的服务队列，使得每个服务队列处理的用户请求数量与其服务能力值相匹配，从而实现了对服务资源的有效利用，特别是在***繁忙的状况下，能够从整体上减少用户的平均等待时长和服务时长，提升用户满意度。

附图说明

图1是本申请的一种用于调整分流策略的方法的实施例的流程图；

图2是本申请提供的根据用户请求的相关信息选择分流策略的处理流程图；

图3是本申请提供的引入迟滞时间后调整分流策略的示意图；

图4是本申请的一种用于调整分流策略的装置的实施例的示意图；

图5是本申请的一种用于分流用户请求的方法的实施例的流程图；

图6是本申请提供的采用应急策略对用户请求进行分流的处理流程图；

图7是本申请的一种用于分流用户请求的装置的实施例的示意图；

图8是本申请的一种用于分流用户请求的***的实施例的示意图；

图9是本申请的另一种用于分流用户请求的方法的实施例的流程图；

图10是本申请的另一种用于分流用户请求的装置的实施例的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种用于调整分流策略的方法和装置、一种用于分流用户请求的方法和装置、一种用于分流用户请求的***、以及另一种用于分流用户请求的方法和装置。在下面的实施例中逐一进行详细说明。

请参考图1，其为本申请的一种用于调整分流策略的方法的实施例的流程图。所述方法包括如下步骤：

步骤101：获取处于等待队列中的用户请求的相关信息。

现有的在线/热线客户服务平台(也称在线/热线客服***)，通常采用单一的分流策略将待处理的用户请求逐一分流到每个服务队列，由每个服务队列的客服人员进行处理。本申请提供的用于调整分流策略的方法，通过获取等待队列的相关信息，可以获知***当前的繁忙程度，并且可以据此对当前采用的分流策略进行相应的调整，从而实现了在不同的应用场景下(例如：***繁忙、***空闲等)及时、自适应地调整分流策略，从而解决了通过人工介入方式进行调整耗时、耗力、而且不够及时的问题。

上文以在线/热线客户服务平台为背景，对本申请的技术方案进行了简要说明，然而本申请的技术方案的应用场景并不局限于在线/热线客户服务平台，也可以应用在其他需要将用户请求分流到不同的服务队列、由服务队列对应的服务资源进行处理的应用场景，其中，所述用户请求可以是用户向客服人员提出的咨询或者投诉请求，也可以是其他请求，例如：计算请求，而为服务队列中的请求提供服务的可以是客服人员，也可以是其他形式的服务资源，例如：计算资源等。

本步骤获取处于等待队列中的用户请求的相关信息，为步骤102依据所述信息选择分流策略做好准备。通常情况下，可以认为处于等待队列中的用户请求数可以反映***的繁忙程度(该数值越大，当前***需要处理的用户请求越多，***越繁忙)。此外，发出服务请求的用户等级也可能不同，而等级高的用户请求通常需要得到相对及时地处理，因此用户等级也可以作为反映***繁忙程度的因素之一。基于上述考虑，在本实施例的一个具体例子中，本步骤获取处于等待队列中的用户请求数以及每个用户请求对应的用户等级(取值1～10，该数值越高，代表用户等级越高)。

至于如何获取上述信息，在具体实施中可以采用不同的方式。在处理用户请求的***(例如在线/热线客服***)中，通常会有用于对服务状态进行监控的模块(简称服务状态监控模块)，负责对等待队列和服务队列的相关信息进行实时监控和记录。在本实施例的上述具体例子中，所述服务状态监控模块负责记录当前进入等待队列的用户请求的数目、每个用户请求的相关信息，例如：与用户发出请求时提供的身份信息(身份证号码或者账号等)对应的用户等级信息等，因此本步骤可以直接从所述服务状态监控模块获取处于等待队列中的用户请求的相关信息。

本实施例的上述具体例子中，获取的是处于等待队列中的用户请求数和每个用户请求对应的用户等级，在其他实施方式，可以获取关于等待队列的、不同于上述描述的其他信息，只要根据获取的信息能够直接或者间接地反映出***的繁忙程度，就都可以实现本申请的技术方案，都在本申请的保护范围之内。

步骤102：根据所述用户请求的相关信息选择分流策略。

本申请所述的分流策略是指，将等待队列中的用户请求分流到服务队列所采用的策略，包括：应急策略、或者普通策略；所述应急策略根据服务队列的处理能力对所述用户请求进行分流，使得服务资源能够得到有效的利用，减少用户的等待时间和服务处理时间；所述普通策略则将所述用户请求依次分流到每个服务队列，从而可以实现对服务资源的均等利用。

本步骤根据所述用户请求的相关信息选择相应的分流策略，该过程具体包括如下所述的步骤102-1至步骤102-2，下面结合附图2作进一步说明。

步骤102-1：根据所述用户请求的相关信息，计算表征***繁忙程度的数值。

本步骤根据处于等待队列中的用户请求的相关信息，对***繁忙程度进行量化，即：获取表征***繁忙程度的量化数值。

在本实施例的上述具体例子中，根据在步骤101中获取的用户请求数和每个用户请求对应的用户等级，首先对所述用户请求数按照用户等级进行划分，计算出每个用户等级下的用户请求数，然后采用如下所示的公式进行计算：

--------公式1

其中，N为用户等级(N的取值为1—10)，count(N)为用户等级N下的用户请求数。采用上述公式进行计算，将用户请求数和用户等级都纳入考量范围，计算得到的busy_param数值即为表征***繁忙程度的量化数值。

在本实施例的上述具体例子中，采用上述公式1计算表征***繁忙程度的数值，在其他实施方式中，可以采用不同于公式1的其他公式或者算法进行计算，只要能够根据等待队列中的用户请求的相关信息，得到表征***繁忙程度的数值，就同样能够实现本申请的技术方案。

步骤102-2：判断所述表征***繁忙程度的数值是否不小于预先设定的应急阈值；若是，执行步骤102-3，否则执行步骤102-4。

判断步骤102-1计算得到的数值是否不小于预先设定的应急阈值；如果是，说明当前***比较繁忙，转到相应的处理步骤102-3执行，否则，说明当前***相对比较空闲，转到相应的处理步骤102-4执行。

在本实施例的上述具体例子中，所述预先设定的应急阈值为100000。该数值仅仅是示意性的，在其他实施方式中，可以根据具体的需求以及实际的运行状况，对所述应急阈值的具体取值进行相应的调整和设置。

步骤102-3：将所述应急策略作为所选的分流策略。

本实施例所述的应急策略根据服务队列的处理能力对所述用户请求进行分流，能够充分利用每个服务队列对应的服务资源的处理能力，减少用户的等待时间和服务处理时间，因此本步骤在***繁忙的应用场景下，将所述应急策略作为所选的分流策略。

步骤102-4：将所述普通策略作为所选的分流策略。

所述普通策略将所述用户请求依次分流到每个服务队列，采用这种分流方式简单易行，而且可以做到对服务资源的均等利用，因此本步骤在***相对空闲的应用场景下将所述普通策略作为所选的分流策略。

步骤103：判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略。

所述当前采用的分流策略是指，负责将用户请求分流到服务队列的应用程序或者软件模块当前所使用的分流策略。

步骤102根据等待队列中的用户请求的相关信息，选择了与当前应用场景相适应的分流策略，在本步骤中要进一步判断所述当前采用的分流策略与所选的分流策略是否相同，若相同，说明当前采用的分流策略与当前的应用场景是相适应的，不用执行额外的调整操作；否则，说明当前采用的分流策略不能满足当前应用场景的需求，应该执行调整操作，即：将当前采用的分流策略调整为步骤102中所选的分流策略。

在具体的实施中，所述调整操作可以有多种实现方式，可以将用于指示当前采用的分流策略的变量值，设置为所选分流策略的对应值(例如：应急策略对应数值1，普通策略对应数值2)，负责分流用户请求的应用程序或者软件模块通过访问该变量可以获知应该采用的分流策略；也可以采用消息机制通知负责分流用户请求的应用程序或者软件模块分流策略发生了变更。

考虑到用户请求的发起过程通常是随机事件，因此可能会在短时间内出现用户请求数急剧增加的突发状况，或者是用户请求数急剧减少的突发状况，如果每次通过计算表征***繁忙程度的值检测到上述变化，就立刻执行调整操作，那么在所述短时突发状况结束后，自然还会执行调整操作恢复原来的分流模式。在上述过程中执行的两次调整操作实际上是不必要的，不仅给***带来额外的操作负担，而且可能会影响***的稳定性。

针对上述问题，本实施例提供了一种优选实施方式，即：在执行调整操作之前，引入预先设定的迟滞时间段，从而避免执行不必要的调整操作。

具体说，如果当前采用的分流策略为普通策略，而在步骤102中所选的分流策略为应急策略，此时不立刻执行调整操作，而是在预先设定的第一时间段内，定期获取等待队列中的用户请求的相关信息、并计算表征***繁忙程度的数值，如果某次计算得到的数值小于预先设定的应急阈值，说明***繁忙的应急状态不是稳定状态，而是一过性的突发状态，这种情况下结束在所述第一时间段内定期执行的上述计算和判断操作，并且不调整当前采用的分流策略。相反，如果在预先设定的第一时间段内，每次定期计算得到的表征***繁忙程度的数值都不小于所述应急阈值，则说明当前出现的繁忙状态是一种相对稳定的状态，因此在所述第一时间段结束后，立即执行调整操作，将当前采用的分流策略调整为应急策略，从而使得用户请求能够得到及时地处理。

在本实施例的上述具体例子中，预先设定的第一时间段为10分钟，在该时间段内，每隔1分钟执行上述的计算和判断过程，其中前4次计算得到的表征***繁忙程度的数值都大于预先设定的应急阈值100000，而第5次计算得到的该数值小于100000，说明之前检测到的***繁忙状况仅仅是***容量的短期波动，因此不执行本次调整操作。

同样的道理，如果当前采用的分流策略为应急策略，而在步骤102中所选的分流策略为普通策略，此时不立刻执行调整操作，而是在预先设定的第二时间段内，定期获取等待队列中的用户请求的相关信息、并计算表征***繁忙程度的数值，如果某次计算得到的数值大于或者等于预先设定的应急阈值，则结束在所述第二时间段内定期执行的上述计算和判断操作，并且不调整当前采用的分流策略。相反，如果在预先设定的第二时间段内，每次定期计算得到的表征***繁忙程度的数值都大于或者等于所述应急阈值，则在所述第一时间段结束后，立即执行调整操作，将当前采用的分流策略调整为普通策略。

上述预先设定的第一时间段和第二时间段就是本实施例所述的迟滞时间，通过引入迟滞时间，能够避免短时***容量波动对策略调整带来的不稳定影响，有效保证***的可靠性。请参见附图3，其为引入迟滞时间后调整分流策略的示意图。在采用普通策略的情况下，第一次检测到需要将分流策略调整为应急策略后，经历了一段迟滞时间，在该迟滞时间段中检测到表征***繁忙程度的数值小于应急阈值(说明***出现的繁忙状态是暂时性的)，因此没有执行调整操作。而第二次和第三次在迟滞时间段内检测到***的状态并没有发生变化(处于稳定状态)，因此执行了相应的调整操作。

本实施例中的第一时间段是从普通策略调整为应急策略的迟滞时间，第二时间段是从应急策略调整为普通策略的迟滞时间。在本实施例的上述具体例子中，所述第一时间段预先设定为10分钟，所述第二时间段预先设定为15分钟。

在其他实施方式中，可以参考***长期运行的统计数据对所述第一时间段和第二时间段的值进行设置，既可以根据需要为这两个时间段设置相同的值，也可以设置为不同的值。通常可以这样处理，对于***长期比较饱和的情况(***通常处于繁忙状态)，可以设置第一时间段的值小于第二时间段的值，也就是说***可以相对快速地从普通策略体调整为应急策略，从而保证***资源的最大化利用。

至此，本实施例描述了用于调整分流策略的方法的基本处理流程，在具体实施中，对分流策略的调整通常不是一次性完成的，可以按照预先设定的时间间隔，定期执行上面所述的步骤101-步骤103，从而能够相对实时地检测到***繁忙程度的变化，并及时地进行分流策略的调整。

所述预先设定的时间间隔，也称为应急时间感知时延，在本实施例的上述具体例子中，将其设置为1分钟，从而保证对***繁忙程度变化的感知在分钟级。在其他实施方式中，也可以根据需要为其设置不同的取值。

在上面提供的实施例中，所述应用场景包括***繁忙和与之对应的***空闲这两种状况，相应的分流策略包括：应急策略和普通策略，在其他实施方式中，可以对应用场景作进一步细化或者从其他角度对应用场景进行划分，并针对每种应用场景设定不同的分流策略，这些都属于具体实施方式的变更，都不偏离本申请的核心，都在本申请的保护范围之内。

综上所述，采用本申请提供的用于调整分流策略的方法，通过获取处于等待队列中的用户请求的相关信息，根据所述相关信息选择与当前应用场景相适应的分流策略，并相应地调整当前采用的分流策略，从而实现了在不同的应用场景下自动、及时地调整分流策略，解决了现有技术只能固定地采用单一分流策略、以及需要人工介入才能改变分流策略的弊端，为在不同应用场景下自动采用相应的分流策略进行用户请求的分流提供了可能性。

在上述的实施例中，提供了一种用于调整分流策略的方法，与之相对应的，本申请还提供一种用于调整分流策略的装置。请参看图4，其为本申请的一种用于调整分流策略的装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种用于调整分流策略的装置，包括：等待队列信息获取单元401，用于获取处于等待队列中的用户请求的相关信息；分流策略选择单元402，用于根据所述用户请求的相关信息选择分流策略，所述分流策略是指，将所述等待队列中的用户请求分流到服务队列所采用的策略；分流策略调整单元403，用于判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；

所述分流策略调整单元包括：

策略调整判断子单元，用于判断当前采用的分流策略与所选的分流策略是否不同；

策略调整执行子单元，用于当所述策略调整判断子单元的输出为“不同”时，将所述当前采用的分流策略调整为所述所选的分流策略。

可选的，所述分流策略选择单元包括：

参数计算子单元，用于根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

策略选择执行子单元，用于判断所述表征***繁忙程度的数值是否不小于预先设定的应急阈值；若是，将所述应急策略作为所选的分流策略；若否，将所述普通策略作为所选的分流策略。

可选的，所述分流策略调整单元还包括：

第一调整迟滞子单元，用于当所述当前采用的分流策略为普通策略，并且所述策略调整判断子单元的输出为“不同”时，在预先设定的第一时间段内，定期执行下述操作：根据所述用户请求的相关信息计算表征***繁忙程度的数值，并判断所述数值是否不小于预先设定的应急阈值；若其中有一次所述判断结果为“否”，则终止本子单元的执行，并且不触发所述策略调整执行子单元工作，否则当所述第一时间段结束后，触发所述策略调整执行子单元工作。

可选的，所述分流策略调整单元还包括：

第二调整迟滞子单元，用于当所述当前采用的分流策略为应急策略，并且所述策略调整判断子单元的输出为“不同”时，在预先设定的第二时间段内，定期执行下述操作：根据所述用户请求的相关信息计算表征***繁忙程度的数值，并判断所述数值是否小于预先设定的应急阈值；若其中有一次所述判断结果为“否”，则终止本子单元的执行，并且不触发所述策略调整执行子单元工作，否则当所述第二时间段结束后，触发所述策略调整执行子单元工作。

可选的，所述装置还包括：

定期执行控制单元，用于按照预先设定的时间间隔，定期触发所述等待队列信息获取单元、所述分流策略选择单元、以及所述分流策略调整单元工作。

与上述的一种用于调整分流策略的方法相对应的，本申请还提供一种用于分流用户请求的方法。请参考图5，其为本申请提供的一种用于分流用户请求的方法的实施例的流程图，本实施例与第一实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的一种用于分流用户请求的方法包括：

步骤501：获取根据等待队列的情况进行自适应调整得到的分流策略。

本申请的技术方案，改变了现有技术中只能采用固定的分流策略对用户请求进行分流的现状，可以根据自适应调整得到的与当前应用场景相适应的不同分流策略进行相应的分流。为了实现上述功能，本步骤需要获取根据等待队列的情况进行自适应调整得到的分流策略，从而为步骤502使用所述分流策略对用户请求进行分流做好准备。

所述根据等待队列的情况对分流策略进行自适应调整包括：获取处于等待队列中的用户请求的相关信息；根据所述用户请求的相关信息选择分流策略；判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略。在具体实施时，通过定期地执行上述操作就可以根据不同的应用场景对当前采用的分流策略进行自适应地调整，关于这部分的描述请参见第一实施例中的相关说明，此处不再赘述。通过上述自适应调整得到的分流策略就是执行后续步骤502对用户请求进行分流应该采用的分流策略。

具体到本步骤，获取通过自适应调整得到的分流策略，可以有多种实现方式，例如，实现了本实施例所述的用于分流用户请求的方法的软件模块(称为分流计算处理模块)如果也包含实现上述对分流策略进行自适应调整的功能，那么每次进行分流策略调整时，自然就实时地获知了应该采用的分流策略；如果上述对分流策略进行自适应调整的功能由其他软件模块(称为策略调整模块)实现，那么通过定期访问策略调整模块提供的、用于指示自适应调整得到的分流策略的变量，或者接受该策略调整模块在进行自适应调整后发送的分流策略变更消息等，都可以获取分流用户请求所应该采用的分流策略。

步骤502：根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列。

采用本申请提供的方法，需要根据在步骤501中获取的分流策略，将处于等待队列中的用户请求分流到相应的服务队列。本实施例所述的分流策略包括：应急策略、或者普通策略，下面分别对采用两种分流策略如何对用户请求进行分流作进一步的说明。

(一)应急策略

步骤501获取的分流策略为应急策略，说明当前***处于比较繁忙的状态，处于等待队列中的用户请求数量比较大或者是用户请求的级别比较高、需要得到比较及时地处理，同时考虑到与每个服务队列对应的服务资源的处理能力通常存在差异，例如：在热线/在线客服***中，有的客服人员的处理效率高，有的客服人员的处理效率相对低一些，在这种情况下采用应急策略进行分流，即：按照服务队列对应的服务资源的处理能力对用户请求进行分流，使得服务能力强的客服资源得到充分利用，从整体上看可以降低用户请求的平均等待时长和服务时长。

为了便于描述，将采用应急策略对用户请求进行分流的处理过程分为计算服务能力值、获取服务能力值和根据服务能力值进行分流这三个步骤，下面结合附图6对该处理过程作详细说明。

步骤502-1：计算每个服务队列的服务能力值。

所述每个服务队列的服务能力值，表征所述服务队列对应的服务资源处理用户请求能力的强弱(简称服务队列处理能力的强弱)。可以用于评价所述处理能力强弱的因素有很多，本实施例采用在特定时间段内的以下几项指标参数衡量每个服务队列的处理能力：处理用户请求的总数、处理用户请求的总时长、和用户对处理过程的满意度评价，采用上述指标能够比较全面地反映服务队列的处理能力。

作为一种简便易行的实现方式，可以采用绝对数值作为服务能力值，即：可以为服务能力强的服务队列指定较大的服务能力值，为服务能力相对弱的服务队列指定较小的服务能力值。考虑到服务能力的强弱实际上是一个相对的概念，用每个服务队列的处理能力与本***内所有服务队列的处理能力的比值作为所述服务队列的服务能力值，通常可以更加客观、准确地反映每个服务队列在当前***中的能力状况。

综合上述考虑，本实施例提供了一种计算每个服务队列的服务能力值的一种优选实施方式，包括计算队列权重、计算队列权重总和以及计算权重百分比三个过程，下面分别进行详细说明。

首先，针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重。为了尽可能反映服务队列当前的服务能力，可以获取近期的所述历史数据。在本实施例的一个具体例子中，服务状态监控模块负责对等待队列和服务队列的相关信息进行实时监控和记录，该模块记录了每个服务队列处理用户请求的总数，处理每个用户请求的时长、以及用户在请求处理完毕后通过电话按键或者填写网页表单的方式反馈的满意度评价(对应的数值越大表明越满意)等，因此可以从该模块获取每个服务队列当天(或者距离当前时间24小时之内)的上述历史数据，并按照下述公式计算每个服务队列的权重：

W＝a×(E/N)+b×(N/T) ----------公式2

其中，N为处理用户请求的总数，T为服务总时长(即：处理每个用户请求的时长的总和)，E为满意度评价总和(即：处理过的每个用户请求的满意度评价值的总和)，a和b为加权因子。在该公式中，E/N为满意度评价的平均值，反映服务队列处理用户请求的质量；N/T为单位时间内处理的用户请求数，反映服务队列处理用户请求的效率。通常情况下，这两个数值越大，说明服务队列处理用户请求的能力越强，因此依据这两个数值计算得到的W值可以反映服务队列处理用户请求的能力。

其次，计算所有服务队列的权重总和。采用上述公式2计算出了每个服务队列的权重后，将所有服务队列的权重值相加，即得到所述权重总和。

最后，计算每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。采用这种计算方法得到每个服务队列的权重百分比，可以表征每个服务队列在所有服务队列中的能力状况，例如：权重百分比为20％的服务队列，其处理能力比权重百分比为10％的服务队列要强。本步骤采用每个服务队列的权重百分比作为其服务能力值。

通过上述过程就计算出了每个服务队列的服务能力值，上面给出的用于计算服务能力值的指标、在上述具体例子中采用的计算公式2、以及采用权重百分比的计算方式，都仅仅是一种参考，在具体的实施过程中，可以根据实际需求采用不同的指标参数或者不同的计算方法，只要能够获取表征每个服务队列的处理能力的量化数值，就同样可以实现本申请的技术方案。

需要说明的是，此处为了便于描述，将计算每个服务队列的服务能力值(即本步骤502-1)作为后续步骤502-2和502-3之前的一个步骤进行说明，而在具体实施过程中，本步骤与后续的步骤502-2和502-3通常不是顺序执行的关系。为了能够反映客服资源处理能力的变化，本步骤通常是按照预先设定的时间间隔定期执行的，而步骤502-2和502-3则是在等待队列中有待分流的用户请求的情况下，根据计算得到的服务能力值，实时进行用户请求的分流。

步骤502-2：获取每个服务队列的服务能力值。

根据前面的说明，每个服务队列的服务能力值是定期计算的，因此本步骤可以获取最近一次计算得到的每个服务队列的服务能力值即可，所述服务能力值可以代表每个服务队列对应的服务资源处理用户请求能力的强弱。

步骤502-3：根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

根据每个服务队列的服务能力值的大小对处于等待队列中的用户请求进行分流，其基本原则是：为服务能力强(即：服务能力值相对比较大)的服务队列分配相对较多的用户请求，为服务能力弱(即：服务能力值相对比较小)的服务队列分配相对比较少的用户请求，也就是说使得每个服务队列负责处理的用户请求数量与其服务能力值相匹配，从而能够使服务资源得到充分、有效的利用。

在本实施例的上述具体例子中，采用权重百分比作为每个服务队列的服务能力值，因此可以按照所述权重百分比的比例进行分流。例如：有三个服务队列，其服务能力值分别为0.2、0.5和0.3，那么在具体分流的时候，如果待分流的用户请求有100个，则可以将20个分配给第一个服务队列，50个分配给第二个服务队列，将剩余的30个分配给第三个服务队列。当然也可以采用其他方式进行分流，只要从整体的角度看三个服务队列处理的用户请求数目基本上与上述服务能力值匹配即可。

上述步骤502-1至502-3，描述了在应急策略下对用户请求进行分流的基本处理过程。在实际应用中，用户请求可能分属于不同的业务类型，例如，在热线客服***中，用户可以在发起请求时通过电话按键选择业务类型；而在线客服***可以通过获取用户在网页表单中填写相关问题的简要描述、并对所述简要描述进行语义分析从而获知用户请求对应的业务类型。相应的，每个服务队列能够处理的业务类型可能也不相同，在这种情况下，在分流用户请求时，还需要考虑用户请求与服务队列的业务类型一致的问题。

在本实施例的上述具体例子中，如果服务队列被划分为多个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求，那么在步骤502-1中可以分别计算每个分组中的所有服务队列的权重总和，计算每个服务队列的服务能力值时，则用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值。相应的，在步骤502-3中，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

(二)普通策略

如果在步骤501中获取的分流策略为普通策略，说明当前***处于相对空闲的状态，处于等待队列中的用户请求数量相对比较少或者是用户请求对处理的及时性要求相对比较低，在这种情况下采用普通策略进行分流，即：将处于等待队列中的用户请求依次分流到每个服务队列中，可以使服务资源得到均等利用，体现均一公平性。所述普通策略是现有技术中通常采用的策略，此处不再赘述。

与上述应急策略类似，在用户请求分属于不同的业务类型、而每个服务队列能够处理的业务类型不相同的情况下，本步骤采用普通策略分流用户请求时，可以将所述用户请求依次分流到与其业务类型对应的分组中的每个服务队列中。

上面描述了本申请提供的用于分流用户请求的方法，该方法改变了现有技术采用固定分流策略进行分流的现状，通过获取根据等待队列的情况进行自适应调整得到的分流策略，并根据所述分流策略将处于等待队列中的用户请求分流到相应的服务队列，从而能够自适应地根据不同的分流策略进行分流，尤其应用于在线/热线客户服务***中，通过在设计分流策略时，将客服资源的处理能力及变化纳入考量范围，可以有效利用客服资源、减少用户等待时间和服务处理时间，提升用户满意度。

在上述的实施例中，提供了一种用于分流用户请求的方法，与之相对应的，本申请还提供一种用于分流用户请求的装置。请参看图7，其为本申请的一种用于分流用户请求的装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种用于分流用户请求的装置，包括：自适应分流策略获取单元701，用于获取根据等待队列的情况进行自适应调整得到的分流策略；用户请求分流单元702，用于根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列。

可选的，所述自适应分流策略获取单元获取的分流策略是由策略调整单元生成的，所述策略调整单元包括：

等待队列信息获取子单元，用于获取处于等待队列中的用户请求的相关信息；

分流策略选择子单元，用于根据所述用户请求的相关信息选择分流策略；

分流策略调整子单元，用于判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；所述当前采用的分流策略即为所述策略调整单元生成的分流策略。

可选的，当所述自适应分流策略获取单元获取的分流策略为应急策略时，所述用户请求分流单元包括：

服务能力值获取子单元，用于获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱；

第一分流执行子单元，用于根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

可选的，所述装置还包括：

服务能力值定期计算单元，用于按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述服务能力值定期计算单元包括：

定期计算控制子单元，用于按照预先设定的时间间隔，触发下列队列权重计算子单元、权重总和计算子单元和服务能力值计算子单元工作；

队列权重计算子单元，用于针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

权重总和计算子单元，用于计算所有服务队列的权重总和；

服务能力值计算子单元，用于用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述权重总和计算子单元具体用于，分别计算每个分组中的所有服务队列的权重总和；

所述服务能力值计算子单元具体用于，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述第一分流执行子单元具体用于，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

可选的，当所述自适应分流策略获取单元获取的分流策略为普通策略时，所述用户请求分流单元包括：

第二分流执行子单元，用于将处于等待队列中的用户请求依次分流到每个服务队列中。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述第二分流执行子单元具体用于，将所述用户请求依次分流到与其业务类型对应的分组中的每个服务队列中。

本申请实施例还提供了一种用于分流用户请求的***，如图8所示，该***包括上述实施例所述的用于调整分流策略的装置801、用于分流用户请求的装置802、用于提供等待队列相关信息和服务资源处理用户请求的历史数据的服务状态监控装置803、以及等待队列804和服务队列805。上述各个装置以及等待队列和服务队列可以部署在同一台计算机设备上，例如：服务器上，也可以分别部署在多台计算机设备上，彼此之间通过网络接口通信。下面对上述装置以及队列如何协作实现本***的功能作简要说明。

所述等待队列用于存放待分流的用户请求，所述服务状态监控装置用于对所述等待队列和所述服务队列的状态进行实时监控，并负责记录等待队列中的用户请求的相关信息、以及与服务队列对应的服务资源处理用户请求的历史数据；所述用于调整分流策略的装置，定期从所述服务状态监控装置获取等待队列中的用户请求的相关信息，并根据所述信息判断是否需要调整当前采用的分流策略，如果需要则在经历一段迟滞时间后进行必要的调整操作；所述用于分流用户请求的装置，获取所述用于调整分流策略的装置经过自适应调整得到的分流策略，并根据所述策略将等待队列中的用户请求分流到相应的服务队列中。

通过上面的描述可以看出，本申请提供的用于分流用户请求的***，改变了现有技术只能采用单一分流策略进行分流的状况，实现了分流策略的自适应调整，即：在不同应用场景下，及时、自动地调整分流策略，并采用所述分流策略对用户请求进行分流。

此外，本申请还提供另一种用于分流用户请求的方法。请参考图9，其为本申请提供的另一种用于分流用户请求的方法的实施例的流程图，本实施例与上述实施例步骤相同的部分不再赘述，下面重点描述不同之处。

本申请提供的另一种用于分流用户请求的方法包括：

步骤901：获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱。

在本实施例的一个具体例子中，所述每个服务队列的服务能力值，是按照预先设定的时间间隔，采用如下方式计算得到的：针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；计算所有服务队列的权重总和；用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

所述与服务队列对应的服务资源处理用户请求的历史数据包括：在特定时间段内处理用户请求的总数、处理用户请求的总时长、和/或用户对处理过程的满意度评价。

在本步骤中获取最近一次计算得到的每个服务队列的服务能力值即可，为后续步骤902的执行做好准备。

步骤902：根据每个服务队列的服务能力值的大小，对用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

根据每个服务队列的服务能力值的大小对处于等待队列中的用户请求进行分流，其基本原则是：为服务能力强的服务队列分配相对较多的用户请求，为服务能力弱的服务队列分配相对比较少的用户请求，也就是说使得每个服务队列负责处理的用户请求数量与其服务能力值相匹配，从而能够使服务资源得到充分、有效的利用。

如果服务队列被划分为多个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求，那么在分流用户请求时，还需要考虑用户请求与服务队列的业务类型一致的问题。在本实施例的上述具体例子中，在上述步骤901中分别计算每个分组中的所有服务队列的权重总和，并用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；在本步骤中，根据每个服务队列的服务能力值的大小，按照用户请求的业务类型将其分流到对应分组的服务队列中。

本申请提供的另一种用于分流用户请求的方法，通过获取表征服务资源处理用户请求能力强弱的服务能力值，并根据所述服务能力值的大小将用户请求分流到相应的服务队列，使得每个服务队列处理的用户请求数量与其服务能力值相匹配，从而实现了对服务资源的有效利用，特别是在***繁忙的状况下，能够从整体上减少用户的平均等待时长和服务时长，提升用户满意度。

在上述的实施例中，提供了另一种用于分流用户请求的方法，与之相对应的，本申请还提供另一种用于分流用户请求的装置。请参看图10，其为本申请的另一种用于分流用户请求的装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的另一种用于分流用户请求的装置，包括：服务能力值获取单元1001，用于获取每个服务队列的服务能力值，所述服务能力值表征所述服务队列对应的服务资源处理用户请求能力的强弱；用户请求分流执行单元1002，用于根据每个服务队列的服务能力值的大小，对用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

可选的，所述装置还包括：

服务能力值定期计算单元，用于按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述服务能力值定期计算单元包括：

定期计算控制子单元，用于按照预先设定的时间间隔，触发下列队列权重计算子单元、权重总和计算子单元和服务能力值计算子单元工作；

队列权重计算子单元，用于针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

权重总和计算子单元，用于计算所有服务队列的权重总和；

服务能力值计算子单元，用于用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

可选的，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述权重总和计算子单元具体用于，分别计算每个分组中的所有服务队列的权重总和；

所述服务能力值计算子单元具体用于，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述用户请求分流执行单元具体用于，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (29)

1.一种用于调整分流策略的方法，其特征在于，包括：

获取处于等待队列中的用户请求的相关信息，所述用户请求的相关信息包括：用户请求数以及每个用户请求对应的用户等级；

根据所述用户请求的相关信息选择分流策略，所述分流策略是指，将所述等待队列中的用户请求分流到服务队列所采用的策略；

判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；其中，所述当前采用的分流策略以及所述所选的分流策略分别包括：应急策略、或者普通策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流；所述普通策略则将所述用户请求依次分流到每个服务队列；所述应急策略根据服务队列的处理能力对所述用户请求进行分流，包括：

获取每个服务队列的服务能力值；根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配；其中，所述服务能力值为所述服务队列的处理能力与全部所述服务队列的处理能力的比值，用于表征所述服务队列对应的服务资源处理用户请求能力的强弱。

2.根据权利要求1所述的用于调整分流策略的方法，其特征在于，所述根据所述用户请求的相关信息选择分流策略包括：

根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

判断所述表征***繁忙程度的数值是否不小于预先设定的应急阈值；

若是，将所述应急策略作为所选的分流策略；

若否，将所述普通策略作为所选的分流策略。

3.根据权利要求2所述的用于调整分流策略的方法，其特征在于，如果所述当前采用的分流策略为普通策略，在将所述当前采用的分流策略调整为所述所选的分流策略之前，在预先设定的第一时间段内，定期执行下述操作：

根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

判断所述数值是否不小于预先设定的应急阈值；

若“否”，终止所述定期执行的操作，并且不执行所述将所述当前采用的分流策略调整为所述所选的分流策略的步骤。

4.根据权利要求2所述的用于调整分流策略的方法，其特征在于，如果所述当前采用的分流策略为应急策略，在将所述当前采用的分流策略调整为所述所选的分流策略之前，在预先设定的第二时间段内，定期执行下述操作：

根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

判断所述数值是否小于预先设定的应急阈值；

若“否”，终止所述定期执行的操作，并且不执行所述将所述当前采用的分流策略调整为所述所选的分流策略的步骤。

5.根据权利要求1所述的用于调整分流策略的方法，其特征在于，按照预先设定的时间间隔，定期执行所述获取处于等待队列中的用户请求的相关信息的步骤、所述根据所述用户请求的相关信息选择分流策略的步骤、以及所述判断和调整分流策略的步骤。

6.一种用于调整分流策略的装置，其特征在于，包括：

等待队列信息获取单元，用于获取处于等待队列中的用户请求的相关信息，所述用户请求的相关信息包括：用户请求数以及每个用户请求对应的用户等级；

分流策略选择单元，用于根据所述用户请求的相关信息选择分流策略，所述分流策略是指，将所述等待队列中的用户请求分流到服务队列所采用的策略；

分流策略调整单元，用于判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；

所述分流策略调整单元包括：

策略调整判断子单元，用于判断当前采用的分流策略与所选的分流策略是否不同；

策略调整执行子单元，用于当所述策略调整判断子单元的输出为“不同”时，将所述当前采用的分流策略调整为所述所选的分流策略；其中，所述当前采用的分流策略以及所述所选的分流策略分别包括：应急策略、或者普通策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流；所述普通策略则将所述用户请求依次分流到每个服务队列；所述应急策略根据服务队列的处理能力对所述用户请求进行分流，包括：

获取每个服务队列的服务能力值；根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配；其中，所述服务能力值为所述服务队列的处理能力与全部所述服务队列的处理能力的比值，用于表征所述服务队列对应的服务资源处理用户请求能力的强弱。

7.根据权利要求6所述的用于调整分流策略的装置，其特征在于，所述分流策略选择单元包括：

参数计算子单元，用于根据所述用户请求的相关信息，计算表征***繁忙程度的数值；

策略选择执行子单元，用于判断所述表征***繁忙程度的数值是否不小于预先设定的应急阈值；若是，将所述应急策略作为所选的分流策略；若否，将所述普通策略作为所选的分流策略。

8.根据权利要求7所述的用于调整分流策略的装置，其特征在于，所述分流策略调整单元还包括：

第一调整迟滞子单元，用于当所述当前采用的分流策略为普通策略，并且所述策略调整判断子单元的输出为“不同”时，在预先设定的第一时间段内，定期执行下述操作：根据所述用户请求的相关信息计算表征***繁忙程度的数值，并判断所述数值是否不小于预先设定的应急阈值；若其中有一次所述判断结果为“否”，则终止本子单元的执行，并且不触发所述策略调整执行子单元工作，否则当所述第一时间段结束后，触发所述策略调整执行子单元工作。

9.根据权利要求7所述的用于调整分流策略的装置，其特征在于，所述分流策略调整单元还包括：

第二调整迟滞子单元，用于当所述当前采用的分流策略为应急策略，并且所述策略调整判断子单元的输出为“不同”时，在预先设定的第二时间段内，定期执行下述操作：根据所述用户请求的相关信息计算表征***繁忙程度的数值，并判断所述数值是否小于预先设定的应急阈值；若其中有一次所述判断结果为“否”，则终止本子单元的执行，并且不触发所述策略调整执行子单元工作，否则当所述第二时间段结束后，触发所述策略调整执行子单元工作。

10.根据权利要求6所述的用于调整分流策略的装置，其特征在于，所述装置还包括：

定期执行控制单元，用于按照预先设定的时间间隔，定期触发所述等待队列信息获取单元、所述分流策略选择单元、以及所述分流策略调整单元工作。

11.一种用于分流用户请求的方法，其特征在于，包括：

获取处于等待队列中的用户请求的相关信息；

根据所述用户请求的相关信息选择分流策略；

判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；

根据所选的所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列；其中，所述当前采用的分流策略以及所述所选的分流策略分别包括：应急策略、或者普通策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流；所述普通策略则将所述用户请求依次分流到每个服务队列；所述应急策略根据服务队列的处理能力对所述用户请求进行分流，包括：

获取每个服务队列的服务能力值；根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配；其中，所述服务能力值为所述服务队列的处理能力与全部所述服务队列的处理能力的比值，用于表征所述服务队列对应的服务资源处理用户请求能力的强弱。

12.根据权利要求11所述的用于分流用户请求的方法，其特征在于，还包括：

按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述计算每个服务队列的服务能力值，包括：

针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

计算所有服务队列的权重总和；

用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

13.根据权利要求12所述的用于分流用户请求的方法，其特征在于，所述与服务队列对应的服务资源处理用户请求的历史数据包括：在特定时间段内处理用户请求的总数、处理用户请求的总时长、和/或用户对处理过程的满意度评价。

14.根据权利要求12所述的用于分流用户请求的方法，其特征在于，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述计算所有服务队列的权重总和是指，分别计算每个分组中的所有服务队列的权重总和；

所述用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值是指，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流是指，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

15.根据权利要求11所述的用于分流用户请求的方法，其特征在于，当所述分流策略为所述普通策略时，所述根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列是指，将处于等待队列中的用户请求依次分流到每个服务队列中。

16.根据权利要求15所述的用于分流用户请求的方法，其特征在于，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述将处于等待队列中的用户请求依次分流到每个服务队列中是指，将所述用户请求依次分流到与其业务类型对应的分组中的每个服务队列中。

17.一种用于分流用户请求的装置，其特征在于，包括：

等待队列信息获取子单元，用于获取处于等待队列中的用户请求的相关信息；

分流策略选择子单元，用于根据所述用户请求的相关信息选择分流策略；

分流策略调整子单元，用于判断当前采用的分流策略与所选的分流策略是否不同；若不同，将所述当前采用的分流策略调整为所述所选的分流策略；

用户请求分流单元，用于根据所述分流策略，将处于等待队列中的用户请求分流到相应的服务队列；其中，所述当前采用的分流策略以及所述所选的分流策略分别包括：应急策略、或者普通策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流；所述普通策略则将所述用户请求依次分流到每个服务队列；

自适应分流策略获取单元，用于获取根据等待队列的情况进行自适应调整得到的分流策略，所述自适应分流策略获取单元获取的分流策略是由策略调整单元生成的，所述策略调整单元包括：所述等待队列信息获取子单元、所述分流策略选择子单元、所述分流策略调整子单元；

当所述自适应分流策略获取单元获取的分流策略为所述应急策略时，所述用户请求分流单元包括：

服务能力值获取子单元，用于获取每个服务队列的服务能力值，所述服务能力值为所述服务队列的处理能力与全部所述服务队列的处理能力的比值，用于表征所述服务队列对应的服务资源处理用户请求能力的强弱；

第一分流执行子单元，用于根据每个服务队列的服务能力值的大小，对所述处于等待队列中的用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配。

18.根据权利要求17所述的用于分流用户请求的装置，其特征在于，所述装置还包括：

服务能力值定期计算单元，用于按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述服务能力值定期计算单元包括：

定期计算控制子单元，用于按照预先设定的时间间隔，触发下列队列权重计算子单元、权重总和计算子单元和服务能力值计算子单元工作；

队列权重计算子单元，用于针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

权重总和计算子单元，用于计算所有服务队列的权重总和；

服务能力值计算子单元，用于用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

19.根据权利要求18所述的用于分流用户请求的装置，其特征在于，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述权重总和计算子单元具体用于，分别计算每个分组中的所有服务队列的权重总和；

所述服务能力值计算子单元具体用于，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述第一分流执行子单元具体用于，根据每个服务队列的服务能力值的大小，按照所述处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。

20.根据权利要求17所述的用于分流用户请求的装置，其特征在于，当所述自适应分流策略获取单元获取的分流策略为所述普通策略时，所述用户请求分流单元包括：

第二分流执行子单元，用于将处于等待队列中的用户请求依次分流到每个服务队列中。

21.根据权利要求20所述的用于分流用户请求的装置，其特征在于，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述第二分流执行子单元具体用于，将所述用户请求依次分流到与其业务类型对应的分组中的每个服务队列中。

22.一种用于分流用户请求的***，其特征在于，包括：如上述权利要求6所述的用于调整分流策略的装置；和

如上述权利要求17所述的用于分流用户请求的装置；和

服务状态监控装置，用于提供等待队列中的用户请求的相关信息；以及

等待队列和服务队列。

23.一种用于分流用户请求的方法，其特征在于，包括：

获取每个服务队列的服务能力值，所述服务能力值为所述服务队列的处理能力与全部所述服务队列的处理能力的比值，用于表征所述服务队列对应的服务资源处理用户请求能力的强弱；

根据每个服务队列的服务能力值的大小，以及用户请求的相关信息选择分流策略，对所述用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配，其中，所述分流策略为应急策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流。

24.根据权利要求23所述的用于分流用户请求的方法，其特征在于，还包括：

按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述计算每个服务队列的服务能力值，包括：

针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

计算所有服务队列的权重总和；

用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

25.根据权利要求24所述的用于分流用户请求的方法，其特征在于，所述与服务队列对应的服务资源处理用户请求的历史数据包括：在特定时间段内处理用户请求的总数、处理用户请求的总时长、和/或用户对处理过程的满意度评价。

26.根据权利要求24所述的用于分流用户请求的方法，其特征在于，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述计算所有服务队列的权重总和是指，分别计算每个分组中的所有服务队列的权重总和；

所述用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值是指，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述根据每个服务队列的服务能力值的大小，对用户请求进行分流是指，根据每个服务队列的服务能力值的大小，按照用户请求的业务类型将其分流到对应分组的服务队列中。

27.一种用于分流用户请求的装置，其特征在于，包括：

服务能力值获取单元，用于获取每个服务队列的服务能力值，所述服务能力值为所述服务队列的处理能力与全部所述服务队列的处理能力的比值，用于表征所述服务队列对应的服务资源处理用户请求能力的强弱；

用户请求分流执行单元，用于根据每个服务队列的服务能力值的大小，以及用户请求的相关信息选择分流策略，对所述用户请求进行分流，使得每个服务队列处理的用户请求数量与其服务能力值相匹配，其中，所述分流策略为应急策略；

所述应急策略根据服务队列的处理能力对所述用户请求进行分流。

28.根据权利要求27所述的用于分流用户请求的装置，其特征在于，所述装置还包括：

服务能力值定期计算单元，用于按照预先设定的时间间隔，定期计算每个服务队列的服务能力值；

所述服务能力值定期计算单元包括：

定期计算控制子单元，用于按照预先设定的时间间隔，触发下列队列权重计算子单元、权重总和计算子单元和服务能力值计算子单元工作；

队列权重计算子单元，用于针对每个服务队列，获取与所述服务队列对应的服务资源处理用户请求的历史数据，并根据所述历史数据计算所述服务队列的权重；

权重总和计算子单元，用于计算所有服务队列的权重总和；

服务能力值计算子单元，用于用每个服务队列的权重与所述权重总和的比值，作为所述服务队列的服务能力值。

29.根据权利要求28所述的用于分流用户请求的装置，其特征在于，所述每个服务队列属于一个服务队列分组，不同的服务队列分组负责处理不同业务类型的用户请求；

相应的，所述权重总和计算子单元具体用于，分别计算每个分组中的所有服务队列的权重总和；

所述服务能力值计算子单元具体用于，用每个服务队列的权重与其所在分组的权重总和的比值，作为所述服务队列的服务能力值；

所述用户请求分流执行单元具体用于，根据每个服务队列的服务能力值的大小，按照处于等待队列中的用户请求的业务类型将其分流到对应分组的服务队列中。