CN103338230A - 一种业务数据的处理方法及系统 - Google Patents

Abstract

本发明公开了一种业务数据的处理方法及系统；方法包括：应用服务器接收各应用进程待处理的业务数据，封装为多个作业包，在包头中携带该应用进程的关联标识、作业包序列号及业务数据的处理信息；将作业包随机分配到下行队列中；分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；业务处理模块分别根据各作业包的包头中所携带的处理信息，调度相应的作业处理模块处理该作业包中的业务数据；应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入对应的上行队列；将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合后返回给该上行队列对应的应用进程。本发明能满足高并发多连接的业务需求。

Description

一种业务数据的处理方法及系统

技术领域

本发明涉及网络领域，尤其涉及一种业务数据的处理方法及系统。

背景技术

随着互联网应用、移动通信的普及，特别是云服务、电子商务、网上银行、电子支付等新型服务模式不断涌现，使各类客户的社会活动和经济活动方式及其地域范围发生了巨大的变化，各类业务必须能为客户提供丰富的访问方式和渠道，访问方式和设备呈现多样性、动态性和移动性的特点。例如，银行业的数据大集中、电子支付等金融电子化应用发展趋势对信息系统的高并发的处理能力提出了更高的需求；随着网络的广泛应用，越来越多的用户选择网上购物的方式，网上商户也经常选择一些时间点组织“抢拍”或“秒杀”活动进行促销；在云计算应用中，海量的终端和云计算中心之间频繁数据交互，所有这些都需要支持高并发的海量连接，期待单台服务器或设备维持千万级以上的并发连接。如果信息系统和设备不能适应高并发多连接的业务需求，信息系统将发生运转困难、业务阻塞等严重问题。

为了满足大数据中心的海量用户和瞬时的海量业务需求，适应“抢拍”或“秒杀”交易等为代表的云服务模式而产生的海量操作、大规模的并发，社交网络、网上银行、电子支付、网上购物业务等系统后台需要采用支持高并发海量连接的通信方法，以满足数据大集中、大数据和云服务对高并发海量连接的高性能要求。

发明内容

本发明要解决的技术问题是如何满足高并发多连接的业务需求。

为了解决上述问题，本发明提供了一种业务数据的处理方法，包括：

应用服务器接收各应用进程待处理的业务数据，将该业务数据封装为多个作业包，并在作业包的包头中携带该应用进程的关联标识、作业包序列号及业务数据的处理信息；将所述多个作业包随机分配到下行队列中；所述下行队列与业务处理系统中的业务处理模块对应，个数为固定值；

所述应用服务器分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；

所述业务处理模块分别根据各作业包的包头中所携带的处理信息，调度所述业务处理系统中相应的作业处理模块处理该作业包中的业务数据；所述应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列；

所述应用服务器分别将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合，将组合后的数据返回给该上行队列对应的应用进程。

进一步地，所述应用服务器接收各应用进程待处理的业务数据的步骤前还包括：

根据所述业务处理系统的处理器核的个数，建立所述应用服务器与所述业务处理系统之间的多条数据连接，并建立分别与所述多条数据连接一一对应的多个下行队列，以及相应个数的业务处理模块。

进一步地，所述应用服务器分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块的步骤包括：

所述应用服务器分别在各下行队列的作业包的包头中携带该下行队列对应的业务处理模块的标识，包括板卡号和处理器核号；

所述应用服务器分别将各下行队列的作业包通过该下行队列对应的数据连接发送给所述业务处理系统；

所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包。

进一步地，所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包的步骤后还包括：

所述业务处理模块在通过所述数据连接所接收到的作业包的包头中增加

该数据连接的标识；

所述应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列的步骤前还包括：

所述业务处理模块根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述应用服务器。

进一步地，所述业务数据的处理信息包括以下信息中的任一个或任几个：

命令字、业务基础数据号、数据长度和业务特征预留字。

进一步地，所述业务处理模块的个数与所有应用服务器与业务处理系统之间所有数据连接的总数相同，且业务处理模块与所述数据连接一一对应。

进一步地，所述业务处理模块的个数与每一个应用服务器与业务处理系统之间的数据连接的个数相同，且对于每一个应用服务器，业务处理模块和该应用服务器与业务处理系统之间的数据连接一一对应；

每个业务处理模块中包含一个或多个监听进程，与不同应用服务器一一对应；各监听进程分别用于对属于本监听进程所对应的应用服务器、且对应于本业务处理模块的数据连接进行监听。

本发明还提供了一种业务数据的处理系统，包括：业务处理系统和应用服务器；

所述业务处理系统包括：作业处理模块；

业务处理模块，用于分别根据各作业包的包头中所携带的处理信息，调度相应的作业处理模块处理该作业包中的业务数据；

所述应用服务器包括：

接口模块，用于接收各应用进程待处理的业务数据，将该业务数据封装为多个作业包，并在作业包的包头中携带该应用进程的关联标识、作业包序列号及业务数据的处理信息；将所述多个作业包随机分配到下行队列中；所述下行队列与所述业务处理系统中的业务处理模块对应，个数为固定值；

业务服务引擎模块，用于分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列；

所述接口模块还用于分别将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合，将组合后的数据返回给该上行队列对应的应用进程。

进一步地，所述业务服务引擎模块还用于在所述业务处理系统初次运行时，根据所述业务处理系统的处理器核的个数，建立与所述业务处理系统之间的多条数据连接，并建立分别与所述多条数据连接一一对应的多个下行队列，并通知业务处理系统建立相应个数的业务处理模块。

进一步地，所述接口模块还用于分别在各下行队列的作业包的包头中携带该下行队列对应的业务处理模块的标识，包括板卡号和处理器核号；

所述业务服务引擎模块分别将各下行队列的作业包发送给该下行队列对应的业务处理模块是指：

所述业务服务引擎模块分别将各下行队列的作业包通过该下行队列对应的数据连接发送给所述业务处理系统；

所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包。

进一步地，所述业务处理模块还用于在通过所述数据连接所接收到的作业包的包头中增加该数据连接的标识；还用于根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述业务服务引擎模块。

进一步地，所述业务数据的处理信息包括以下信息中的任一个或任几个：

命令字、业务基础数据号、数据长度和业务特征预留字。

进一步地，所述业务处理模块的个数与所有应用服务器与业务处理系统之间所有数据连接的总数相同，且业务处理模块与所述数据连接一一对应。

进一步地，所述业务处理模块的个数与每一个应用服务器与业务处理系统之间的数据连接的个数相同，且对于每一个应用服务器，业务处理模块和该应用服务器与业务处理系统之间的数据连接一一对应；

各业务处理模块分别包括：

一个或多个监听单元，与不同应用服务器一一对应，用于对属于本监听单元所对应的应用服务器、且对应于本业务处理模块的数据连接进行监听；

一个业务调度单元，用于从本业务处理模块对应的数据连接接收作业包，并分别根据各作业包的包头中所携带的处理信息，调度相应的作业处理模块处理该作业包中的业务数据；

一个数据反馈单元，用于根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述业务服务引擎模块。

本发明的至少一个实施例能针对高并发海量连接的业务需求进行处理，采用固定数目的进程(或线程)进行业务数据的处理，不会随着前端应用进程(线程)的增加而增加，避免在高并发海量连接的情况下，进程(或线程)数大幅度增加而导致的处理性能下降的问题。可广泛用于社交网络、电子支付、网上银行、银行资金结算、证券资金结算、股票交易、EDI电子贸易、电子商务、网络购票等应用环境；本发明的一个优化方案中采用固定数目的逻辑连接进行业务数据的传输，同样也不会随着前端应用进程(线程)的增加而增加。本发明的又一个优化方案中将处理后的作业包通过发送该作业包的数据连接返回给应用服务器，这样无论有多少个应用服务器，都可以共用业务处理系统中的多个数据连接来返回数据，这样每个应用服务器的数据连接数就只和业务处理系统中的处理器核数有关，而无需在业务处理系统中为每个应用服务器各自建立更多数据连接来返回数据。

附图说明

图1为实施例一的业务数据的处理方法的流程示意图；

图2为实施例二的业务数据的处理系统的一种示意框图；

图3为实施例二的业务数据的处理系统的另一种示意框图；

图4为实施例二中前端应用服务器的示意框图；

图5a为实施例二中后端业务处理系统一种实现方式的示意框图；

图5b为实施例二中后端业务处理系统另一种实现方式的示意框图；

图6为实施例二中处理系统的工作流程示意图；

图7为实施例二中步骤一的流程示意图；

图8为实施例二中步骤二的流程示意图；

图9为实施例二中步骤三的流程示意图；

图10为实施例二中步骤四的流程示意图。

图11为实施例二中作业包的结构示意图；

图12为实施例二中作业包的包头示意图；

图13为实施例二中报文的结构示意图；

图14为实施例二中报文的报头示意图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。所举实例只用于解释本发明，并非用于限定本发明的范围。

需要说明的是，如果不冲突，本发明实施例以及实施例中的各个特征可以相互结合，均在本发明的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一、一种业务数据的处理方法，如图1所示，包括：

应用服务器接收各应用进程待处理的业务数据，将该业务数据封装为多个作业包，并在作业包的包头中携带该应用进程的关联标识(本实施例采用的是应用进程对应的应用程序接口的线程号，THREAD_ID)、作业包序列号(SEQ)及业务数据的处理信息；将所述多个作业包随机分配到下行队列中；所述下行队列与业务处理系统中的业务处理模块对应，个数为固定值；

所述应用服务器分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；

所述业务处理模块分别根据各作业包的包头中所携带的处理信息，调度所述业务处理系统中相应的作业处理模块处理该作业包中的业务数据；

所述应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列；

所述应用服务器分别将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合，将组合后的数据返回给该上行队列对应的应用进程。

本实施例中业务处理系统里的每个处理器核可对应于一个或多个业务处理模块，各处理器核对应的业务处理模块数相同且固定；本实施例中，无论应用进程的数目如何改变，业务处理模块的数目都保持固定，只与处理器核的数目有关。而将各应用进程待处理的业务数据分解为作业包后随机分派到各业务处理模块对应的下行队列中，可确保每个应用进程待处理的业务数据可以尽可能平均的得到处理。

本实施例中，THREAD_ID和SEQ具有三个作用：一是用于保证作业包的有效处理和正确返回到相应的应用进程，二是在需要数据先后顺序的业务处理中作为数据的先后顺序标识，三是用于作业包的排序和组合；THREAD_ID和SEQ在作业包生命周期中全程跟随，在拆分作业包时进行填写，在进行业务数据的处理时、及给应用进程返回处理后的作业包时使用。所述THREAD_ID可以但不限于是应用进程对应的应用程序接口的的进程号或线程号。

本实施例中，所述应用服务器可以在将业务数据拆分成作业包时，从该业务数据的控制信息中获取业务数据的处理信息，并携带在该业务数据所拆分成的各作业包的包头中。

本实施例的一种实施方式中，所述应用服务器接收各应用进程待处理的业务数据的步骤前还可以包括：

根据所述业务处理系统的处理器核的个数，建立所述应用服务器与所述业务处理系统之间的多条数据连接，并建立分别与所述多条数据连接一一对应的多个下行队列，以及相应个数的业务处理模块。

该实施方式的一种备选方案中，所述业务处理模块的个数与所有应用服务器与业务处理系统之间所有数据连接的总数相同，且业务处理模块与所述数据连接一一对应。

该备选方案中，与业务处理系统连接的一个或多个应用服务器中的每个下行队列各自对应一个业务处理模块。

该实施方式的另一种备选方案中，所述业务处理模块的个数与每一个应用服务器与业务处理系统之间的数据连接的个数相同，且对于每一个应用服务器，业务处理模块和该应用服务器与业务处理系统之间的数据连接一一对应；

每个业务处理模块中包含一个或多个监听进程，与不同应用服务器一一对应；各监听进程分别用于对属于本监听进程所对应的应用服务器、且对应于本业务处理模块的数据连接进行监听。

该备选方案中，当与业务处理系统连接的应用服务器有多个时，一个业务处理模块对于每一个应用服务器，都对应且只对应该应用服务器上的一个下行队列；因此对于每一个应用服务器而言，该应用服务器上每个下行队列仍是各自对应一个业务处理模块，这多个应用服务器将复用业务处理模块。

该实施方式中，所述数据连接可以但不限于为TCP数据连接。

该实施方式中，所述应用服务器分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块的步骤具体可以包括：

所述应用服务器分别在各下行队列的作业包的包头中携带该下行队列对应的业务处理模块的标识，包括板卡号(SLOT_ID)和处理器核号(CORE_ID)；

所述应用服务器分别将各下行队列的作业包通过该下行队列对应的数据连接发送给所述业务处理系统；

所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包。

本实施方式中，板卡号(SLOT_ID)和处理器核号(CORE_ID)用于指定相应的业务板卡及相应的处理器核进行业务处理，在拆分作业包时进行填写，在进行业务数据的处理时使用。

该实施方式的一种备选方案中，所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包的步骤后还可以包括：

所述业务处理模块在通过所述数据连接所接收到的作业包的包头中增加该数据连接的标识(SOCKET_ID)；

所述应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列的步骤前还可以包括：

所述业务处理模块根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述应用服务器。

该备选方案中，数据连接的标识(SOCKET_ID)用于保证前端的应用服务器与后端的业务处理系统之间业务数据的传输和准确返回，在业务处理模块通过数据连接接收作业包时填写，在业务处理模块返回处理后的作业包时使用。

该备选方案中，无论应用进程的数目如何改变，无论应用服务器的个数是一个还是多个，每台应用服务器的数据连接的数目都保持固定，只与业务处理进程的数目(亦即处理器核的数目或其整数倍)n有关，因此该数据连接的进程个数也是固定为n个；而且作业包通过同一个数据连接传输给业务处理进程并返回，无需在返回时再次进行调度。

在其它备选方案中，也可以不为作业包增加数据连接的标识，处理后的作业包通过业务处理进程返回给应用服务器；这样如果有多个应用服务器，则需要分别为多个应用服务器各建立n个用于监视数据反馈的进程。

本实施例的一种实施方式中，所述业务数据的处理信息可以但不限于包括以下信息中的任一个或任几个：

命令字(CMD)、业务基础数据号(IV_ID)、数据长度(LONG)和业务特征预留字(reserved)等。

命令字(CMD)用于标识业务数据的处理类型，可以在拆分作业包时填写一部分，然后由业务处理进程补充完全后发送给作业处理模块；在选择作业处理模块、及作业处理模块进行业务数据的处理时使用。

业务基础数据号(IV_ID)用于为不同的业务处理制定相应的业务数据(如加密业务中选取不同的密钥等)，在拆分作业包时进行填写，在进行业务数据的处理时使用。

数据长度(LONG)用于指出本作业包内实际的有用数据的长度，LONG小于作业包的总长度，在拆分作业包时进行填写，在进行业务数据的处理时使用。

业务特征预留字(reserved)用于进行个性化业务处理使用，在拆分作业包时填写一部分，然后在填写数据连接的标识时填写完成；在选择作业处理模块、及作业处理模块进行业务数据的处理时使用。

该实施方式中，作业处理模块根据作业包的包头中的所述命令字、业务基础数据号、数据长度及业务特征预留字对作业包中的业务数据进行处理；处理后的业务数据仍放在原作业包中返回。对业务数据进行处理的实现细节，可参照现有技术或将来可能出现的方案进行；具体怎么处理并不影响本实施例的方法中其它过程的实现。

实施例二、一种业务数据的处理系统，如图2所示，包括：

业务处理系统和应用服务器；

所述业务处理系统包括：业务处理模块、作业处理模块；

业务处理模块用于分别根据各作业包的包头中所携带的处理信息，调度相应的作业处理模块处理该作业包中的业务数据；

所述应用服务器包括：

接口模块，用于接收各应用进程待处理的业务数据，将该业务数据封装为多个作业包，并在作业包的包头中携带该应用进程的关联标识、作业包序列号及业务数据的处理信息；将所述多个作业包随机分配到下行队列中；所述下行队列与所述业务处理系统中的业务处理模块对应，个数为固定值；

业务服务引擎模块，用于分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列；

所述接口模块还用于分别将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合，将组合后的数据返回给该上行队列对应的应用进程。

本实施例的一种实施方式中，所述业务服务引擎模块还可以用于在所述业务处理系统初次运行时，根据所述业务处理系统的处理器核的个数，建立与所述业务处理系统之间的多条数据连接，并建立分别与所述多条数据连接对应的多个下行队列、并通知所述业务处理系统建立相应个数的业务处理模块。

该实施方式中，所述数据连接可以但不限于为TCP数据连接。

该实施方式中，所述接口模块还可以用于分别在各下行队列的作业包的包头中携带该下行队列对应的业务处理模块的标识，包括板卡号和处理器核号；

所述业务服务引擎模块分别将各下行队列的作业包发送给该下行队列对应的业务处理模块是指：

所述业务服务引擎模块分别将各下行队列的作业包通过该下行队列对应的数据连接发送给所述业务处理系统；

所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包。

所述业务处理系统还可以包括：

通信值守模块，用于根据所述板卡号和处理器核号发送给相应的业务处理模块。

该实施方式的一种备选方案中，所述通信值守模块还可以用于在根据所述板卡号和处理器核号发送给相应的业务处理模块前，在通过所述数据连接所接收到的作业包的包头中增加该数据连接的标识；以及根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述业务服务引擎模块。

本实施例的一种实施方式中，所述业务数据的处理信息可以但不限于包括以下信息中的任一个或任几个：

命令字、业务基础数据号、数据长度和业务特征预留字。

该实施方式中，所述接口模块还可以用于在将业务数据封装为多个作业包时，从该业务数据的控制信息中获取上述处理信息，以封装到作业包的包头中。所述作业处理模块可以根据作业包的包头中的所述命令字、业务基础数据号、数据长度及业务特征预留字对作业包中的业务数据进行处理；处理后的业务数据仍放在原作业包中返回。

本实施例的一个具体的例子如图3所示，包括：

前端的应用服务器；一个应用服务器中可以运行多个相同类型或者不同类型的应用服务系统，每个应用服务系统又可以运行多个相同或不同的应用进程。所述应用服务系统是指前端应用服务器为用户提供服务的程序组，如图4所示，包括应用接口层和作业服务层。

应用接口层包括接口模块(本例子中采用与应用进程一一对应的应用程序接口引出函数API实现)、下行队列随机选择器、上行队列等部分；作业服务层包括下行队列、运行有上行数据分配进程的业务服务引擎模块等；

后端的业务处理系统是指后端根据用户需求为用户提供的业务处理及管理的程序组，可以分布在一个或多个业务板卡上，各业务板卡都设置有唯一的板卡号(SLOT_ID)。所述后端业务处理系统包括作业调度层和作业处理层。作业调度层包括配置管理程序、业务管理值守程序、若干业务处理模块及其相应的读写队列；作业处理层包括作业处理动态链接库、若干作业处理模块和若干作业处理模块的驱动程序。

一个应用服务器可以与一个业务处理系统建立连接，也可以与多个业务处理系统建立连接；一个业务处理系统可以与一个应用服务器建立连接，也可以与多个应用服务器建立连接，如图3所示。固定的应用服务器与固定的业务处理系统之间在进行业务服务过程中逻辑连接(包括一个管理连接和多个数据连接)的数目不变，同时业务处理系统中的业务处理进程的数目不变。即应用服务器与业务处理系统之间的逻辑连接数和业务处理系统的业务处理进程数不随用户或应用进程数量的改变而改变。

每个前端应用服务器和后端业务处理系统之间的逻辑连接包括一条管理连接和若干个数据连接，当有多个应用服务器时，它们中下行队列的总数与数据连接的总数相同，由后端业务处理系统自身的系统架构决定，不随着前端应用服务器的应用进程(线程)的增加而增加，降低了由于需要对不同应用进程(线程)的通信数据进行管理和维护而建立不同网络连接所花费的内存开销，也降低了由于需要对不同前端应用服务器的数据进行相应的业务处理和管理而启动相应进程(线程)所花费的内存开销，简化了对并发连接的数据管理，提高了用户并发连接的能力。

本例子的一种实施方式中，每个业务处理模块可以以一个独立的业务处理进程的方式实现，该实施方式中业务处理系统如图5a所示，作业处理层及配置管理程序、业务管理值守程序同上文所述，此时业务处理进程与前端应用服务器和后端业务处理系统之间的数据连接一一对应，通过网络协议栈通信。当有多个应用服务器时，比如图5a中的应用服务器1至应用服务器L，为每个应用服务器中的每个下行队列各建立一个业务处理进程，假设每个应用服务器中各有n个下行队列，则存在业务处理进程1-1、……、1-n、……L-1、……、L-n，业务处理进程的总个数与所有应用服务器中下行队列的总数(即n×L个)相同，此外与所有应用服务器与该业务处理系统的数据连接的总数也相同；该总数由后端业务处理系统自身的系统框架决定。本例子的另一种实施方式中，业务处理模块也可以细化为包括：一个业务调度单元、一个或多个监听单元、和一个数据反馈单元，所述业务处理模块的个数与每一个应用服务器与业务处理系统之间的数据连接的个数相同，且对于每一个应用服务器，业务处理模块和该应用服务器与业务处理系统之间的数据连接一一对应。

该实施方式中业务处理系统如图5b所示，作业处理层及配置管理程序、业务管理值守程序同上文所述，在此情况下监听单元监听数据连接，并利用消息方式通知业务调度单元从网络协议栈获取数据；一个业务处理模块中的监听单元与不同应用服务器一一对应，用于对属于本监听单元所对应的应用服务器、且与本业务处理模块对应的数据连接进行监听；此时监听单元与前端应用服务器和后端业务处理系统之间的数据连接一一对应，当有多个应用服务器时(比如图5b中的应用服务器1至应用服务器L，各有下行队列1至下行队列n)，所有业务处理模块中监听进程的总数也与所有应用服务器中下行队列的总数(即n×L)相同，和下行队列及所述数据连接一一对应；而业务调度单元和数据反馈单元的个数均为固定值n，只由后端业务处理系统自身的系统框架决定，比如但不限于为处理器核的个数，不随着前端应用服务器的应用进程(线程)或应用服务系统的增加而增加，也不随着连接的前端应用服务器的个数增加而增加。

对于每一个应用服务器而言，该应用服务器中的下行队列(以及对应该下行队列对应的数据连接)与业务调度单元是一一对应的，比如图5b应用服务器1的下行队列1至下行队列n分别对应于业务调度单元1至业务调度单元n；应用服务器L的下行队列1至下行队列n也是分别对应于业务调度单元1至业务调度单元n；即：L个应用服务器共用n个业务调度单元及数据反馈单元。而对于每一个应用服务器，各业务处理模块中各有一个对应于该应用服务器中一个下行队列的监听单元，比如图5b中业务处理模块1中包括监听单元1-1至监听单元L-1，监听单元1-1唯一对应于应用服务器1的下行队列1，监听单元L-1唯一对应于应用服务器L的下行队列1；业务处理模块n中包括监听单元1-n至监听单元L-n，监听单元1-n唯一对应于应用服务器1的下行队列n，监听单元L-n唯一对应于应用服务器L的下行队列n；其它可类推。当增加一个应用服务器时，只需要将该新增应用服务器中每个下行队列分别对应于一个业务处理模块，并且在每个业务处理模块中增加一个对应于该新增应用服务器的监听单元即可，所增加的监听单元用于监听该新增应用服务器中对应于本业务处理模块的下行队列。

本例子中，应用服务器和业务处理系统之间，以及业务处理系统进行多用户并发业务处理以作业包为单位进行操作。应用进程(线程)与前端应用服务器的应用程序接口之间的数据格式由应用程序接口约定。

本例子中的处理系统的工作流程如图6所示，包括步骤一至步骤五，其中步骤二和三可以并行。

步骤一：业务处理系统的加电启动，如图7所示，包括步骤101～103。

步骤101：业务处理系统加电，业务管理值守程序加电启动。

步骤102：业务管理值守程序根据业务处理系统的硬件信息和配置信息配置系统。

步骤103：业务管理值守程序监听网络数据，等待网络逻辑连接建立。

步骤二：逻辑连接创建(连接分为数据连接和管理连接)，如图8所示，包括步骤201～206。

步骤201：启动业务服务引擎模块。

步骤202：业务服务引擎模块获取业务处理系统的配置信息，如业务处理系统个数、业务处理系统IP地址、业务处理系统的下行队列起始键值等。

步骤203：业务服务引擎模块向业务板(即业务处理系统)的管理端口发送TCP连接请求，确定端口号，建立管理连接。管理连接在一个应用服务器和一个业务处理系统之间只存在一条；管理连接用于维护前端应用服务器和后端业务处理系统之间的网络连接，在运行生命周期内始终维持连接；管理连接在空闲时产生心跳信号维护业务板的工作状态。步骤204：业务服务引擎模块向业务板发送获取业务板的CPU Core个数的命令字，业务板响应请求，并将CPU Core个数值返回给业务服务引擎模块。

步骤205：业务服务引擎模块根据业务板的CPU Core个数修改配置文件，并向业务板的业务端口建立对应的TCP数据连接，比如每个CPU Core建立一条双向的TCP数据连接；业务处理系统建立相应个数的业务处理进程。

如果采用业务处理进程独立的方式，如图5a所示，根据各应用服务器的数据连接总数建立相应个数的业务处理进程；如果采用如图5b所示方式进行实现，如果是第一台应用服务器建立连接，则建立若干监听进程、业务调度进程和数据反馈进程，且与该应用服务器的数据连接一一对应，如果后面再增加连接的应用服务器，只需要建立相应的监听进程、监听进程与相应的业务调度进程之间的消息管道即可。

步骤206：连接建立完成。

步骤三：配置连接建立，包括步骤301～304。

步骤301：用户启动控制台管理程序。

步骤302：控制台管理程序查找配置文件，获取业务板IP地址。

步骤303：根据IP地址，与业务板建立管理连接，端口号为6006。

步骤304：配置连接建立成功，之后可通过管理界面进行配置和操作，实现如系统配置、信息管理、权限管理等管理功能。

步骤四：数据处理及调用流程，如图10所示，包括步骤401～410。

假设存在应用进程App1～App M，已经完成初始连接建立流程，现进行数据的处理。

步骤401：用户通过图4所示的应用进程App1～App M分别调用应用程序接口引出函数(API1～API M)接口，若该用户调用为系统初次运行，则执行步骤402，否则执行步骤403；

步骤402：系统数据队列初始化，作业服务层负责建立下行队列：根据CPU Cores个数建立数据下行队列，每个下行队列对应一个CPU Core，队列的初始键值在配置文件中设定。下行队列的数量与业务服务引擎模块建立的TCP数据连接的数量相同(本例子中与业务处理系统的CPU Core的个数也相同)，并且一一对应。

数据连接在一个前端应用服务器和一个后端业务处理系统之间的数目固定，其数目由后端业务处理系统的多核处理系统的核数决定；数据连接用于进行前端应用服务器和后端业务处理系统之间处理数据的交换，在运行生命周期内始终维持连接。

步骤403：应用接口层的API接收用户使用请求及待处理的业务数据，分割业务数据，当待处理的业务数据较大时，将业务数据中的应用数据包分割成多个作业包，填充作业包头，并将应用进程的关联标识——进程(或线程)号(THREAD_ID)、部分命令字(CMD)、业务基础数据号(IV_ID)、作业包序列号(SEQ)、数据长度(LONG)和部分业务特征预留字(reserved)填写到预留的作业包包头。

应用数据包是指每个用户在相应的应用进程下产生的需要业务处理系统处理的数据包，该数据包为不限制长度的数据包。

作业包是业务处理的数据操作单位。应用数据包通过应用进程调用应用程序接口引出函数(API)对要处理的数据进行封装，生成作业包，然后进入业务处理系统进行处理。作业包由作业包头和业务数据两部分组成，如图11所示。作业包头根据不同的业务处理需求可以设置成不同的长度(如设置为16字节)，其基本信息包括数据连接的标识(SOCKET_ID)、板卡号(SLOT_ID)、处理器核号(CORE_ID)、命令字(CMD)、数据长度(LONG)、业务特征预留字(reserved)、业务基础数据号(IV_ID)、作业包序列号(SEQ)、应用进程的关联标识(THREAD_ID)等基本字段，如图12所示。作业包为限制了大小范围的限定长度数据包，可以根据业务处理系统的特征定义最小长度和最大长度，最大长度为最小长度的整数倍。作业包头的长度在一个业务处理系统中为固定长度，不同业务处理系统可以设定为不同长度。例如：一个业务处理系统可以定义一个作业包的长度为不小于128字节不大于2k字节。在进行应用数据包到作业包分割打包时首先按照最大长度进行打包，当最后一组数据不够一次业务处理数据最小分组长度时(如不足128字节)，进行补足。

步骤404：应用接口层的API根据部分命令字(CMD)和部分业务特征预留字(reserved)，结合业务服务引擎模块的业务资源调用下行队列随机选择器确定该作业包对应的下行队列，并将该下行队列所对应的板卡号(SLOT_ID)、处理器核号(CORE_ID)填写到作业包的包头，将作业包发送到下行队列。

下行队列为作业包的发送缓冲队列，内部缓冲的数据以作业包为单位。由应用服务器的作业服务层创建，与业务处理系统中作业调度层的业务处理进程(如图5a所示)或者与业务处理系统中的监听进程(如图5b所示)一一对应，如图4中的下行队列1至下行队列n，n为大于1的正整数。

步骤405：业务服务引擎模块监控下行队列的状态，并实时将下行队列中的作业包直接(或者打包为报文)通过相应的数据连接发送给业务处理系统。

一个报文包括多个完整的作业包，报文内作业包总长度不小于网络协议要求的最小数据包长度，不大于操作系统支持的最大包长度(64K字节)。报文结构如图13所示。报头信息包括报文头标识(2字节)、版本号(2字节)、报文长度(4字节)、作业包个数(4字节)、预留字(4字节)等，如图14所示。其中报文长度只包含报文内连续作业包的总长度，该长度不包括16字节报头。

步骤406：业务处理系统的作业调度层的业务处理模块通过对socket的监听接收作业包，填写作业包的数据连接的标识(SOCKET_ID)和部分业务特征预留字(reserved)，并根据板卡号和处理器核号从相应的数据连接中接收所述作业包。

如果采用图5a所示方式，由业务处理进程完成所述内容；如采用图5b所示方式，由监听进程以阻塞的方式监听对应的数据连接是否有数据，如有数据，则通过消息方式通知(消息内容包含SOCKET_ID)相应板卡号和处理器核号对应的业务调度进程从相应的数据连接读取数据，并填写作业包的数据连接的标识(SOCKET_ID)和部分业务特征预留字(reserved)，然后由业务调度进程调度相应的作业处理模块进行业务处理。

步骤407：业务处理进程(图5a的情况)或业务调度进程(图5b的情况)根据作业包的命令字(CMD)、业务基础数据号(IV_ID)、数据长度(LONG)和业务特征预留字(reserved)，补充命令字(CMD)并通过所述作业处理动态链接库及相应的驱动程序调度相应的作业处理模块完成对作业包中业务数据的业务处理。

作业处理模块根据作业包的命令字(CMD)、业务基础数据号(IV_ID)、数据长度(LONG)和业务特征预留字(reserved)对作业包的数据进行处理，并将处理完成后的数据包通过本作业处理模块的驱动程序及作业处理动态链接库返回作业调度层。

步骤408：业务处理系统根据作业包的数据连接的标识(SOCKET_ID)将作业包通过相应的数据连接发送给应用服务器。

如果采用图5a所示方式，处理完成后的数据返回给业务处理进程，由业务处理进程根据作业包的数据连接的标识(SOCKET_ID)将作业包通过相应的数据连接发送给应用服务器；如果采用图5b所示方式，处理完成后的数据返回给数据反馈进程，由数据反馈进程根据作业包的数据连接的标识(SOCKET_ID)将作业包通过相应的数据连接发送给应用服务器。

步骤409：应用服务器的业务服务引擎模块中的上行数据分配进程根据作业包包头中的应用进程的关联标识——进程(或线程)号(THREAD_ID)信息将作业包放入相应应用进程对应的上行队列。

上行队列为向用户的应用进程返回的业务处理结果的队列，与用户的应用进程一一对应，如图3中的上行队列1～上行队列M分别与API1～API M对应、还分别与应用进程App1至App M对应，M为正整数。

步骤410：应用接口层对应于一上行队列的API根据该上行队列中作业包包头中的作业包序列号(SEQ)信息对作业包进行排序和组合，并将组合后完整的数据返还给相应的应用进程。

步骤五：连接断开。

一个固定的应用服务器和一个固定的业务处理系统在服务周期内不主动进行连接断开的操作，由业务处理系统的业务管理值守程序维护连接。

在应用服务器或业务处理系统任意一方断电、应用服务器的业务服务引擎模块或业务处理系统的业务管理值守程序任意一方宕机、或业务处理系统在配置连接下进行相应配置时，才会出现断开连接的情况。连接一旦断开，必须重新从步骤一开始操作。

其它实现细节可参见实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明的权利要求的保护范围。

Claims (14)

1.一种业务数据的处理方法，包括：

应用服务器接收各应用进程待处理的业务数据，将该业务数据封装为多个作业包，并在作业包的包头中携带该应用进程的关联标识、作业包序列号及业务数据的处理信息；将所述多个作业包随机分配到下行队列中；所述下行队列与业务处理系统中的业务处理模块对应，个数为固定值；

所述应用服务器分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；

所述业务处理模块分别根据各作业包的包头中所携带的处理信息，调度所述业务处理系统中相应的作业处理模块处理该作业包中的业务数据；所述应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列；

所述应用服务器分别将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合，将组合后的数据返回给该上行队列对应的应用进程。

2.如权利要求1所述的方法，其特征在于，所述应用服务器接收各应用进程待处理的业务数据的步骤前还包括：

根据所述业务处理系统的处理器核的个数，建立所述应用服务器与所述业务处理系统之间的多条数据连接，并建立分别与所述多条数据连接一一对应的多个下行队列，以及相应个数的业务处理模块。

3.如权利要求2所述的方法，其特征在于，所述应用服务器分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块的步骤包括：

所述应用服务器分别在各下行队列的作业包的包头中携带该下行队列对应的业务处理模块的标识，包括板卡号和处理器核号；

所述应用服务器分别将各下行队列的作业包通过该下行队列对应的数据连接发送给所述业务处理系统；

所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包。

4.如权利要求3所述的方法，其特征在于，所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包的步骤后还包括：

所述业务处理模块在通过所述数据连接所接收到的作业包的包头中增加

该数据连接的标识；

所述应用服务器将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列的步骤前还包括：

所述业务处理模块根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述应用服务器。

5.如权利要求1所述的方法，其特征在于，所述业务数据的处理信息包括以下信息中的任一个或任几个：

命令字、业务基础数据号、数据长度和业务特征预留字。

6.如权利要求2所述的方法，其特征在于：

所述业务处理模块的个数与所有应用服务器与业务处理系统之间所有数据连接的总数相同，且业务处理模块与所述数据连接一一对应。

7.如权利要求2所述的方法，其特征在于：

所述业务处理模块的个数与每一个应用服务器与业务处理系统之间的数据连接的个数相同，且对于每一个应用服务器，业务处理模块和该应用服务器与业务处理系统之间的数据连接一一对应；

每个业务处理模块中包含一个或多个监听进程，与不同应用服务器一一对应；各监听进程分别用于对属于本监听进程所对应的应用服务器、且对应于本业务处理模块的数据连接进行监听。

8.一种业务数据的处理系统，包括：

业务处理系统和应用服务器；

其特征在于，所述业务处理系统包括：作业处理模块；

业务处理模块，用于分别根据各作业包的包头中所携带的处理信息，调度相应的作业处理模块处理该作业包中的业务数据；

所述应用服务器包括：

接口模块，用于接收各应用进程待处理的业务数据，将该业务数据封装为多个作业包，并在作业包的包头中携带该应用进程的关联标识、作业包序列号及业务数据的处理信息；将所述多个作业包随机分配到下行队列中；所述下行队列与所述业务处理系统中的业务处理模块对应，个数为固定值；

业务服务引擎模块，用于分别将各下行队列中的作业包发送给该下行队列对应的业务处理模块；将处理完的作业包按照包头中的应用进程的关联标识放入该应用进程对应的上行队列；

所述接口模块还用于分别将各上行队列中的作业包根据包头中的作业包序列号进行排序和组合，将组合后的数据返回给该上行队列对应的应用进程。

9.如权利要求8所述的系统，其特征在于：

所述业务服务引擎模块还用于在所述业务处理系统初次运行时，根据所述业务处理系统的处理器核的个数，建立与所述业务处理系统之间的多条数据连接，并建立分别与所述多条数据连接一一对应的多个下行队列，并通知业务处理系统建立相应个数的业务处理模块。

10.如权利要求9所述的系统，其特征在于：

所述接口模块还用于分别在各下行队列的作业包的包头中携带该下行队列对应的业务处理模块的标识，包括板卡号和处理器核号；

所述业务服务引擎模块分别将各下行队列的作业包发送给该下行队列对应的业务处理模块是指：

所述业务服务引擎模块分别将各下行队列的作业包通过该下行队列对应的数据连接发送给所述业务处理系统；

所述业务处理模块根据自身的板卡号和处理器核号从相应的数据连接接收作业包。

11.如权利要求10所述的系统，其特征在于：

所述业务处理模块还用于在通过所述数据连接所接收到的作业包的包头中增加该数据连接的标识；还用于根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述业务服务引擎模块。

12.如权利要求8所述的系统，其特征在于，所述业务数据的处理信息包括以下信息中的任一个或任几个：

命令字、业务基础数据号、数据长度和业务特征预留字。

13.如权利要求9所述的系统，其特征在于：

所述业务处理模块的个数与所有应用服务器与业务处理系统之间所有数据连接的总数相同，且业务处理模块与所述数据连接一一对应。

14.如权利要求9所述的系统，其特征在于：

所述业务处理模块的个数与每一个应用服务器与业务处理系统之间的数据连接的个数相同，且对于每一个应用服务器，业务处理模块和该应用服务器与业务处理系统之间的数据连接一一对应；

各业务处理模块分别包括：

一个或多个监听单元，与不同应用服务器一一对应，用于对属于本监听单元所对应的应用服务器、且对应于本业务处理模块的数据连接进行监听；

一个业务调度单元，用于从本业务处理模块对应的数据连接接收作业包，并分别根据各作业包的包头中所携带的处理信息，调度相应的作业处理模块处理该作业包中的业务数据；

一个数据反馈单元，用于根据处理完的作业包的包头中的数据连接的标识，将处理完的作业包通过相应的数据连接返回给所述业务服务引擎模块。

Images