CN106685853A - 处理数据的方法及装置 - Google Patents

Abstract

本公开提供一种处理数据的方法及装置，该方法包括：对接收的报文数据进行解析，从中得到与报文数据所属机构相对应的机构代码；启动至少一个任务队列，并根据机构代码为报文数据分配相应的任务队列；监控任务队列的业务压力，业务压力为单位时间内接收报文数据的数量；在预设周期内根据任务队列的业务压力的情况调整任务队列所处理的机构。设置多个任务队列以及多个守护线程，可以进行多线程处理，提高处理效率。由于接收的报文数据经解析之后是由相应的任务队列对报文数据进行处理，可以保证同一机构报文数据处理的有序性。通过监控任务队列的业务压力可以动态地进行任务队列的拆分或合并，具有很大的灵活性，保证处理效率，节省系统资源。

Description

处理数据的方法及装置

技术领域

本公开总体涉及数据处理技术领域，尤其涉及一种处理数据的方法及装置。

背景技术

当前，电销系统的数据库部署方式为：1个总公司数据库，下属的多家分公司的数据按照一定的规则部署在N个数据库上(分别为分公司1DB、分公司2DB……分公司NDB)。部署一个总公司应用，对报文数据进行处理的流程如图1所示：在步骤S11中，通过接口调用接收XML格式的报文数据；在步骤S12中，总公司应用对XML格式的报文数据进行解析可以得到多个参数，其中的一个参数为机构代码，通过一定的规则可以根据解析的参数选择该机构对应的是哪一个数据库，得到该数据库的数据源以后把解析得到的参数传递给对应数据库并存储过程，执行业务操作；在步骤S13中，总公司应用将报文数据和执行结果保存到总公司数据库中的汇总表中。

其中上述处理过程中通过接口调用接收的一条XML格式的报文就相当于一张订单(如保单)的一次业务操作，业务操作是要求有先后顺序的，也就是说，通过接口先后得到的同一个机构的同一张保单的两个报文，必须保证按照顺序先处理第一条报文，再处理第二条报文。如果前一条报文没有处理完，之后的报文就会一直等待，这样就会影响报文数据处理的整体速度。

另外，如果总公司应用通过接口调用先后有不同机构的报文数据，如果采用单线程处理，则一个机构的报文数据执行效率慢，就会阻塞其他机构报文数据的执行，造成数据处理的效率低下；如果采用多线程处理，接收到一个报文数据就启动一个线程进行处理，则无法保证同一机构发送来的报文数据的执行顺序。因此，需要一种新的处理数据的方法及装置。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种处理数据的方法及装置，以解决现有技术中单线程处理数据的效率慢、多线程处理数据无法保证报文数据顺序的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一方面，本公开提供一种处理数据的方法，该方法包括：

对接收的报文数据进行解析，从中得到与所述报文数据所属机构相对应的机构代码；

启动至少一个任务队列，并根据所述机构代码为所述报文数据分配相应的任务队列；

监控所述任务队列的业务压力，所述业务压力为单位时间内接收报文数据的数量；

在预设周期内根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构，其中所述预设周期大于等于所述单位时间。

在本公开的一种示例性实施例中，每一所述任务队列用于处理至少一个机构的报文数据。

在本公开的一种示例性实施例中，所述监控所述任务队列的业务压力包括：

设定一预设阈值，所述预设阈值为单位时间内所述任务队列接收到报文数据数量的最大值；

判断所述任务就队列的业务压力是否大于所述预设阈值，得到比较结果。

在本公开的一种示例性实施例中，所述根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构包括：

如果所述比较结果为所述任务队列的业务压力大于所述预设阈值，则对所述任务队列所处理的报文数据按照机构代码的不同进行拆分。

在本公开的一种示例性实施例中，所述根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构包括：

如果所述比较结果为所述任务队列的业务压力小于所述预设阈值，则对所述任务队列所处理的报文数据不做拆分或合并的处理，等待下一个预设周期。

在本公开的一种示例性实施例中，所述根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构包括：

如果所述比较结果为若干个任务队列的业务压力总和小于所述预设阈值，则对所述若干个任务队列所处理的报文数据合并为一个任务队列。

根据本公开的一个方面，提供一种处理数据的装置，包括：

报文解析模块，用于对接收的报文数据进行解析，从中得到与所述报文数据所属机构相对应的机构代码；

队列分配模块，用于启动至少一个任务队列，并根据所述机构代码为所述报文数据分配相应的任务队列；

监控模块，用于监控所述任务队列的业务压力，所述业务压力为单位时间内接收报文数据的数量；

调整模块，用于在预设周期内根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构，其中所述预设周期大于等于所述单位时间。

在本公开的一种示例性实施例中，所述调整模块包括：

设定子模块，用于设定一预设阈值，所述预设阈值为单位时间内所述任务队列接收到报文数据数量的最大值；

判断子模块，用于判断所述任务就队列的业务压力是否大于所述预设阈值，得到比较结果。

在本公开的一种示例性实施例中，所述调整模块还包括：

拆分子模块，用于如果所述比较结果为所述任务队列的业务压力大于所述预设阈值，则对所述任务队列所处理的报文数据按照机构代码的不同进行拆分。

在本公开的一种示例性实施例中，所述调整模块还包括：

合并子模块，用于如果所述比较结果为若干个任务队列的业务压力总和小于所述预设阈值，则对所述若干个任务队列所处理的报文数据合并为一个任务队列。

基于上述技术方案可知，本公开的实施例具有以下技术效果：

该方法设置多个任务队列以及多个守护线程，可以进行多线程处理，提高处理效率。由于接收的报文数据经解析之后是由相应的任务队列对报文数据进行处理，可以保证同一机构报文数据处理的有序性。分配任务队列之后对其承载的业务压力进行监控，并根据业务压力的情况定期调整任务队列所处理的机构，即动态地进行任务队列的拆分或合并，具有很大的灵活性，使得在业务压力大的时候进行任务队列的拆分，保证处理效率，在业务压力小的时候进行任务队列的合并，可以节省系统资源。

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

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1示出相关实施例中对报文数据进行处理的流程图。

图2示出相关实施例中总公司应用处理同一机构的先后两条报文的流程图。

图3示出相关实施例中总公司应用处理不同机构的先后多条报文的流程图。

图4示出相关实施例中对于同一机构先后发送来的报文数据分别交给不同的线程进行处理的流程图。

图5示出本公开一实施例中提供的一种处理数据的方法的流程图。

图6示出本公开一实施例中进行数据处理的一种实施方式的处理流程图。

图7示出本公开一实施例中监控步骤的流程示意图。

图8示出本公开一实施例中对任务队列进行拆分操作的示意图。

图9示出本公开一实施例中对任务队列进行合并操作的示意图。

图10示出本公开另一实施例中提供的一种处理数据的装置的示意图。

图11示出本公开另一实施例中报文解析模块以及监控模块工作的示意图。

图12示出本公开另一实施例中本实施例中调整模块的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现、材料或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

为了保证业务操作执行的先后顺序，总公司应用处理同一机构的先后两条报文的流程如图2所示：

首先，通过接口调用先后接收两条报文数据，如图2所示，这两条报文数据为报文数据1(先)和报文数据2(后)，它们所对应的机构代码和保单号均相同，但是完成的业务操作是不同的，那么总公司应用必须保证报文数据1先执行成功后，再执行报文数据2，即报文数据1执行图1中步骤S11～S13的处理后再接收报文数据2，并执行步骤S11～S13的处理。如果报文数据1执行效率慢，那么报文数据2会一直等待，直到报文数据1执行完成。

总公司应用处理不同机构的先后多条报文的流程如图3所示，总公司应用接收机构代码为1的机构先后发送来的两条报文数据1和数据报文2以及机构代码为1的机构发送来的报文数据3、机构代码为C的机构发送来的报文数据4，其实报文数据3和报文数据4并不需要等待报文数据1、2执行完成后再做执行。图3中所示流程为采用单线程进行数据处理，如果报文数据1执行效率慢，同样也会影响到其他分公司数据(如报文数据3和报文数据4)的执行效率。

除此之外，总公司应用处理不同机构的先后多条报文还可以采用多线程进行处理，但是采用多线程处理时，对于同一机构先后发送来的报文数据分别交给不同的线程进行处理的流程，如图4所示，机构代码为1的机构发送来的报文数据1由线程1进行处理，而机构代码为2的机构发送来的报文数据2由线程2进行处理，这样将无法保证总公司应用在处理这两条报文数据时并不是按照处理完报文数据1以后再处理报文数据2的先后顺序。

基于上述，总公司应用采用单线程处理来自多个机构的报文数据会有处理效率低的问题，一旦一个机构的报文数据处理以及执行的效率过慢就会导致其他机构的报文数据的处理以及执行收到阻塞，不利于提高处理效率；而总公司应用采用多线程处理来自多个机构的报文数据又会有无法保证报文数据的处理以及执行顺序的问题。

针对上述问题，图5示出根据本公开一实施例提供的一种处理数据的方法的流程图。

如图5所示，在步骤S10中，对接收的报文数据进行解析，从中得到与报文数据所属机构相对应的机构代码。

如图5所示，在步骤S20中，启动至少一个任务队列，并根据机构代码为报文数据分配相应的任务队列。

如图5所示，在步骤S30中，监控任务队列的业务压力，业务压力为单位时间内接收报文数据的数量。

如图5所示，在步骤S40中，在预设周期内根据任务队列的业务压力的情况调整任务队列所处理的机构，其中预设周期大于等于单位时间。

本实施例提供的方法通过启动多个任务队列，根据从报文数据中解析的机构代码分配相应的任务队列，分配任务队列之后对其承载的业务压力进行监控，并根据业务压力的情况定期调整任务队列所处理的机构，灵活性增强，从而可以对报文数据进行多线程处理，同时还可以保证同一机构的报文数据按照先后顺序进行处理，既提高处理效率又保证有序性。

其中本实施例中每一任务队列用于处理至少一个机构的报文数据，实际情况中可以根据每一机构所发送的报文数据的数量的不同来确定每一任务队列来处理几个机构的报文数据，例如如果报文数据的数量一直不是很多的机构，则可以是一个任务队列处理几个机构的报文数据，而如果报文数据的数量很多的话，则一个任务队列可以处理一个机构的报文数据，如果处理多个机构的报文数据则将会影响处理的效率。需要说明的是，一般是不会用多个任务队列来处理同一个机构的报文的数据的，因此一个任务队列至少对应一个机构的报文数据。

首先，在步骤S10中在总公司应用通过接口调用接收来自不同机构的报文数据，并对报文数据进行解析，其中的报文数据可以是保单，一条保单的报文数据包括机构代码、保单号以及业务信息等。机构代码就是总公司对下属的机构作统一的编码以便进行数据统计以及管理等，保单号是保险公司为客户提供每一份保险的合同号，还可以是销售公司的订单号等等，此处仅为示例，不在此一一列举。业务信息是对于同一保单号或订单号提供针对不同阶段的任务，例如保单先进行质检，再进行电核等等不同的业务阶段，或者是订单的接收、确认、发货、售后以及安装或维修等业务。

同一个机构可以向总公司应用发送相同或不同的保单号的报文数据，还可以发送同一保单号不同业务类型的报文数据，如先接收机构A保单号为X的质检结果，再接收机构A保单号为X的电核结果……在步骤S10中只需要解析出报文数据中包含的机构代码的信息即可，以便下一步骤根据机构代码来配置任务队列以及处理线程。

在本实施例中，在程序启动时根据配置生成多个任务队列，包括任务队列1、任务队列2……每一个任务队列可以对应一个或多个机构，通常每一个任务队列对应启动一个处理线程，该处理线程扫描任务队列中是否有新的任务(也就是需要处理的报文数据)。

例如，以保险公司为例，总公司往往有几家设置在不同城市或地区的下属分公司机构，参见表1所示，北京、天津和河北的分公司共用任务队列1，但北京、天津和河北分别具有不同的机构代码，山东的分公司配置任务队列2……

分公司机构	任务队列编号
		北京	1
天津	1
		河北	1
山东	2
		......	......

表1

本实施例在步骤S20中根据解析出来的机构代码分配相应的任务队列，参见表1所示，如果报文数据中解析出机构代码是北京、天津或河北，则为其分配任务队列1，如果报文数据中解析出机构代码是山东，则为其分配任务队列2，并且由分配的任务队列进行后续的一系列处理。

由于接收报文数据后是由任务队列进行处理，由于队列特有的先进先出属性，因此本实施例中任务队列对接收的报文数据也是按照先进先出的原则进行处理，这样可以保证处理报文数据的顺序为先接收的报文数据先处理，后接收的报文数据后处理，以此保证报文数据处理的有序性。以保单为例，对于同一机构的保单号相同的报文数据而言，按照业务信息的类型的不同具有一定的有序性，也就是先收到质检结果再收到电核结果，利用任务队列处理对报文数据进行一一有序的处理，可以解决现有技术中进行多线程处理时无法保证同一机构同一张保单的执行顺序的问题。

本实施例在步骤S30中监控任务队列的业务压力包括：

首先，设定一预设阈值，预设阈值为单位时间内任务队列接收到报文数据数量的最大值。之后，判断任务队列的业务压力是否大于预设阈值，得到比较结果，比较结果分为三种：大于预设阈值、等于预设阈值以及小于预设阈值。

在本实施例中步骤S40主要是根据步骤S30的比较结果来对任务队列所处理的报文数据来源进行动态调整，即如果比较结果为任务队列的业务压力大于预设阈值，则对任务队列所处理的报文数据按照机构代码的不同进行拆分；如果比较结果为任务队列的业务压力小于预设阈值，则对任务队列所处理的报文数据不做拆分或合并的处理，等待下一个预设周期；如果比较结果为若干个任务队列的业务压力总和小于预设阈值，则对若干个任务队列所处理的报文数据合并为一个任务队列。

图6示出本实施例一种实施方式下的处理流程图，具体包括以下步骤：

1)总公司应用从接口中得到报文数据后进行解析，得到报文所属的分公司代码(也就是机构代码)。

2)根据解析结果中的机构代码，将解析结果发送到对应的任务队列。如报文数据解析后，机构为北京，那么按照表1的对应关系就会将其发送到任务队列1进行后续处理。

3)每个任务队列会有对应的守护线程，如图6所示，任务队列1对应守护线程1，相应的处理程序对分公司1以及总公司的报文数据，如果扫描到有新的任务，把报文数据从任务队列中取出来，进行后续的操作：记录日志、存总部库、连接分公司数据源、调用分公司数据源上的存储过程等。

4)同时对每个消息队列进行监控，主要是监控每个分公司的业务压力，并且会根据业务压力的大小，进行人队伍队列的调整，所谓调整包括：拆分或合并。

监控时需要设置一个预设阈值，例如可以设置单位时间内任务队列接收到报文数据数量的最大值maxNum＝500，这里的单位时间可以是一分钟，因此监控时需要对每一分钟各个机构报文数据的数量进行统计，用于决定是否进行拆分和合并。

按照表1中的初始化设置，北京、天津、河北三家分公司公用一个任务队列，山东分公司使用一个任务队列。任务队列启动后，统计单位时间内每一机构报文数据的数量，最后判断统计的数量是否大于预设阈值，并根据比较结果对当前任务队列所承担的机构进行拆分、合并或者不变的处理，之后返回继续统计下一个单位时间内每一机构报文数据的数量，图7示出上述过程的流程示意图。

需要说明的是，对报文数据数量进行统计的预设周期可以大于或等于单位时间，如果预设周期等于单位时间，也就是可以在一个单位时间对任务队列进行一次调整；如果预设周期大于单位时间，也可以是在W个单位时间内对任务队列进行一次调整，都可以进行动态调整。预设周期时一个单位时间还是W个单位时间将会影响调整的灵敏度，W的数值越大，则灵敏度越差。因此具体调整的预设周期选择多大，可以根据需要进行选择。

例如，单位时间内统计结果：北京的报文数据数量＝100，天津的报文数据数量＝100，河北的报文数据数量＝200；计算结果三家分公司总计的报文数据数量为400<maxNum＝500，可以看出任务队列1还能承受这三家分公司的报文数据的业务压力，因此对任务队列1不做拆分。

由于任务队列1处理的是北京、天津、河北三家分公司的报文数据，如果监控模块发现这段时间某一分公司的报文数据特别多，那么会自动拆分生成一个新的任务队列，并由新的任务队列去单独处理来自北京的报文数据，以提高处理效率。

仍以单位时间内的统计结果为例，如果北京的报文数据数量＝200，天津的报文数据数量＝100，河北的报文数据数量＝300；计算结果三家分公司总计的报文数据数量为600>maxNum＝500；那么需要把最大的报文数据数量的河北分公司拆分出去；拆分后，河北分公司单独使用一个任务队列(假如分配给新的任务队列A)，北京、天津分公司共用一个任务队列。

另外，进行一次拆分之后，还可以进一步进行拆分，即单位时间内的统计结果为北京的报文数据数量＝400，天津的报文数据数量＝300，河北的报文数据数量＝500；计算后，河北分公司被拆分出去，分配给新的任务队列A。图8示出对任务队列进行拆分操作的示意图。剩余的北京、天津分公司的报文数据数量再计算，依然大于预设阈值，那么会继续拆分，也就是北京分公司和天津分公司分别分配一个任务队列B和任务队列C，最终的拆分结果为：北京、天津、河北三家分公司各使用一个任务队列。但是需要说明的是，如果单个分公司的报文数据数量依然大于预设阈值，如河北一分钟内有1000条数据，也不再继续拆分，因此一般不会出现一家分公司使用多个任务队列的情况。

例如，单位时间内的统计结果：北京的报文数据数量＝100，天津的报文数据数量＝100，河北的报文数据数量＝200；通过计算得到三个分公司的报文数据数量之和400<maxNum＝500，说明系统的处理压力得到降低，那么如果这三家分公司之前分别由三个任务队列单独进行处理，则可以将这三个任务队列会合并成一个。仍以表1为例，任务队列1中处理的是北京、天津、河北的报文数据，任务队列2中处理的是山东的数据，如果一段时间四家分公司报文数据都不是很多，那么会将其合并成一个任务队列，以节约系统资源，图9示出对任务队列进行合并操作的示意图。

本实施例中是将上述方法应用在保险类公司在处理保单数据过程中，还可以应用在其他类别的数据处理过程中，这样可以便于总公司对下属的分公司的订单数据等进行管理。

综上所述，本实施例提供的处理数据的方法设置多个任务队列以及多个守护线程，可以进行多线程处理，提高处理效率。由于接收的报文数据经解析之后是由相应的任务队列对报文数据进行处理，可以保证同一机构报文数据处理的有序性。进一步的，分配任务队列之后对其承载的业务压力进行监控，并根据业务压力的情况定期调整任务队列所处理的机构，即动态地进行任务队列的拆分或合并，具有很大的灵活性，使得在业务压力大的时候进行任务队列的拆分，保证处理效率，在业务压力小的时候进行任务队列的合并，可以节省系统资源。

图10还示出本公开另一实施例中提供的一种处理数据的装置的示意图，如图10所示，该装置100包括：报文解析模块110、队列分配模块120、监控模块130和调整模块140。

报文解析模块110用于对接收的报文数据进行解析，从中得到与报文数据所属机构相对应的机构代码。队列分配模块120用于启动至少一个任务队列，并根据机构代码为报文数据分配相应的任务队列。监控模块130用于监控任务队列的业务压力，业务压力为单位时间内接收报文数据的数量。调整模块140用于在预设周期内根据任务队列的业务压力的情况调整任务队列所处理的机构，其中预设周期大于等于单位时间。

该实施例提供的装置中总公司应用通过报文解析模块对接收的报文数据进行解析，队列分配模块根据解析出来的机构代码分配相应的任务队列进行后续处理，同时通过监控模块对所有任务队列的业务压力进行监控，以便调整模块能够及时根据任务队列所承受的业务压力调整任务队列对应的机构。

其中报文解析模块以及监控模块工作的示意图如图11所示，即报文解析模块对通过接口调用接收到的报文数据进行解析，按照机构代码将报文数据分配给相应的任务队列，即分别分配给任务队列1、任务队列2、……任务队列N，同时监控模块对这些任务队列进行监控，以得到每个任务队列的业务压力。

在本实施例中，每一任务队列用于处理至少一个机构的报文数据，同时每一任务队列对应一个守护线程，并由相应的处理程序进行对分公司以及总公司的数据进行处理。实际情况中可以根据每一机构所发送的报文数据的数量的不同来确定每一任务队列来处理几个机构的报文数据，例如如果是报文数据的数量一直不是很多的机构可以是一个任务队列处理几个机构的报文数据，而如果报文数据的数量很多的话则一个任务队列可以处理一个机构的报文数据，如果处理多个机构的报文数据则将会影响处理的效率。

在总公司应用通过接口调用接收来自不同机构的报文数据，并对报文数据进行解析，其中的报文数据可以是保单，一条保单的报文数据包括机构代码、保单号以及业务信息等，同一个机构可以向总公司应用发送相同或不同的保单号的报文数据，还可以发送同一保单号不同业务类型的报文数据，如先接收机构A保单号为X的质检结果，再接收机构A保单号为X的电核结果……报文解析模块只需要解析出报文数据中包含的机构代码的信息即可。

队列分配模块120根据解析出来的机构代码分配相应的任务队列，参见表1所示，如果报文数据中解析出机构代码是北京、天津或河北，则为其分配任务队列1，如果报文数据中解析出机构代码是山东，则为其分配任务队列2，并且由分配的任务队列进行后续的一系列处理。

由于接收报文数据后是由任务队列进行处理，由于队列特有的先进先出属性，因此本实施例中任务队列对接收的报文数据也是按照先进先出的原则进行处理，这样可以保证处理报文数据的顺序为先接收的报文数据先处理，后接收的报文数据后处理，以此保证报文数据处理的有序性。以保单为例，对于同一机构的保单号相同的报文数据而言，按照业务信息的类型的不同具有一定的有序性，也就是先收到质检结果再收到电核结果，利用任务队列处理对报文数据进行一一有序的处理，可以解决现有技术中进行多线程处理时无法保证同一机构同一张保单的执行顺序的问题。

图12示出本实施例中调整模块140的示意图，如图12所示，调整模块140还可以进一步包括：设定子模块141和判断子模块142。

其中设定子模块141用于设定一预设阈值，预设阈值为单位时间内任务队列接收到报文数据数量的最大值，例如设置单位时间内任务队列接收到报文数据数量的最大值maxNum＝500。“单位时间”可以是一分钟，因此监控时需要对每一分钟各个机构报文数据的数量进行统计，用于决定是否对任务队列进行拆分和合并。

判断子模块142用于判断任务队列的业务压力是否大于预设阈值，得到比较结果，比较结果分为三种：大于预设阈值、等于预设阈值以及小于预设阈值。

接下来调整模块140就会根据比较结果来对任务队列所处理的报文数据来源进行动态调整，即如果比较结果为任务队列的业务压力大于预设阈值，则对任务队列所处理的报文数据按照机构代码的不同进行拆分；如果比较结果为任务队列的业务压力小于预设阈值，则对任务队列所处理的报文数据不做拆分或合并的处理，等待下一个预设周期；如果比较结果为若干个任务队列的业务压力总和小于预设阈值，则对若干个任务队列所处理的报文数据合并为一个任务队列。

如图11所示，调整模块140中还包括：拆分子模块143以及合并子模块144，具体的是对任务队列进行拆分还是合并需要根据比较结果来决定。

拆分子模块143用于如果比较结果为任务队列的业务压力大于预设阈值，则对任务队列所处理的报文数据按照机构代码的不同进行拆分。

按照表1中的初始化设置，北京、天津、河北三家分公司公用一个任务队列，山东分公司使用一个任务队列。任务队列启动后，统计单位时间内每一机构报文数据的数量，最后判断统计的数量是否大于预设阈值，并根据比较结果对当前任务队列所承担的机构进行拆分、合并或者不变的处理，之后返回继续统计下一个单位时间内每一机构报文数据的数量，图7示出上述过程的流程示意图。

需要说明的是，对报文数据数量进行统计的预设周期可以大于或等于单位时间，如果预设周期等于单位时间，也就是可以在一个单位时间对任务队列进行一次调整；如果预设周期大于单位时间，也可以是在W个单位时间内对任务队列进行一次调整，都可以进行动态调整。预设周期时一个单位时间还是W个单位时间将会影响调整的灵敏度，W的数值越大，则灵敏度越差。因此具体调整的预设周期选择多大，可以根据需要进行选择。

例如，单位时间内统计结果：北京的报文数据数量＝100，天津的报文数据数量＝100，河北的报文数据数量＝200；计算结果三家分公司总计的报文数据数量为400<maxNum＝500，可以看出任务队列1还能承受这三家分公司的报文数据的业务压力，因此对任务队列1不做拆分。

由于任务队列1处理的是北京、天津、河北三家分公司的报文数据，如果监控模块发现这段时间某一分公司的报文数据特别多，那么会自动拆分生成一个新的任务队列，并由新的任务队列去单独处理来自北京的报文数据，以提高处理效率。

仍以单位时间内的统计结果为例，如果北京的报文数据数量＝200，天津的报文数据数量＝100，河北的报文数据数量＝300；计算结果三家分公司总计的报文数据数量为600>maxNum＝500；那么需要把最大的报文数据数量的河北分公司拆分出去；拆分后，河北分公司单独使用一个任务队列(假如分配给新的任务队列A)，北京、天津分公司共用一个任务队列。

另外，进行一次拆分之后，还可以进一步进行拆分，即单位时间内的统计结果为北京的报文数据数量＝400，天津的报文数据数量＝300，河北的报文数据数量＝500；计算后，河北分公司被拆分出去，分配给新的任务队列A。剩余的北京、天津分公司的报文数据数量再计算，依然大于预设阈值，那么会继续拆分，也就是北京分公司和天津分公司分别分配一个任务队列B和任务队列C，最终的拆分结果为：北京、天津、河北三家分公司各使用一个任务队列。但是需要说明的是，如果单个分公司的报文数据数量依然大于预设阈值，如河北一分钟内有1000条数据，也不再继续拆分，因此一般不会出现一家分公司使用多个任务队列的情况。

如果比较结果为任务队列的业务压力小于预设阈值，则对任务队列所处理的报文数据不做拆分或合并的处理，等待下一个预设周期。

合并子模块144用于如果比较结果为若干个任务队列的业务压力总和小于预设阈值，则对若干个任务队列所处理的报文数据合并为一个任务队列。

例如，单位时间内的统计结果：北京的报文数据数量＝100，天津的报文数据数量＝100，河北的报文数据数量＝200；通过计算得到三个分公司的报文数据数量之和400<maxNum＝500，说明系统的处理压力得到降低，那么如果这三家分公司之前分别由三个任务队列单独进行处理，则可以将这三个任务队列会合并成一个。仍以表1为例，任务队列1中处理的是北京、天津、河北的报文数据，任务队列2中处理的是山东的数据，如果一段时间四家分公司报文数据都不是很多，那么会将其合并成一个任务队列，以节约系统资源。

综上所述，本实施例提供的装置通过设置多个任务队列以及多个守护线程，可以进行多线程处理，提高处理效率。由于接收的报文数据经解析之后是由相应的任务队列对报文数据进行处理，可以保证同一机构报文数据处理的有序性。进一步的，分配任务队列之后对其承载的业务压力进行监控，并根据业务压力的情况定期调整任务队列所处理的机构，即动态地进行任务队列的拆分或合并，具有很大的灵活性，使得在业务压力大的时候进行任务队列的拆分，保证处理效率，在业务压力小的时候进行任务队列的合并，可以节省系统资源。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (10)

1.一种处理数据的方法，其特征在于，该方法包括：

对接收的报文数据进行解析，从中得到与所述报文数据所属机构相对应的机构代码；

启动至少一个任务队列，并根据所述机构代码为所述报文数据分配相应的任务队列；

监控所述任务队列的业务压力，所述业务压力为单位时间内接收报文数据的数量；

在预设周期内根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构，其中所述预设周期大于等于所述单位时间。

2.根据权利要求1所述的方法，其特征在于，每一所述任务队列用于处理至少一个机构的报文数据。

3.根据权利要求1所述的方法，其特征在于，所述监控所述任务队列的业务压力包括：

设定一预设阈值，所述预设阈值为单位时间内所述任务队列接收到报文数据数量的最大值；

判断所述任务就队列的业务压力是否大于所述预设阈值，得到比较结果。

4.根据权利要求3所述的方法，其特征在于，所述根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构包括：

如果所述比较结果为所述任务队列的业务压力大于所述预设阈值，则对所述任务队列所处理的报文数据按照机构代码的不同进行拆分。

5.根据权利要求3所述的方法，其特征在于，所述根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构包括：

如果所述比较结果为所述任务队列的业务压力小于所述预设阈值，则对所述任务队列所处理的报文数据不做拆分或合并的处理，等待下一个预设周期。

6.根据权利要求3所述的方法，其特征在于，所述根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构包括：

如果所述比较结果为若干个任务队列的业务压力总和小于所述预设阈值，则对所述若干个任务队列所处理的报文数据合并为一个任务队列。

7.一种处理数据的装置，其特征在于，包括：

报文解析模块，用于对接收的报文数据进行解析，从中得到与所述报文数据所属机构相对应的机构代码；

队列分配模块，用于启动至少一个任务队列，并根据所述机构代码为所述报文数据分配相应的任务队列；

监控模块，用于监控所述任务队列的业务压力，所述业务压力为单位时间内接收报文数据的数量；

调整模块，用于在预设周期内根据所述任务队列的业务压力的情况调整所述任务队列所处理的机构，其中所述预设周期大于等于所述单位时间。

8.根据权利要求7所述的装置，其特征在于，所述调整模块包括：

设定子模块，用于设定一预设阈值，所述预设阈值为单位时间内所述任务队列接收到报文数据数量的最大值；

判断子模块，用于判断所述任务就队列的业务压力是否大于所述预设阈值，得到比较结果。

9.根据权利要求8所述的装置，其特征在于，所述调整模块还包括：

拆分子模块，用于如果所述比较结果为所述任务队列的业务压力大于所述预设阈值，则对所述任务队列所处理的报文数据按照机构代码的不同进行拆分。

10.根据权利要求9所述的装置，其特征在于，所述调整模块还包括：

合并子模块，用于如果所述比较结果为若干个任务队列的业务压力总和小于所述预设阈值，则对所述若干个任务队列所处理的报文数据合并为一个任务队列。