CN101938396A - 数据流控制方法及装置 - Google Patents

Abstract

本发明实施例提供一种数据流控制方法以及装置。其中，数据流控制方法，包括根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值；将所述动态数据流阈值配置给对应的数据池，以对所述数据池对应级别的业务数据流进行控制。由于可以对不同级别业务的数据池配置动态数据流阈值，使得可以更灵活地为不同的级别业务提供不同的数据流控制，同时不需要业务接入系统，节约了业务接入的系统资源占用。

Description

数据流控制方法及装置

技术领域

本发明涉及过负荷控制技术领域，尤其涉及一种数据流控制方法及装置。

背景技术

过负荷通常是指，系统承受的压力大于或等于了预先设定的可承受压力阈值，如，系统最高处理能力阈值是每秒处理10万条消息，但在某个时刻，可能需要处理20万条消息，这就产生了过负荷，如果不对过负荷进行控制，则可能导致系统瘫痪无法工作等等。所以，提出了过负荷控制机制，避免过负荷带来的损害。

目前，过负荷控制机制，通常是设定过负荷阈值，如CPU占用阈值，以及过负荷控制策略，如一旦过负荷，则拒绝接入业务。在系统运行中，利用检测程序对系统的CPU占用进行检测，当检测到CPU占用大于或等于设定阈值，则检测程序修改寄存器的控制标志位，以指示过负荷。每个业务在执行前，需要查看当前的控制标志位，如果过负荷，则决定拒绝该业务请求，避免导致系统无法工作；如果未过负荷，则决定接收该业务请求。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

由于过负荷控制机制，一旦系统过负荷，则拒绝接入所有业务，即无论是何种业务，一律拒绝接入，CPU占用迅速下降，一旦系统恢复正常后，所有业务又都可以接入，CPU占用迅速上升，导致系统又过负荷，周而复始，业务抖动严重，过负荷控制效果不好。

而且，系统需要接入业务请求，以使业务代码在业务入口层代码调用API(Application Programming Interface，应用程序接口)获取控制标志位，得知是否过负荷，而系统接入业务请求必然消耗掉很多资源，如，SOAP(Simple Object Access Protocol，简单对象访问协议)封包解包、数据格式(XSD，XML Schema Definition，XML文档结构定义)校验处理，等等，一定程度上又增加了系统的负荷，过负荷控制效果不好。

发明内容

本发明的实施例提供了一种数据流控制方法及装置，数据流控制效果好。

一种数据流控制方法，包括：

根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值；

将所述动态数据流阈值配置给对应的数据池，以对所述数据池对应级别的业务数据流进行控制。

一种数据流控制装置，包括：

数据流阈值获取单元，用于获取至少一个级别业务的数据池对应的动态数据流阈值；

控制单元，用于将所述动态数据流阈值配置给对应的数据池，以对所述数据池对应级别的业务数据流进行控制。

由上述本发明的实施例提供的技术方案可以看出，数据流控制方法及装置，由于可以对业务划分级别并分配数据池，以及通过对不同级别业务的数据池配置动态数据流阈值，对不同级别业务的数据流进行控制，所以，可以为不同的级别业务提供不同的数据流控制，数据流控制灵活、效果好。同时，数据流控制方法及装置不需要业务接入系统，节约了业务接入的系统资源占用。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例数据流控制方法流程示意图；

图2为本发明实施例数据流控制方法中线程池接收或释放线程的示意图；

图3为本发明实施例数据流控制方法应用场景示意图一；

图4为本发明实施例数据流控制方法应用场景示意图二；

图5为本发明实施例数据流控制方法应用场景示意图三；

图6为本发明实施例数据流控制装置构成结构示意图一；

图7为本发明实施例数据流控制装置构成结构示意图二。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

基于现有技术的过负荷控制机制，系统过负荷，则拒绝接入所有业务请求，过负荷控制效果不好，以及需要业务接入系统，再进行过负荷控制，增加系统负荷的缺陷。

本发明的实施例提供的数据流控制方法及装置，对业务划分级别并分配数据池，以及对不同级别业务的数据池配置动态数据流阈值，不仅不需要业务接入系统，而且，可以对业务划分级别并对不同级别业务的数据池配置动态数据流阈值，对不同级别业务的数据流进行控制，数据流控制灵活、效果好。

如图1所示，本发明实施例提供一种数据流控制方法，包括：

步骤101：根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值。

步骤102：将动态数据流阈值配置给对应的数据池，以对数据池对应级别的业务数据流进行控制。

由上述方案可以知道，根据系统的负荷状态，可以实现对一个或多个级别业务的数据流进行控制，不再是所有业务都同一控制。而且，对各级别业务的数据流进行控制的动态数据流阈值是与级别业务相对应的，这样，可以实现按照级别对业务的数据流进行控制，使得对不同级别业务的数据流的控制更灵活、适用。

还可以知道，本发明实施例提供的数据流控制方法不需要业务接入系统，节约了业务接入的系统资源占用。

本发明实施例提供的数据流控制方法，可以较佳地应用于多线程机制或多消息机制的系统中，线程池或消息池都需要遵循一定的派发机制，即通过某一管理器创建并管理线程池或消息池的工作线程或消息。那么，数据流池可以包括线程池或消息池，动态数据流阈值可以包括动态线程数或动态消息数。

可选的：上述方法在步骤101之前还包括：

根据业务的类型、业务的重要性、业务的Qos((Quality of Service，服务质量)中的至少一个为业务划分级别。应当知道，业务级别的划分依据，不限于此。

根据上述业务级别，为业务分配对应的数据池，并为数据池预设数据流阈值，数据流阈值表明该数据池的能够承受的最大业务数据流值。例如：为高级别的业务分配的数据流阈值也比较大一些，低级别的业务分配的数据流阈值比较小一些；这样，实现为不同级别的业务分配不同的数据池，使得不同级别的业务的接入相分离，一旦一个数据池的通道因故障导致该级别的业务无法接入，而不会影响到其他级别业务的接入，达到故障隔离的效果。

根据业务级别，为业务对应的数据池配置至少一个动态数据流阈值，动态数据流阈值包括第一动态数据流阈值以及第二动态数据流阈值，第一动态数据流阈值小于所述数据流阈值，第二动态数据流阈值小于或等于所述数据流阈值。

上述基于本发明实施例提供的数据流控制方法，可以较佳地应用于多线程机制或多消息机制的系统中。进一步，上述步骤中的数据流阈值可以包括最大线程数或最大消息数，第一动态数据流阈值可以包括第一动态线程数或第一动态消息数，第二动态数据流阈值可以包括第二动态线程数或第二动态消息数。

如果在上述步骤中属于同一级别的业务为至少两个时，为各业务的数据流设置子数据流阈值，子数据流阈值小于数据池的数据流阈值，以控制各业务的数据流共享数据池。进一步，子数据流阈值可以包括子线程数或子消息数。

示例性的，如2个业务的级别相同，其二者共用一个数据池为例，如数据池的数据流阈值为150，则可以为各业务设置子数据流阈值为100，这样才可以保证通道不会完全被某一类业务故障堵死。在保证2/3的通道占用的前提下，可以保留1/3(线程数为50)的通道对于其它业务是可用的。

可选的，在根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值的步骤101之前，还可以包括：

通过检测并比较CPU(Central Processing Unit，中央处理单元)占用与预设CPU最大占用，或数据流请求的时延与预设最大时延、或数据流请求的等待队列长度与预设最大等待队列长度，或业务QoS与预设QoS，确定系统的负荷状态，业务QoS为业务平均响应时长、业务及时响应率或业务成功率。

具体而言，如果CPU占用大于等于预设CPU最大占用，或数据流请求的时延大于等于预设最大时延、或数据流请求的等待队列长度大于等于预设最大等待队列长度，或业务平均响应时长大于等于预设业务平均响应时长，或业务及时响应率小于等于预设业务及时响应率，或业务成功率小于等于预设业务成功率时，可以认为，系统的负荷状态为过负荷状态。

相应地，如果CPU占用小于预设CPU最大占用，或数据流请求的时延小于预设最大时延、或数据流请求的等待队列长度小于预设最大等待队列长度，或业务平均响应时长小于预设业务平均响应时长，或业务及时响应率大于预设业务及时响应率，或业务成功率大于预设业务成功率时，可以认为，系统的负荷状态为未过负荷状态。

由上描述，根据上述步骤获得的系统负荷状态，上述步骤101，进一步，可以具体包括：

当系统处于过负荷状态时，按照业务级别的高低排序，先获取低级别业务的数据池对应的第一动态数据流阈值。

或者，当系统恢复处于未过负荷状态时，按照业务级别的高低排序，先获取高级别业务的数据池对应的第二动态数据流阈值。

具体而言，当系统处于过负荷状态时，可以按照业务级别的高低排序，优先获取低级别业务的数据池对应的第一动态数据流阈值。由于第一动态数据流阈值小于数据流阈值，步骤102中，将第一动态数据流阈值配置给对应的数据池，即相当于将低级别业务的数据池的接收并发请求的能力降低了，则新的业务请求无法接入，则被放入等待队列，甚至可以因为等待时间长超时而被拒绝接入，这样系统的负荷也就随之下降了。

按照业务级别的高低排序，优先获取低级别业务的数据池对应的第一动态数据流阈值，并配置给对应的数据池，是为了对高级别业务的接入保障，这样，优先控制低级别业务的接入，保障了高级别业务的接入，并同时降低了系统的负荷。

另外，为各级别业务的第一动态数据流阈值可以相同或不同，根据不同的控制策略而定。

对应地，当系统恢复处于未过负荷状态时，可以按照业务级别的高低排序，优先获取高级别业务的数据池对应的第二动态数据流阈值。由于第二动态数据流阈值小于或等于所述数据流阈值，而且，之前由于系统处于过负荷状态，各级别业务的数据池的接收并发请求的能力被配置的第一动态数据流阈值降低了，所以步骤102中，将第二动态数据流阈值配置给对应的数据池，即相当于将高级别业务的数据池的接收并发请求的能力提高了，则新的业务请求可以接入，这样系统的能力被合理利用。按照业务级别的高低排序，优先获取高级别业务的数据池对应的第二动态数据流阈值，并配置给对应的数据池，是为了对高级别业务的接入保障。

另外，为各级业务配置的第二动态数据流阈值可以相同或不同，根据不同的控制策略而定。

具体而言，上述过程中，可以通过连续检测一次以上的CPU占用、数据流请求的时延、数据流请求的等待队列长度或业务QoS，再比较CPU占用、数据流请求的时延、数据流请求的等待队列长度或业务QoS与预设最大CPU占用、预设最小时延、预设最小等待队列长度或预设业务QoS，通过每次的比较结果，判断系统是否处于过负荷状态，得到准确可靠的判断结果。如果只是偶尔一次发现系统处于过负荷状态，可以不必立即进行数据流控制。

综上所述，本发明实施例提供的数据流控制方法，根据系统的负荷状态，可以实现对一个或多个级别业务的数据流进行控制，不再是所有业务都同一控制。而且，对各级别业务的数据流进行控制的动态数据流阈值是与级别业务相对应的，这样，可以实现按照级别对业务的数据流进行控制，使得对不同级别业务的数据流的控制更灵活、适用。

本发明实施例提供的数据流控制方法，数据流控制平稳，避免了现有技术中，一旦系统过负荷之后，所有业务都拒绝接入，导致业务变化突变，一旦系统恢复正常后，所有业务都接收接入，产生业务抖动。

如图2所示，以于单个线程池为例，说明本发明实施例提供的数据流控制方法，如何对数据池对应级别的业务数据流进行控制。

当某一级别业务的线程池中已创建的线程数还没有达到最大线程数时，系统可以接入新的业务请求，创建新的线程来处理业务，也就是系统有多余的能力处理新的业务请求，也意味着系统的并发请求处理能力在增加。

当系统负荷随着并发业务请求的增加而出现过负荷时，可以为线程池配置第一动态线程数，该第一线程数小于最大线程数，这样，线程池可允许的并发请求处理能力相当于被调低了，这样新的业务请求因为没有线程可用，则被放入等待队列，甚至新的业务请求可以因为等待时间长超时而被拒绝接入，这样系统的负荷也就随之下降了。当线程池的第一动态线程数为1时，业务就变成单线程串行执行了，线程池可允许的并发请求处理能力到达最低。

再随着时间推移，线程池已有的线程执行完成后，变为空闲线程，系统负荷恢复正常状态，可以为线程池配置第二动态线程数，该第二线程数小于或等于最大线程数，这样，相当于调高了线程池可允许的并发请求处理能力，线程池释放出空闲线程，以恢复系统接收并发请求的能力。

注意，当线程池的第二动态线程数等于最大线程数时，系统恢复达到接收最大并发请求的能力。

通过上述描述，本发明的实施例提供的数据流控制方法，可以对业务划分级别并分配数据池，以及对不同级别业务的数据池配置动态数据流阈值，实现不同级别业务的数据流控制。

示例性的，如目前基于J2EE的JAVA(Java 2Platform Enterprise Edition Java，企业应用平台)系统，适用于本发明的实施例提供的数据流控制方法。J2EE的JAVA系统是单进程多线程的机制，同时在系统中运行多种业务，以电话营业厅为例，营业业务包括开户，销户，查询余额，挂失，解挂失等多种业务，还有系统后台的定时批量任务，比如月结，批量预开户等，业务复杂多样，各种业务的占用数据流量都不一样。

同理，根据本发明实施例的数据流控制方法，还可以结合应用该方法到后台定时任务的执行，即可以将后台定时任务分级别，按照级别高低排序，与前台的数据流控制方法结合进行控制。

具体而言，如在系统处于过负荷状态时，如果有后台定时任务在执行，则根据后台定时任务的级别，可以先暂不执行级别低的后台定时任务，如果还过负荷，可以再按照任务级别，逐级暂停后台定时任务。而在系统业务压力下降时，可以恢复后台定时任务继续执行。

也可以，在对前台业务分级别的进行控制时，同步对后台定时任务也分级别的进行控制，等等。具体的结合控制策略，不受上述示例限制。

结合参见图3所示，具体以为各级别业务分配线程池，以及为各级别业务的线程池配置3级第一动态线程数及第二动态线程数，来说明本发明实施例的数据流控制方法。

仍以电话营业厅为例，营业业务包括开户，销户，查询余额，挂失，解挂失等多种，还可以有系统后台的定时批量任务，比如月结，批量预开户等业务。

301、按照业务的重要性对业务进行分级。

可以按业务的重要性对业务进行分级，如级别从高到低排序为：

第1级：后台系统间实时调用接口(查询接口，比如查询余额)；

第2级：后台系统间实时调用接口(如调帐业务)；

第3级：营业前台网络(Web)请求；

第4级：管理业务接口(开户，挂失等)；

第5级：批量业务接口(批量开户，批量消户)。

如果有后台定时任务，则也可以根据后台定时任务的级别对后台业务进行分级。

如后台定时任务，按照级别从高到低排序为：月结业务、批量预开户业务。

302、为各级别业务分配线程池。

可以根据业务级别，为每个级别的业务分配线程池，并可以为各线程池预设最大线程数，最大线程数表明线程池的接收最大并发请求的能力。

303、为各级别业务的线程池配置第一动态线程数及第二动态线程数。

可以根据业务级别，为每个业务的线程池配置第一动态线程数及第二动态线程数。

每个业务的线程池的第一动态线程数小于线程池的最大线程数，系统处于过负荷状态时，通过为线程池配置第一动态线程数，调低线程池可允许的并发请求处理能力，以降低系统负荷。

每个业务的线程池的第二动态线程数小于或等于线程池的最大线程数，系统恢复处于未过负荷状态时，通过为线程池配置第二动态线程数，提高线程池可允许的并发请求处理能力，以使系统恢复负荷能力。

可以为各级别业务的线程池配置多个第一动态线程数，系统处于过负荷状态时，实现分级对各级别业务控制，如下表1所示：

表1：

注意，当线程池的第一动态线程数为1时，业务就变成单线程串行执行了。

同理，可以为各级别业务的线程池配置多个第二动态线程数，系统恢复处于未过负荷状态时，实现分级对各级别业务恢复，如下表1所示：如下表2所示：

表2：

注意，当线程池的第二动态线程数为最大线程数时，线程池接收并发请求的能力完全恢复。

参考上述图3对应实施例的描述内容，仍以电话营业厅为例，营业业务包括开户，销户，查询余额，挂失，解挂失等多种，还可以有系统后台的定时批量任务，比如月结，批量预开户等业务，各级别业务分配有线程池，各线程池配置有最大线程数、第一动态线程数及第二动态线程数。并结合参见图4所示，在系统处于过负荷状态时，说明本发明实施例的数据流控制方法。

401、检测单元检测CPU占用情况，并将检测结果发生给系统负荷状态判断单元，检测结果可以为CPU占用值。

402、系统负荷状态判断单元根据检测结果判断系统是否过负荷，并将过负荷的判断结果发送给告警单元。

系统负荷状态判断单元接收到检测单元发送的检测结果，如果CPU占用值大于等于预设CPU最大占用值，系统处于过负荷状态。如果CPU占用值小于预设CPU最大占用值，系统处于未过负荷状态，则结束该数据流控制。

403、告警单元连续接收到判断结果，并确认判断结果满足告警条件，向控制单元发出告警信息。

告警条件，可以为连续接收到几次(例如本发明实施例为3次)系统负荷状态判断单元发送的过负荷状态判断结果。也就是，检测单元连续检测3次CPU占用，系统负荷状态判断单元连续3次发现CPU占用值均大于或等于预设CPU最大占用值时，则可以确认系统处于过负荷状态。

告警单元可以向控制单元发出告警信息，也可以是控制事件监听单元(图中未示)获取告警信息，并告知控制单元系统处于过负荷状态。

404、控制单元根据告警信息启动第一级控制。

控制单元接收到告警信息后，控制单元从数据流阈值获取单元获得第一动态线程数，控制单元启动第一级控制。如，控制单元可以对第5级的批量业务接口(批量开户，批量消户)的业务的线程池，配置第一动态线程数，第一动态线程数可以为线程池的最大线程数的80％。

由于第一动态线程数小于最大线程数，相当于第5级业务的线程池接收并发请求能力被调低了，这样新的业务请求因为没有线程可用，则被放入等待队列或因为等待时间长超时而被拒绝接入，所以，系统的负荷也就随之下降了。而且，第1-4级的高级别业务的线程池的最大线程数没有被限制，可以较佳的保证高级别业务的接入。

405、在启动第一级控制后，检测单元重新检测CPU占用，并将检测结果发生给系统负荷状态判断单元，检测结果可以为CPU占用值。

406、系统负荷状态判断单元根据检测结果判断系统是否过负荷，并将过负荷的判断结果发送给告警单元。

在第一级控制之后，系统负荷状态判断单元接收到判断结果，并重新比较检测单元重新发送的CPU占用值与预设CPU最大占用值，如果CPU占用值小于预设CPU最大占用值，系统恢复处于未过负荷状态，则结束数据流控制。

如果CPU占用值仍大于或等于预设CPU最大占用值，系统仍然处于过负荷状态。

407、告警单元接收到判断结果，并确认满足告警条件，向控制单元发出告警信息。

告警单元接收系统负荷状态判断单元发送的过负荷的判断结果，并且确认判断结果是否满足告警条件。此时的告警条件，可以为接收到一次系统负荷状态判断单元发送的过负荷状态判断结果。

408、控制单元根据告警信息启动第二级控制。

控制单元接收到告警信息后，控制单元从数据流阈值获取单元处获得第一动态线程数，控制单元启动第二级控制。如，控制单元再次对第5级的批量业务接口(批量开户，批量消户)的业务的线程池，配置第一动态线程数，如将已经调低的线程数再次调低50％。

由于第一动态线程数小于最大线程数，相当于第5级业务的线程池接收并发请求能力再次被调低了，这样新的业务请求因为没有线程可用，则被放入等待队列或因为等待时间长超时而被拒绝接入，这样系统的负荷再次下降。同样，较佳的保证第1-4级业务的接入不受影响。

或者，第二级控制还可以为：控制单元还可以对第4级的管理业务接口(开户，挂失等)的业务的线程池配置第一动态线程数，如第一动态线程数可以为该线程池的最大线程数的80％。新的业务请求因为没有线程可用，则被放入等待队列或因为等待时间长超时而被拒绝接入，这样系统的负荷再次下降。

或者，第二级控制还可以为：控制单元再次对第5级的批量业务接口(批量开户，批量消户)的业务的线程池配置第一动态线程数，如将已经调低的线程数再次调低50％，同时，为第4级的管理业务接口(开户，挂失等)的业务的线程池，也配置第一动态线程数，如第一动态线程数可以为该线程池的最大线程数的80％，以使系统的负荷再次下降，不做赘述。

409、在启动第二级控制后，检测单元重新检测CPU占用，并将检测结果发生给系统负荷状态判断单元，检测结果可以为CPU占用值。

410、系统负荷状态判断单元根据检测结果判断系统是否过负荷，并将过负荷的判断结果发送给告警单元。

在第二级控制之后，系统负荷状态判断单元接收到判断结果，并重新比较检测单元重新发送的CPU占用值与预设CPU最大占用值，如果CPU占用值小于预设CPU最大占用值，系统恢复处于未过负荷状态，则结束数据流控制。

如果CPU占用值仍大于或等于预设CPU最大占用值，系统仍然处于过负荷状态。

411、告警单元接收到判断结果，并确认满足告警条件，向控制单元发出告警信息。

告警单元接收系统负荷状态判断单元发送的过负荷的判断结果，并且确认判断结果是否满足告警条件。此时的告警条件，可以为接收到一次系统负荷状态判断单元发送的过负荷状态判断结果。

412、控制单元根据告警信息启动第三级控制。

控制单元接收到告警信息后，控制单元从数据流阈值获取单元处获得第一动态线程数，控制单元启动第二级控制。如，控制单元可以对第5级的批量业务接口(批量开户，批量消户)的业务的线程池，配置为1的第一动态线程数。由于第一动态线程数为1，业务就变成单线程串行执行了，新的业务请求因为没有线程可用，系统的负荷再次下降。而高级别业务的接入没有受到影响。

或者，第三级控制还可以为：控制单元还可以对第4级的管理业务接口(开户，挂失等)的业务的线程池再次配置第一动态线程数，过程与之前步骤类似，在此不做赘述。

检测单元继续检测CPU占用，系统负荷状态判断单元继续判断系统是否过负荷，如果有必要，可以直到对第1级的后台系统间实时调用接口(查询接口，比如查询余额)的业务的线程池，配置第一动态线程数，过程与之前步骤类似，在此不做赘述。

在上述步骤403、407、411中，可以通过告警信息携带不同的标识，来区分过负荷状态告警还是恢复未过负荷状态告警，不做赘述。

而且，上述各步骤主要控制的为前台业务，如果有后台定时任务在执行，在步骤404、408、412中，可以在分级控制前台业务的同时，按照后台定时任务的级别，从低到高暂不执行相应的后台定时任务。之后，系统恢复正常状态时，再从高到低的恢复执行相应的后台定时任务。

如步骤404中，控制单元可以对第5级的批量业务接口(批量开户，批量消户)的业务，配置第一动态线程数，同时，可以暂不执行低级别的后台定时任务，如月结业务，这样系统的负荷也就随之下降。

值得注意的是，如果单独按照后台定时任务的级别，暂不执行相应的后台定时任务，即可以恢复系统的正常负荷，则无需对前台业务进行控制，不做赘述。

综上所述，系统过负荷时的线程的控制，由于分级进行逐步处理，避免了导致系统运行不平稳，CPU占用大起大落。系统过负荷时的线程的控制，体现了对低级别业务的控制力度大，对高级别业务的控制力度小，充分保证高级业务在系统高负荷情况下的服务质量保证，最大限度的保证高级的业务处理。

可以参考图3及图4对应的本发明实施例的描述内容，仍以电话营业厅为例，营业业务包括开户，销户，查询余额，挂失，解挂失等多种，还可以有系统后台的定时批量任务，比如月结，批量预开户等业务，各级别业务分配有线程池，各线程池配置有最大线程数、第一动态线程数及第二动态线程数。并结合参见图5所示，在系统从过负荷状态恢复到未过负荷状态时，说明本发明实施例的数据流控制方法，也即是系统恢复正常状态时的数据流恢复。

501、检测单元检测CPU占用情况，并将检测结果发生给系统负荷状态判断单元，检测结果可以为CPU占用值。

502、系统负荷状态判断单元根据检测结果判断系统是否过负荷，并将过负荷的判断结果发送给告警单元。

系统负荷状态判断单元接收到检测单元发送的检测结果，并比较检测单元发送的CPU占用值与预设CPU最大占用值，如果CPU占用值小于预设CPU最大占用值，系统恢复处于未过负荷状态。

系统负荷状态判断单元将系统是否过负荷的判断结果发送给告警单元。

503、告警单元连续接收到判断结果，并确认判断结果满足告警条件，向控制单元发出告警信息。

告警条件，可以为连续接收到3次系统负荷状态判断单元发送的未过负荷状态判断结果。也就是，检测单元连续检测3次CPU占用，系统负荷状态判断单元连续3次发现CPU占用值均小于预设CPU最大占用值时，则可以确认系统恢复处于未过负荷状态。

告警单元可以向控制单元发出告警信息，也可以是控制事件监听单元(图中未示)获取告警信息，并告知控制单元系统恢复处于未过负荷状态。

504、控制单元根据告警信息启动第一级控制。

控制单元接收到告警信息后，控制单元从数据流阈值获取单元处获得第二动态线程数，控制单元启动第一级控制。如，控制单元可以对第1级后台系统间实时调用接口(查询接口，比如查询余额)的业务的线程池，配置第二动态线程数，第二动态线程数可以高于当前线程数20％(这里，当前线程数为已经被调低的线程数)。

由于第二动态线程数高于当前线程数20％，相当于第1级业务的线程池接收并发请求能力被调高了20％，这样，第1级业务的线程池可以接收新的业务请求，创建新的线程来处理业务，避免系统资源浪费。这样可以较佳的保证高级别业务的优先接入处理。

505、在启动第一级控制后，检测单元重新检测CPU占用，并将检测结果发生给系统负荷状态判断单元，检测结果可以为CPU占用值。

506、系统负荷状态判断单元根据检测结果判断系统是否过负荷，并将未过负荷的判断结果发送给告警单元。

在第一级控制之后，系统负荷状态判断单元接收到判断结果，并重新比较检测单元重新发送的CPU占用值与预设CPU最大占用值，如果CPU占用值大于或等于预设CPU最大占用值，系统处于过负荷状态，则结束数据流控制。

如果CPU占用值仍小于预设CPU最大占用值，系统仍然处于未过负荷状态。

507、告警单元接收到判断结果，并确认满足告警条件，向控制单元发出告警信息。

告警单元接收系统负荷状态判断单元发送的过负荷的判断结果，并且确认判断结果是否满足告警条件。此时的告警条件，可以为接收到一次系统负荷状态判断单元发送的未过负荷状态判断结果。

508、控制单元根据告警信息启动第二级控制。

控制单元接收到告警信息后，控制单元从数据流阈值获取单元处获得第一动态线程数，控制单元启动第二级控制。如，控制单元可以对第1级的后台系统间实时调用接口(查询接口，比如查询余额)的业务的线程池，配置第二动态线程数，再次提高第1级业务的线程池接收并发请求的能力，这样第1级业务的线程池可以接收新的业务请求，创建新的线程来处理业务，避免系统资源浪费。

或者，第二级控制还可以为：控制单元还可以再次对第1级的后台系统间实时调用接口(查询接口，比如查询余额)的业务的线程池，配置第二动态线程数，同时，为第2级的后台系统间实时调用接口(如调帐业务)的业务的线程池，配置第二动态线程数，不做赘述。

或者，第二级控制还可以为：控制单元还可以对第2级的后台系统间实时调用接口(如调帐业务)的业务的线程池，配置第二动态线程数，不做赘述。

509、在启动第二级控制后，检测单元重新检测CPU占用，并将检测结果发生给系统负荷状态判断单元，检测结果可以为CPU占用值。

510、系统负荷状态判断单元根据检测结果判断系统是否过负荷，并将未过负荷的判断结果发送给告警单元。

在第二级控制之后，系统负荷状态判断单元接收到判断结果，并重新比较检测单元重新发送的CPU占用值与预设CPU最大占用值，如果CPU占用值大于或等于预设CPU最大占用值，系统处于过负荷状态，则结束系统恢复的数据流控制。

如果CPU占用值仍小于预设CPU最大占用值，系统仍然处于未过负荷状态。

511、告警单元接收到判断结果，并确认满足告警条件，向控制单元发出告警信息。

告警单元接收系统负荷状态判断单元发送的过负荷的判断结果，并且确认判断结果是否满足告警条件。此时的告警条件，可以为接收到一次系统负荷状态判断单元发送的未过负荷状态判断结果。

512、控制单元根据告警信息启动第三级控制。

控制单元接收到告警信息后，控制单元从数据流阈值获取单元处获得第一动态线程数，控制单元启动第二级控制。如，控制单元可以对第1级的后台系统间实时调用接口(查询接口，比如查询余额)的业务的线程池，配置最大线程数，使得系统恢复其接收最大并发请求的能力，系统资源被合理的利用。

或者，第三级控制还可以为：控制单元对第2级的后台系统间实时调用接口(如调帐业务)的业务的线程池，配置第二动态线程数，不做赘述。

或者，第三级控制还可以为：对第1级的后台系统问实时调用接口(查询接口，比如查询余额)的业务的线程池，配置最大线程数，系统恢复其接收并发请求的能力的同时，为第2级的后台系统间实时调用接口(如调帐业务)的业务的线程池，配置第二动态线程数，不做赘述。

检测单元继续检测CPU占用，系统负荷状态判断单元继续判断系统是否过负荷，如果有必要，可以直到对第5级的批量业务接口(批量开户，批量消户)的业务进行控制，实现各业务的线程池的线程数恢复为最大线程数，即系统恢复接收最大并发请求的能力，系统资源可以被合理的利用。

在上述步骤503、507、511中，可以通过告警信息携带不同的标识，来区分过负荷状态告警还是恢复未过负荷状态告警，不做赘述。

综上所述，系统恢复时的线程控制，分级进行逐步恢复，避免系统运行不平稳，CPU占用大起大落。而且体现了对低级别业务的恢复力度小，高级别业务的恢复力度大，充分保证高级业务在系统高负荷情况下的服务质量保证，最大限度的保证高级的业务处理。

如图6所示，对应于上述数据流控制方法，本发明实施例提供一种数据流控制装置，包括：

数据流阈值获取单元100，用于获取至少一个级别业务的数据池对应的动态数据流阈值。

控制单元200，用于将动态数据流阈值配置给对应的数据池，以对数据池对应级别的业务数据流进行控制。

本发明实施例的数据流控制装置，根据系统的负荷状态，可以实现对一个或多个级别业务的数据流进行控制，不再是所有业务都同一控制。而且，对各级别业务的数据流进行控制的动态数据流阈值是与级别业务相对应的，这样，可以实现按照级别对业务的数据流进行控制，使得对不同级别业务的数据流的控制更灵活、适用。

可选的，如图7所示，本发明实施例的数据流控制装置，还可以包括：

数据流阈值配置单元300，用于根据业务级别，为业务分配对应的数据池，并为数据池预设数据流阈值，数据流阈值表明数据池的最大业务数据流值，以及根据业务级别，为业务对应的数据池配置至少一个动态数据流阈值，动态数据流阈值包括第一动态数据流阈值以及第二动态数据流阈值，第一动态数据流阈值小于所述数据流阈值，第二动态数据流阈值小于或等于所述数据流阈值。

数据流阈值存储单元400，用于存储数据流阈值配置单元300配置的数据流阈值、第一动态数据流阈值及第二动态数据流阈值。

这样，数据流阈值获取单元100，还用于获取第一动态数据流阈值及第二动态数据流阈值。

可选的，数据流阈值配置单元300，还用于当属于同一级别的业务为至少两个时，为各业务的数据流设置子数据流阈值，所述子数据流阈值小于数据池的数据流阈值，以控制各业务的数据流共享数据池。

数据流阈值存储单元400，还用于存储各业务的子数据流阈值。

进一步，数据流阈值获取单元100，可以包括：

第一数据流阈值获取单元，用于当系统处于过负荷状态时，按照业务级别的高低排序，先获取低级别业务的数据池对应的第一动态数据流阈值；

第二数据流阈值获取单元，用于当系统恢复处于未过负荷状态时，按照业务级别的高低排序，先获取高级别业务的数据池对应的第二动态数据流阈值。

可选的，本发明实施例的数据流控制装置，还可以包括：

业务级别划分单元500，用于根据根据业务的类型、业务的重要性、业务的服务质量Qos中的至少一个为业务划分级别。

检测单元600，用于检测CPU占用，或数据流请求的时延，或数据流请求的等待队列长度或业务QoS；

系统负荷状态判断单元700，用于比较检测单元600获得的CPU占用与预设CPU最大占用，或数据流请求的时延与预设最大时延、或数据流请求的等待队列长度与预设最大等待队列长度，或业务QoS与预设QoS，确定系统的负荷状态，业务QoS为业务平均响应时长、业务及时响应率或业务成功率；

如果CPU占用大于等于预设CPU最大占用，或数据流请求的时延大于等于预设最大时延、或数据流请求的等待队列长度大于等于预设最大等待队列长度，或业务平均响应时长大于等于预设业务平均响应时长，或业务及时响应率小于等于预设业务及时响应率，或业务成功率小于等于预设业务成功率时，系统的负荷状态为过负荷状态；

如果CPU占用小于预设CPU最大占用，或数据流请求的时延小于预设最大时延、或数据流请求的等待队列长度小于预设最大等待队列长度，或业务平均响应时长小于预设业务平均响应时长，或业务及时响应率大于预设业务及时响应率，或业务成功率大于预设业务成功率时，系统的负荷状态为未过负荷状态；

告警单元800，用于系统负荷状态判断单元700的判断结果符合告警条件时，向数据流阈值获取单元100和/或控制单元200发出告警信号。

参见图1、图3及图4所述涉及的数据流控制方法，数据流池可以包括线程池或消息池，动态数据流阈值可以包括动态线程数或动态消息数。

其中，本实施例所涉及的第一动态阈值、第二动态阈值、业务级别的划分、系统负荷状态的判断以及所涉及的具体工作过程，可以参考上述图1、图3及图4所涉及的实施例揭露的相关内容，在此不再赘述。

综上所述，本发明实施例的数据流控制装置，根据系统的负荷状态，可以实现对一个或多个级别业务的数据流进行控制，不再是所有业务都同一控制。而且，对各级别业务的数据流进行控制的动态数据流阈值是与级别业务相对应的，这样，可以实现按照级别对业务的数据流进行控制，使得对不同级别业务的数据流的控制更灵活、适用。本发明实施例提供的数据流控制装置，业务请求不需要接入系统，节约了业务接入的系统资源占用。本发明实施例提供的数据流控制装置，数据流控制平稳，避免了现有技术中，一旦系统过负荷之后，所有业务都拒绝接入，导致业务变化突变，一旦系统恢复正常后，所有业务都接收接入，产生业务抖动。

结合图6、7，说明本发明实施例提供的数据流控制装置，如何为不同级别的业务分别对应设置一个线程池，以及当属于同一级别的业务为至少两个时，如何为各业务的数据流设置子数据流阈值，控制各业务的数据流共享数据池。

上述图6，图7对应的数据流控制装置的可以应用于，如目前基于J2EE的JAVA系统。基于J2EE的JAVA系统是单进程多线程的机制，数据流阈值配置单元300可以为不同级别的业务(如业务1-业务3)分别对应设置一个线程池(线程池1-线程池3)，各线程池可以连接调用CBP计数器，不同级别的业务可以通向不同的CBP(Convergent Billing Point，融合计费点，用于业务实时计费、后付费和批价入账)，如CBP1-CBP3。

业务管理点(BMP，Business Management Point)，可以用于业务的开通，关闭，变更，接入，配置等，以及接收营业受理各项业务的信息并同步到计费和呼叫系统。本发明实施例的数据流控制装置可以设置在JBOSS(开源的J2EE应用服务器)上，不做赘述。

由上可见，为不同级别的业务分配不同的数据池，可以实现按照级别对业务的数据流进行控制，使得对不同级别业务的数据流的控制更灵活、适用。而且，实现不同级别的业务的接入相分离，一旦一个数据池的通道因故障导致该级别的业务无法接入，而不会影响到其他级别业务的接入，达到故障隔离的效果。

示例性的，如线程池对端还有同步调用的情况下，比如转账业务和调账业务优先级相同，共用一个线程池1，在同一个线程池1的通道内派发和处理请求，如果调账业务通往CBP1，转账业务通往CBP2，如果通往CBP1调账业务故障，需要该故障不能影响通往CBP2的转账业务的正常处理。

可以利用超时机制，避免线程池通道被单一CBP节点故障影响而导致通道内全部业务的堵塞。但基于超时时间不能设置的太短，所以在业务高峰时，超时机制不能解决瞬间堵塞的问题。

这样，为各业务设置子线程数，并通过计数机制(实现载体是调用CBP计数器)，避免线程池通道被某一类业务故障堵死，而导致通道内全部业务的堵塞。示例性的，如线程池最大线程数150，则调用任何CBP的计数统计要小于150，这样才可以保证通道不会完全被某一类业务故障堵死。可以为各业务设置子线程数为100，这样，在保证2/3的通道占用的前提下，可以保留1/3(线程数为50)的线程通道对于其它业务是可用的，如通往CBP1的调账业务占用线程数，通过计数得知已经达到了设置的子线程数100，则不再接入新的调账业务，而通往CBP2的转账业务还可以用保留的线程数50，这样通往CBP2的转账业务不被堵塞。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (12)

1.一种数据流控制方法，其特征在于，包括：

根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值；

将所述动态数据流阈值配置给对应的数据池，以对所述数据池对应级别的业务数据流进行控制。

2.根据权利要求1所述的数据流控制方法，其特征在于，所述方法还包括：根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值之前，

根据业务级别，为业务分配对应的数据池，并为所述数据池预设数据流阈值，所述数据流阈值表明数据池的最大业务数据流值；

根据业务级别，为业务对应的数据池配置至少一个动态数据流阈值，所述动态数据流阈值包括第一动态数据流阈值以及第二动态数据流阈值，所述第一动态数据流阈值小于所述数据流阈值，所述第二动态数据流阈值小于或等于所述数据流阈值。

3.根据权利要求2所述的数据流控制方法，其特征在于，根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值，包括：

当系统处于过负荷状态时，按照业务级别的高低排序，先获取低级别业务的数据池对应的第一动态数据流阈值；

或者，当系统恢复处于未过负荷状态时，按照业务级别的高低排序，先获取高级别业务的数据池对应的第二动态数据流阈值。

4.根据权利要求2所述的数据流控制方法，其特征在于，所述数据流池包括线程池或消息池，所述数据流阈值包括最大线程数或最大消息数，所述动态数据流阈值包括动态线程数或动态消息数。

5.根据权利要求2所述的数据流控制方法，其特征在于，所述方法还包括：根据业务级别，为业务分配对应的数据池之前，根据业务的类型、业务的重要性、业务的服务质量Qos中的至少一个为业务划分级别。

6.根据权利要求1所述的数据流控制方法，其特征在于，所述方法还包括：根据系统的负荷状态，获取至少一个级别业务的数据池对应的动态数据流阈值之前，

通过检测并比较中央处理单元CPU占用与预设CPU最大占用，或数据流请求的时延与预设最大时延、或数据流请求的等待队列长度与预设最大等待队列长度，或业务QoS与预设QoS，确定系统的负荷状态，所述业务QoS为业务平均响应时长、业务及时响应率或业务成功率；

所述CPU占用大于等于预设CPU最大占用，或数据流请求的时延大于等于预设最大时延、或数据流请求的等待队列长度大于等于预设最大等待队列长度，或业务平均响应时长大于等于预设业务平均响应时长，或业务及时响应率小于等于预设业务及时响应率，或业务成功率小于等于预设业务成功率时，系统的负荷状态为过负荷状态；

所述CPU占用小于预设CPU最大占用，或数据流请求的时延小于预设最大时延、或数据流请求的等待队列长度小于预设最大等待队列长度，或业务平均响应时长小于预设业务平均响应时长，或业务及时响应率大于预设业务及时响应率，或业务成功率大于预设业务成功率时，系统的负荷状态为未过负荷状态。

7.根据权利要求2所述的数据流控制方法，其特征在于，根据业务级别，为业务分配对应的数据池，包括：

当属于同一级别的业务为至少两个时，为各业务的数据流设置子数据流阈值，所述子数据流阈值小于数据池的数据流阈值，以控制各业务的数据流共享数据池。

8.一种数据流控制装置，其特征在于，包括：

数据流阈值获取单元，用于获取至少一个级别业务的数据池对应的动态数据流阈值；

控制单元，用于将所述动态数据流阈值配置给对应的数据池，以对所述数据池对应级别的业务数据流进行控制。

9.根据权利要求8所述的数据流控制装置，其特征在于，所述数据流控制装置，还包括：

数据流阈值配置单元，用于根据业务级别，为业务分配对应的数据池，并为所述数据池预设数据流阈值，所述数据流阈值表明数据池的最大业务数据流值，以及根据业务级别，为业务对应的数据池配置至少一个动态数据流阈值，所述动态数据流阈值包括第一动态数据流阈值以及第二动态数据流阈值，所述第一动态数据流阈值小于所述数据流阈值，所述第二动态数据流阈值小于或等于所述数据流阈值；

所述数据流阈值获取单元，还用于获取第一动态数据流阈值及第二动态数据流阈值；

数据流阈值存储单元，用于存储所述数据流阈值配置单元配置的所述数据流阈值、第一动态数据流阈值及第二动态数据流阈值。

10.根据权利要求9所述的数据流控制装置，其特征在于，所述数据流阈值获取单元，包括：

第一数据流阈值获取单元，用于当系统处于过负荷状态时，按照业务级别的高低排序，先获取低级别业务的数据池对应的第一动态数据流阈值；

第二数据流阈值获取单元，用于当系统恢复处于未过负荷状态时，按照业务级别的高低排序，先获取高级别业务的数据池对应的第二动态数据流阈值。

11.根据权利要求8所述的数据流控制装置，其特征在于，所述装置，还包括：

业务级别划分单元，用于根据业务的类型、业务的重要性、业务的服务质量Qos中的至少一个为业务划分级别；

检测单元，用于检测CPU占用，或数据流请求的时延，或数据流请求的等待队列长度或业务QoS；

系统负荷状态判断单元，用于比较所述检测单元获得的CPU占用与预设CPU最大占用，或数据流请求的时延与预设最大时延、或数据流请求的等待队列长度与预设最大等待队列长度，或业务QoS与预设QoS，确定系统的负荷状态，所述业务QoS为业务平均响应时长、业务及时响应率或业务成功率；

所述CPU占用大于等于预设CPU最大占用，或数据流请求的时延大于等于预设最大时延、或数据流请求的等待队列长度大于等于预设最大等待队列长度，或业务平均响应时长大于等于预设业务平均响应时长，或业务及时响应率小于等于预设业务及时响应率，或业务成功率小于等于预设业务成功率时，系统的负荷状态为过负荷状态；

所述CPU占用小于预设CPU最大占用，或数据流请求的时延小于预设最大时延、或数据流请求的等待队列长度小于预设最大等待队列长度，或业务平均响应时长小于预设业务平均响应时长，或业务及时响应率大于预设业务及时响应率，或业务成功率大于预设业务成功率时，系统的负荷状态为未过负荷状态；

告警单元，用于所述系统负荷状态判断单元的判断结果符合告警条件时，向所述数据流阈值获取单元和/或所述控制单元发出告警信号。

12.根据权利要求9所述的数据流控制装置，其特征在于，所述数据流阈值配置单元，还用于当属于同一级别的业务为至少两个时，为各业务的数据流设置子数据流阈值，所述子数据流阈值小于数据池的数据流阈值，以控制各业务的数据流共享数据池。

Images