CN101021801A - 流水线多进程之间基于消息队列的海量数据传输方法 - Google Patents

Abstract

流水线多进程之间基于消息队列的海量数据传输方法，在计费产品业务处理流程中一条话单顺序通过至少分为格式化、规整(或者称为分拣)、排重、批价、入库多个进程，计费方法采用单步与整体提交相结合的机制，通过配置来实现在不同环境下采用不同消息队列类型自动分配任务，负载均衡管理，将话单分发至不相同的消息队列，根据业务逻辑，自定义方式进行部署。采用本发明方法实现的计费系统海量的话单数据在进程间的传输，全部通过消息队列，处理过程可以在内存里面实现，没有系统IO的开销，速度大大提高。采用基于消息队列的流水线并行处理技术方案的系统处理效率明显提高。处理速度在国内外计费厂家中名列前茅。

Description

流水线多进程之间基于消息队列的海量数据传输方法

技术领域

本发明属于电信运营商大规模准确数据处理应用技术范畴，尤其涉及多进程之间基于消息队列的海量数据传输方法。

背景技术

计费系统处理的数据都是海量数据，目前中国电信运营商一般以省为单位建设计费系统，通常1000万用户量的计费系统每月处理话单达到亿数量级。如何提高系统处理效率，是至关重要的问题。在解决效率问题上，联创计费产品有很多自主创新的方面，这里重点说明一下消息队列在计费产品中进程间数据传输上的创新。

国内外电信计费产品在处理海量话单数据的情况下，为了提高系统性能，充分利用主机多CPU的特性，采用多进程流水线处理技术，实现话单的高效处理。流水线技术主要通过让多个进程在同一时间上交划重叠地并行运算和处理，以实现时间上的并行。

申请号为CN00808157.3的专利：用于监视正在计算机系统中执行的应用内的子进程的建立和解除的方法和设备，其中每个子进程具有一个对应的子进程数据库结构，该正执行应用具有一个对应的应用进程数据库结构，该方法包括：提供一个用来存储和该正执行应用内的现存的子进程对应的现存子进程数据库结构的表；判定该应用执行中何时建立新进程；检索和该新进程对应的新进程数据库结构；利用该新进程数据库结构检索和该新进程的父进程对应的父进程数据库结构；比较该父进程数据库结构和该应用进程数据库结构；若该父进程数据库结构和该应用进程数据库结构相同，把该新进程标识为一个现存子进程；以及若把该新进程标识为现存子进程，把该新进程数据库结构添加到该现存子进程数据库结构表中。

一般计费产品业务处理流程中至少分为格式化、规整(或者称为分拣)、排重、批价、入库等多个进程，一条话单要顺序通过一个流程中的格式化、规整、排重、批价、入库等进程，第1条话单经过整个流程结束以后，第2条话单才进入该流程。假设T时间内处理一条话单，格式化、规整、排重、批价、入库每个进程处理话单的时间为1/5的T时间，那么系统采用流水线技术以后，在多CPU主机环境下，不考虑系统IO开销，话单处理速度将会提高5倍。然而这是很理想的状况，因为系统IO开销，会造成处理速度不能够提高5倍。如果能避免IO开销，那么处理速度不就提高了吗？但是目前的计费产品考虑事务的一致性，考虑话单的回退，仍然采用文件传输的方法实现话单在进程间的传输。

在国内外计费产品中，普遍使用多进程流水线并行处理技术提高系统处理效率。实际使用情况来看，效率提高也是比较明显的。一个计费流程一般包括格式化、规整、排重、批价、入库等多个进程，相当于一个流水线中的多个岗位。原始话单文件中的话单放在计费系统的输入目录，经历流水线各个进程以后，最终经入库进程加载到数据库中。

为什么其他厂家的计费产品中各个进程之间使用文件传输？为何系统不处理一条话单，就将话单送给下一进程呢？

这是因为计费系统的稳定性要求很高，一旦出错，需要回退处理，回退在计费系统中非常复杂。所以许多计费公司无法做到回退，所以等一个文件完全处理完毕，将整个文件提交。如果将一条话单处理好了，就提交给下一进程，万一系统异常宕机，一个文件中不同话单处理到什么阶段很难判断，这个文件无法重新处理，破坏了数据完整性。如果以整个文件进行提交，一个文件处理完毕才将处理结果进行提交，那么在处理过程中如果发生宕机，这个文件都没有提交。

写到文件里面有IO开销，为什么不把文件内已经处理的话单数据放到内存里面，一个文件处理完再提交呢？由于内存大小是有限的，但是话单文件大小是无限的，所以一个进程没有处理完一个文件之前，将已经处理完的话单保存在临时文件中，等处理完毕，再将此临时文件改为正式文件，送给下一进程。

这种思想非常简单，但是给系统带来了IO开销，直接影响到系统的处理效率。

发明内容

本发明目的是：在保证系统的稳定性和数据处理完整性的前提下，采用消息队列方式实现话单在进程间的传输，减少系统IO开销，加快处理速度。

本发明技术解决方案是：流水线多进程之间基于消息队列的海量数据传输方法，在计费产品业务处理流程中一条话单顺序通过至少分为格式化、规整(或者称为分拣)、排重、批价、入库多个进程，计费方法采用单步与整体提交相结合的机制：

格式化作为计费流程的源头，将一个文件内的话单根据分发规则分发到不同的后续流程的规整进程里面，当结束一个文件格式化的时候，格式化进程发送此文件结束信号给各个后续的规整进程；每个规整进程接收到一个文件结束信号，就进行本进程的单步提交，说明此进程已经处理完毕输送到本流程的此文件的所有话单；然后规整进程将结束信号送给下一步的排重进程，排重进程同样的处理机制，进行单步提交；排重进程和批价进程也是同样处理方式；批价进程再将结束信号送给入库进程，入库进程进行单步提交；只有当格式化将结束信息输送的所有流程的入库进程对这个文件进行提交完毕，系统才进行这个文件的整体提交；如果系统在处理过程中，需要中断，这个时候一个文件在整个流水线中没有处理完毕，那么计费进程采用不精确/模糊断点；不精确/模糊断点是指当发生中断后，计算机并不立即响应中断，而是等待一个文件中的所有话单完毕，才响应该中断；

如果系统发生异常宕机，那么系统重新启动的时候，系统自动发现有哪些文件入库进程前的进程已经提交，但是流水线最终进程入库进程没有对这个文件进行提交，那么说明这个文件在处理过程中存在问题，就进行告警；维护人员进行检查，发现原因，进行这个文件的文件级回退处理

文件级回退需要对整个文件在计费系统中各处留下的痕迹进行清理，是计费过程的逆向操作，恢复到最初状态。

本发明计费方法充分考虑系统的回退，同时严格的提交机制，为采用消息队列做好保证。

本发明计费方法采用单步与整体提交相结合的机制。

只有当格式化将结束信息输送的所有流程的入库进程对这个文件进行提交完毕，系统才进行这个文件的整体提交。

流水线技术处理中断的方法有不精确断点法和精确断点法两种。不精确断点法是指当发生中断后，计算机并不立即响应中断，而是等待一个文件中的所有话单完毕，才响应该中断。

事务控制技术和回退技术，保证了系统的稳定，也为消息队列的引入作为技术保证。

本发明可以通过配置来实现在不同环境下采用的消息队列类型；消息队列是一个消息的链表；在计费系统中，消息就可以等同于话单，是具有特定格式的记录；对消息队列有写权限的进程可以向其中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息；采用统一的消息队列数据结构，就是通过标准话单的结构，任意进程之间可以通过配置，建立消息队列，这样灵活实现各个进程之间话单的传输；计费系统海量的话单数据在进程间的传输，全部通过消息队列，在内存里面实现。

本发明通过自动分配任务，负载均衡管理，将话单分发至少相同的消息队列，根据业务逻辑，自定义方式进行部署。

本发明特点是：采用本发明方法实现的计费系统海量的话单数据在进程间的传输，全部通过消息队列，处理过程可以在内存里面实现，没有系统IO的开销，速度大大提高。采用基于消息队列的流水线并行处理技术方案的系统处理效率明显提高。处理速度在国内外计费厂家中名列前茅。

附图说明

图1是不同方式完成话单任务处理的时间过程示意图。

图2是自动分配任务处理进程图。

图3是本发明计费系统中处理流程示意图。

具体实施方式

如图2所示，通过图2中自动分配任务，负载均衡管理，将话单分发至不同的消息队列。

消息队列就是一个消息的链表。在计费系统中，消息就可以等同于话单，是具有特定格式的记录。对消息队列有写权限的进程可以向其中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。

目前主要有两种类型的消息队列：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。考虑到程序的可移植性，本发明计费方法通过配置来实现在不同环境下采用哪种消息队列类型。

本发明计费流程是可以根据业务逻辑，自定义方式进行部署的，例如有些流程不需要经过排重进程，那么直接在规整进程和批价进程之间建立消息队列；联创采用统一的消息队列数据结构，就是标准话单的结构，任意进程之间可以通过配置，建立消息队列，这样灵活实现各个进程之间话单的传输。

计费系统海量的话单数据在进程间的传输，全部通过消息队列，在内存里面实现，没有系统IO的开销，速度大大增强。

以下是计费系统处理效率的测试情况。

测试环境：IBM P650 16*1.5G CPU，32G RAM

测试对象：一个省的计费话单，待入库文件数为：101724个，共有628779011条记录。

测试方法：将文件放置于系统输入目录；系统采用单流程(单流水线)进行测试，2种测试的区别在于：第一种测试方法话单在进程间的传输基于文件方式，第二种测试方法话单在进程间的传输基于消息队列方式；启动计费系统，记录开始时间；监控输入目录的文件个数直至为零，记录结束时间。

测试结果：话单基于消息队列的进程间传输：系统耗时：36557秒

话单基于文件的进程间传输：系统耗时：66362秒。

测试结论：话单基于消息队列的进程间传输方式下，系统处理效率有很大提高。如图3所示：

1、首先在计费系统中部署处理流程，也可以称为部署一条流水线，在流程中部署本流程

涉及的进程；消息队列的建立是自定义方式，按照业务逻辑，2个相关进程之间用黑线连接，系统后台自动建立消息队列；

2、在消息队列属性中配置前一进程向后续进程分发的条件；

3、将流水线中所有的进程启动起来；

4、一个文件送入流水线的第一个进程即格式化进程，此进程将文件打开，读入一条话单，处理完毕，根据条件，格式化进程通过消息队列，发送话单到其后续的某一个规整进程，此规整进程在不断扫描消息队列，如果发现此进程和其关联的格式化进程之间的消息队列里面有话单，那么就立即处理，处理完毕，将话单通过消息队列传给满足条件的排重进程；排重进程和批价进程、批价进和入库进程也是同样原理；最终入库进程将话单送到数据库中；

5、如果某一进程处理缓慢，造成前一进程跟自身建立的消息队列空间满负荷，那么就会发生堵塞，前一进程无法将话单通过消息队列传输过来，前一进程就进行sleep，直到此消息队列有空间，才会继续处理；

6、格式化进程处理完一个文件的时候，就通过消息队列，发送文件结束信息给后续的规整进程，同时进行单步提交；规整、排重、批价、入库等进程同样道理，收到文件结束消息，就进行本文件在该进程单步提交；

7、当所有的入库进程收到某个文件的结束信息，系统进行该文件在本系统的整体提交。添加新消息的方式是：

系统启动的时候创建消息队列，消息队列的内核持续性要求每个消息队列都在系统范围内对应唯一的键值，所以，要获得一个消息队列的描述字，只需提供该消息队列的键值即可；消息队列描述字是由在系统范围内唯一的键值生成的，而键值可以看作对应系统内的一条路经。

系统处理过程中，消息队列存在大量的读写操作，对于前一进程发送消息来说，首先预置一个msgbuf缓冲区检查消息队列是否满，如果满，那么就先sleep，直到消息队列有空余，调用相应的发送函数即可，在系统V消息队列采用msgsnd系统函数，在POSIX消息队列中使用mq_send系统函数，将消息内容发送到消息队列中；对于后一进程读取消息，首先分配这样一个msgbuf缓冲区，检查消息队列中是否有消息，如果没有消息，就进入sleep状态，直到消息队列中有消息，在系统V消息队列采用msgrcv系统函数，在POSIX消息队列中使用mq_receive系统函数，从消息队列中将最先进入消息队列的消息读取出来。

图3中通过配置来实现在不同环境下采用不同消息队列(POSIX消息队列以及系统V消息队列，系统V消息队列)类型的方式(消息队列是一个消息的链表)；

由于操作系统定义，一些系统调用会不同，首先在系统配置文件中需要定义操作系统类型，目前主流的操作系统包括HP UNIX、SOLARIS、LINUX和AIX，系统支持的标准对消息队列有影响，存在POSIX or SYSTEM_V标准

在系统的编译定义文件里面配置操作系统类型，通过操作系统类型控制采用POSIX消息队列还是SYSTEM_V消息队列。

编译定义文件格式如下：

#定义操作系统类型

#OS_DEF＝DEF_HP

#OS_DEF＝DEF_SOLARIS

OS_DEF＝DEF_LINUX

#OS_DEF＝DEF_AIX

#系统支持的标准，这个对消息队列有影响

#POSIX or SYSTEM_V

#惠普的机器的消息队列使用POSIX，其他的机器用SYSTEM_V

：ifeq($(OS_DEF)，DEF_HP)

SYS_TYPE＝POSIX

：else

SYS_TYPE＝SYSTEM_V

：endif

系统通过条件编译来满足不同定义下的消息队列的实现。

采用统一的消息队列数据结构，就是通过标准话单的结构，任意进程之间可以通过配置，建立消息队列，这样灵活实现各个进程之间话单的传输；计费系统海量的话单数据在进程间的传输，全部通过消息队列在内存里面实现。

采用统一的消息队列数据结构，就是标准话单的结构，一般的话单结构至少包括以下内容：

Struct StdEvent

{

//原始的主叫方号码

char m_sOrgCallingNBR[40]；

//原始的被叫号码

char m_sOrgCalledNBR[40]；

//事件起始时间

char m_sStartDate[15]；

//事件时长

int m_iDuration；

}

任意进程之间可以通过配置，建立消息队列，这样灵活实现各个进程之间话单的传输。例如存在前一进程A，后一进程B，系统在配置表中配置进程B的消息队列Q的属性，那么系统启动的时候就会根据定义，建立相应大小的消息队列Q，属主是进程B。同时系统建立分发规则配置表，配置表中是分发条件，方向是A发向B。那么进程A处理完一条话单，就会判断此话单是否满足分发条件，如果满足分发条件，就把话单发向B进程的消息队列。

Claims (3)

1、流水线多进程之间基于消息队列的海量数据传输方法，在计费产品业务处理流程中一条话单顺序通过至少分为格式化、规整(或者称为分拣)、排重、批价、入库多个进程，计费方法采用单步与整体提交相结合的机制：

格式化作为计费流程的源头，将一个文件内的话单根据分发规则分发到不同的后续流程的规整进程里面，当结束一个文件格式化的时候，格式化进程发送此文件结束信号给各个后续的规整进程；每个规整进程接收到一个文件结束信号，就进行本进程的单步提交，说明此进程已经处理完毕输送到本流程的此文件的所有话单；然后规整进程将结束信号送给下一步的排重进程，排重进程同样的处理机制，进行单步提交；排重进程和批价进程也是同样处理方式；批价进程再将结束信号送给入库进程，入库进程进行单步提交；只有当格式化将结束信息输送的所有流程的入库进程对这个文件进行提交完毕，系统才进行这个文件的整体提交；

如果系统在处理过程中，需要中断，这个时候一个文件在整个流水线中没有处理完毕，那么计费进程采用不精确/模糊断点；不精确/模糊断点是指当发生中断后，计算机并不立即响应中断，而是等待一个文件中的所有话单完毕，才响应该中断；

如果系统发生异常宕机，那么系统重新启动的时候，系统自动发现有哪些文件入库进程前的进程已经提交，但是流水线最终进程入库进程没有对这个文件进行提交，那么说明这个文件在处理过程中存在问题，就进行告警；

文件级回退需要对整个文件在计费系统中各处留下的痕迹进行清理，是计费过程的逆向操作，恢复到最初状态。

2、根据权利要求1多进程之间基于消息队列的海量数据传输方法，其特征是通过配置来实现在不同环境下采用不同消息队列类型；消息队列是一个消息的链表；在计费系统中，消息就可以等同于话单，是具有特定格式的记录；对消息队列有写权限的进程可以向其中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息；采用统一的消息队列数据结构，就是通过标准话单的结构，任意进程之间可以通过配置，建立消息队列，这样灵活实现各个进程之间话单的传输；计费系统海量的话单数据在进程间的传输，全部通过消息队列，在内存里面实现。

3、根据权利要求1多进程之间基于消息队列的海量数据传输方法，其特征是自动分配任务，负载均衡管理，将话单分发至不相同的消息队列，根据业务逻辑，自定义方式进行部署。

Images