CN1787588A - 多进程消息处理方法以及多进程话单处理的方法 - Google Patents
多进程消息处理方法以及多进程话单处理的方法 Download PDFInfo
- Publication number
- CN1787588A CN1787588A CNA2005101257362A CN200510125736A CN1787588A CN 1787588 A CN1787588 A CN 1787588A CN A2005101257362 A CNA2005101257362 A CN A2005101257362A CN 200510125736 A CN200510125736 A CN 200510125736A CN 1787588 A CN1787588 A CN 1787588A
- Authority
- CN
- China
- Prior art keywords
- ticket
- load
- shared drive
- memory block
- drive piece
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 311
- 238000012545 processing Methods 0.000 title claims abstract description 38
- 230000008569 process Effects 0.000 claims abstract description 207
- 238000013507 mapping Methods 0.000 claims description 27
- 230000003068 static effect Effects 0.000 claims description 6
- 208000037656 Respiratory Sounds Diseases 0.000 claims description 3
- 206010037833 rales Diseases 0.000 claims description 3
- 230000015572 biosynthetic process Effects 0.000 description 87
- 238000005755 formation reaction Methods 0.000 description 87
- 230000007246 mechanism Effects 0.000 description 16
- 230000006870 function Effects 0.000 description 9
- 230000005856 abnormality Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000003672 processing method Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000005303 weighing Methods 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明涉及一种多进程消息处理方法以及多进程话单处理的方法。所述的多进程话单处理的方法,用于计费系统中对话单的并行处理,包括:1)为每个进程建立一块共享内存;2)进程读取共享内存块中存储的话单进行处理;3)基于内存块当前占用状况,根据预置的负载均衡规则分配话单保存到共享内存块,且将同一收费号码的话单存储到同一块共享内存。该方法不仅保证了话单处理的高效性,能满足实时业务的要求;同时基于系数组的负载策略定义,直观反映了负载情况,也保证了处理同一收费号码话单的时序性。
Description
技术领域
本发明涉及多进程消息处理方法,尤其是一种多进程间消息处理的负载均衡方法。本发明还涉及一种实时计费方法,尤其是一种多进程话单处理的方法。
背景技术
现有的多进程消息处理方法是通过在组件间约定的进程间通信(IPC)机制(如管道、套接字、消息队列)或目录文件把数据分发到组件进行处理。
.以套接字(管道)为例,在前置处理环节进程和后继处理环节进程之间建立一个连接(在管道机制中为一读一写两个管道),一个进程写入数据,另一个进程从中读出数据;后继处理环节进程定期把处理速度反馈给前置处理环节进程,所述反馈可采用IPC机制/文件/数据表等形式实现,进而,前置处理环节进程根据后继处理环节进程的反馈进行数据的分发,决定当前数据由哪个后继处理环节进程处理。
这种模式下,前置处理环节进程要确保后继处理环节进程收到数据,需要得到后继处理环节进程的确认信息。如果后继处理环节进程出现异常或任务滞留,前置处理进程将会陷入等待。另外这种机制性能有限,不能适应大量数据交换。
以消息队列为例,在消息队列方式下,每个进程建立一个消息队列。前置处理环节进程向后继处理环节进程的队列中发送数据,后继进程从中读出数据。后继处理环节进程定期把处理速度反馈给前置处理环节进程,所述反馈可采用类似IPC机制/文件/数据表等形式实现,前置处理环节进程根据后继处理环节进程的反馈进行数据的分发,决定由哪个进程进行下一步处理。
这种模式下,前置处理进程把数据放入队列就可以继续工作。但消息队列的应用程序接口(API)有限,后继处理环节进程无法得知队列里的数据积压情况;另外这种机制性能有限,不能适应大量数据交换。
综上所述,采用现有技术,后继处理环节任务的滞留将引起前置处理环节的等待,进而前置处理环节不能进行其它任务的调度,进而造成部分进程繁忙而另一部分进程处于等待状态的进程间负载失衡的状况。虽然现有的消息队列机制具有缓冲的作用,但进程间通信(IPC)没有提供访问队列状态的应用程序接口(API)。并且,现有技术中,若进程出现异常,操作系统将收回该进程使用的内存,导致丢失该块内存中的数据。现有技术采用机制的性能相对较慢,无法满足实时业务的需求。
发明内容
本发明的目的是提供一种多进程消息处理方法,该方法能够均衡各进程的数据负载;进一步该方法在进程出现异常时能够避免数据的丢失;并且该方法能够提供较高的处理速度。相应的,本发明的另一目的是提供一种采用所述进程消息处理方法的计费方法。
为解决上述技术问题,本发明提供了一种多进程消息处理方法,包括:1)为每个进程分配一块共享内存;2)进程读取共享内存块中存储的消息进行处理;3)基于内存块当前占用状态,将待处理消息根据预置的负载均衡规则存储到确定的共享内存块中。
在上述方法基础上,3)中所述负载均衡规则具体为:计算内存块已用容量与内存块静态容量的比值作为进程载荷,并将待处理消息发送到当前进程载荷最小的内存块;或者,获取最大进程载荷与最小进程载荷的比值,若该比值大于预置的门限值,则根据负载均衡规则保存待处理消息。所述负载均衡规则可选择将待处理消息发送到当前剩余容量最大的内存块。
在上述方法基础上,3)中进一步周期性的获得共享内存块的进程载荷,判断最小进程载荷是否大于预置的上限门限值,若大于则启动更多组件,并触发根据负载均衡规则保存待处理消息。
上述方法中,进程处理确定内存块中消息时,采用访问控制锁的方式限制其他进程对该内存块的访问。
本发明还提供了一种多进程话单处理的方法,用于计费系统中对话单的并行处理,包括:1)为每个进程建立一块共享内存;2)进程读取共享内存块中存储的话单进行处理;3)基于内存块当前占用状况,根据预置的负载均衡规则分配话单保存到共享内存块,且同一帐户号码的话单存储到同一块共享内存。
上述方法基础上,1)中还包括建立共享内存块与帐户号段的映射关系,根据该对应关系保存确定号段的话单存到共享内存块;以及,3)中所述根据预置的负载均衡规则分配话单的操作具体为:调整共享内存块所映射的帐户号段范围。所述内存块与号段的映射关系可为线性映射关系或非线性映射关系。
上述方法中,3)具体为:计算各内存块的进程载荷[g1,g2...,gn],所述进程载荷为共享内存块当前占用容量与共享内存块静态容量的比值;计算共享内存块的平均载荷量
其中n为内存块数;以及,所述负载均衡具体为通过
更新各共享内存块与号段的映射系数,以调整共享内存块所映射的号段范围。
上述方法基础上,在映射关系调整完毕后,还可进一步判断内存块中是否保存了不属于当前号段的话单,若有则读取并保存到该话单所述号段当前映射的内存块。
上述方法基础上,还包括:获取最大进程载荷与最小进程载荷的比值,若该比值大于预置的第一门限值,则触发调整共享内存块与号段的映射关系。并且可周期性的获取所述的比值。并且,可进一步,在获取最小进程载荷后,若判断其大于预置的第二门限值,则系统启动更多服务组件,并触发调整共享内存块与号段的映射关系;和/或获取最大进程载荷,若小于预置的第三门限值,则系统关闭部分组件,并触发调整共享内存块与号段的映射关系。
2)中进程读取共享内存块的话单,系统保存该话单的当前状态。进而当组件出现异常时,该话单可依然保存在共享内存中,待组件重起后,可找到未处理完的话单继续处理。
以上技术方案可以看出,本发明的多进程消息处理方法中利用共享内存实现数据交换,由于共享内存是最快的进程间通信(IPC)机制,因而保证本发明中对消息的处理具有较高的速度;并且,由于本发明利用共享内存存储待处理消息,并在进程读取消息后对该消息的当前状态进行保存,因而,采用本发明的方法后,若存在进程出现异常的状况,则不会导致内存块中的数据丢失。进一步,在利用了共享内存的基础上,本发明采用了负载均衡机制,动态的根据共享内存块当前的载荷状况将待处理消息保存到空闲的内存块,以均衡各内存块的负载,避免造成部分进程繁忙而另一部分进程处于等待状态的情况,进而总体上提高了消息处理的速度。
本发明还提供了一种多进程话单的处理方法,用于计费系统中对话单的并行处理。该方法中利用共享内存实现数据交换,由于共享内存是最快的进程间通信(IPC)机制,因而保证本发明中的话单处理的高效性;并且,由于本发明利用共享内存存储话单,并保存被进程读取的话单的当前状态,因而,采用本发明的方法后,若存在进程出现异常的状况,则不会导致内存块中的数据丢失。
进一步,本发明中采用了多种灵活有效的负载均衡策略,进程载荷定义、负载均衡度定义,基于系数组的负载策略定义,直观反映了负载情况,计算快捷简便,对计费业务的运行性能影响很小,能满足实时业务的要求。
进而,本发明中负载策略的一组系数决定将话单一一映射到分配的共享内存块中,同一主叫帐户的话单只会落入同一内存块,某一时刻只被该内存块所对应的进程处理。因此,本发明在提供负载均衡的同时,保证了话单处理的时序性。
附图说明
图1为本发明多进程消息处理方法流程图;
图2为本发明多进程消息处理方法中负载均衡策略实施例流程图;
图3为常见话单计费处理示意图。
具体实施方式
本发明提供了一种多进程消息处理方法,该方法的核心在于:1)为每个进程分配一块共享内存;2)进程从所分配的共享内存块中读取消息进行处理;3)基于内存块当前占用状态,将待处理消息根据预置的负载均衡规则存储到确定的共享内存块中。
参照图1,具体说明该方法的较佳实施例。
步骤11:为每个进程分配一块共享内存,并用一个唯一名字加以标识。
系统约定每个进程分配一个唯一标识(如1,2,3...n);根据该标示设置队列名称,如tmp/BILL_0,/tmp/BILL_1,.../tmp/BILL_xxx;利用ftok函数(用于将文件名转换为一个键值)得到一个唯一的key值,根据该key值,结合系统提供的参数(如内存尺寸,读写许可等)用shmget(IPC机制下建立共享内存的函数)建立共享内存;各组件根据队列名称获取队列唯一key,shmat(IPC机制下访问共享内存的函数)把该内存加载到进程的地址空间,以使得进程可以像访问普通内存一样进行队列访问。
步骤12:将每个进程的共享内存划分队列,进程读取队列中的消息进行处理。
将每个进程的共享内存划分队列,并在共享内存中建立队列的属性。在内存空间中划分出队列头用于描述队列属性,内容可包括:队列静态容量、队列内当前消息数、剩余的队列条目数、起始消息位置、访问控制锁等;出去队列头,将剩余的内存空间作为数据区,用于存储数据。所述访问控制锁用于当进程访问确定队列时,限制其他进程对该队列的访问。访问控制锁通过semaphore实现,为本领域公知技术。
当队列中插入一条待处理消息时,将该消息保存到所述数据区,并将队列内当前消息数进行一个单位值的累加;当进程对队列中的一条消息处理完毕,则将队列内当前消息数减去一个单位值;当进程处理一条消息时,锁定该消息,即对该消息当前状态进行保存,不改变队列内当前消息数值。
步骤13:根据预置的负载均衡策略,将待处理消息保存到空闲的队列。
本实施例提供的负载均衡策略的思想为:分析比较各队列的容量、消息数目、剩余队列条目数,计算进程的载荷,并根据载荷计算负载均衡度;进而将待处理消息插入到最空闲的队列中。参照图2,说明本实施例中的负载均衡策略。
各队列的进程载荷的计算,进程载荷为进程队列的消息数与队列容量的比值。即:进程载荷=进程队列的消息数/队列容量。进程载荷值域[0,1],0表示进程完全空闲,队列中没有消息待处理,1表示进程处理能力达到极限,队列已被待处理消息占满。
负载均衡度的计算,负载均衡度为所述进程载荷中最大进程载荷与最小进程载荷的比值,即负载均衡度=最大进程载荷/最小进程载荷。负载均衡度的值域为[1,+∞),负载均衡度为1时表示各队列负载达到理想平衡状态,负载均衡度越大表示各队列间的负载均衡度越差,即部分进程处于繁忙状况而另一部分的进程处于空闲状态。
本实施例的负载均衡策略定义为:步骤21:周期性获取计算进程载荷,步骤26:计算所述负载均衡度,当所述负载均衡度大于预置的第一门限值时,则进行步骤27:将待处理消息发送到进程载荷最小的队列中,否则,可根据业务需求按照原有的规则将待处理消息分配到确定队列中保存,如采用随机分配的方式或将特定业务类型的待处理消息发送到与该类型业务建立映射关系的队列中,交由特定进程进行处理。所述第一门限值可根据系统性能进行人为设定,通常可将第一门限值设置为2。
所述负载均衡度用于判断各队列间的负载是否均衡,体现了队列最大进程载荷与最小进程载荷之间的差距,然而负载均衡度并不能体现出所有队列是否接近全满或空闲状态。因而,在上述方法基础上,还可以在步骤21与26之间进行步骤22:判断所述队列的最小进程载荷是否大于预置的第二门限;以及步骤24:队列的最大进程载荷是否小于预置的第三门限。所述第二门限用于判断队列是否接近被占满状态,当最小进程载荷超过所述第二门限值,则需要进行步骤23:系统启动更多的服务组件,进而启动组件后触发进行步骤27的负载均衡处理;相应的,步骤24中所述的第三门限用于判断队列是否接近空闲状态,当最大进程载荷小于第三门限时,表明组件处理能力过剩,进而进行步骤25:系统可关闭部分服务组件,并且,关闭组件后触发进行步骤27的负载均衡处理。
上述介绍仅对照图2说明了一种负载策略,该负载策略中存在的某些步骤不存在执行顺序的约束,如步骤22与步骤24的判断,因而,本领域技术人员可根据需要设置符合业务需求的执行顺序。
除此之外,本发明也可采用其他的方式判断队列是否接近占满或空闲状态,例如:计算各队列的平均载荷,将所述平均载荷与预置的门限进行比较,以反映整体队列的进程载荷状况,当平均载荷大于上限时,表明所有队列整体上接近全满的状况,相应的所有进程处于繁忙状态,应启动更多的服务组件;若平均载荷小于下限,则表明所有队列整体上接近空闲状态,相应的进程空闲,应当关闭部分服务组件。综上所述,本领域技术人员可设置不同的机制判断队列的当前状况,本发明并不做具体的限制。
上述较佳实施例中,提供了一种负载均衡机制,本领域技术人员可根据业务的具体需求进行不同的设置,例如,所述负载均衡规则可将待处理消息发送到剩余容量最大的队列。然而,与上文实施例中所提供的均衡机制相比,虽然该方法可起到负载均衡的作用,由于没有考虑到各队列大小不同的情况,因而不作为本发明的优选均衡策略,但本发明并不对具体负载均衡策略的选用进行限制。
本发明还提供了一种多进程话单处理的方法,用于计费系统中对话单的并行处理。
通常,每条话单的计费处理需要经过预处理、批价、入库等处理环节,每个处理环节通常由多个进程来并行完成。如图3所示话单计费处理实例,包括:话单采集,由一个话单采集进程负责从交换机获得需要处理的话单,然后把话单分发到两个不同的预处理进程中,所述话单采集的速度很快较快;预处理,两个预处理进程独立地进行计算(如话单合法性检测、重单检测等),然后独立发往后继的批价系统;与话单采集相比,预处理的速度相对较慢;批价处理,四个批价进程独立地进行批价处理,并将批价后的结果发给“入库”进程纳入话单库,所述批价处理的运行速度交所述预处理更慢一些。实际系统中,除话单采集、预处理、批价、入库之外,根据业务的需求还可能包括其他的处理环节;并且,各处理环节可能包含更多的处理进程,各处理进程的处理速度可能随处理内容出现变化。
由上述话单计费处理的过程可以看出,话单从一个处理进程到下一个处理进程,应保证:在后继处理环节进程中得到较均衡的话单输入量,避免出现部分进程繁忙而另一部分进程进入等待状态;如果处理进程异常终止,重起进程后不会丢失处理中的话单;同一个主叫号码的话单,应该是按时间顺序进行处理的,即同一主叫号码的两条话单负载均衡后的计费处理依然能保持原来的时间顺序,例如:话单1和话单2是按照时间先后到达,负载均衡把话单1分发给批价进程1,话单2分发给批价进程2,如果批价进程2比批价进程1快,就可能先对话单2进行批价,从而得到错误的结果。
根据上述话单计费处理的特点,本发明的多进程话单处理方法的核心在于:1)为每个进程建立一块共享内存;2)进程读取共享内存块中存储的话单进行处理;3)基于内存块当前占用状况,根据预置的负载均衡规则分配话单保存到共享内存块,且同一帐户的话单存储到同一块共享内存。
根据以上核心,以下分三个部分具体说明本发明的较佳实施方式。
1)为每个进程分配一块共享内存,并用一个唯一名字加以标识。
系统约定每个进程分配一个唯一标识(如1,2,3...n);根据该标示设置队列名称,如/tmp/BILL_0,/tmp/BILL_1,.../tmp/BILL_xxx;利用ftok函数(用于将文件名转换为一个键值)得到一个唯一的key值,根据该key值,结合系统提供的参数(如内存尺寸,读写许可等)用shmget(IPC机制下建立共享内存的函数)建立共享内存;各组件根据队列名称获取队列唯一key,shmat(IPC机制下访问共享内存的函数)把该内存加载到进程的地址空间,以使得进程可以像访问普通内存一样进行队列访问。
2)将每个进程的共享内存划分队列,进程读取队列中的话单进行处理。
将每个进程的共享内存划分队列,并在共享内存中建立队列的属性。在内存空间中划分出队列头用于描述队列属性,内容可包括:队列静态容量、队列内当前话单数、剩余的队列条目数、起始话单位置、访问控制锁等;出去队列头,将剩余的内存空间作为数据区,用于存储数据。所述访问控制锁用于当进程访问确定队列时,限制其他进程对该队列的访问。访问控制锁通过semaphore实现,为本领域公知技术。
当队列中插入一条话单时,将该话单保存到所述数据区,并将队列内当前话单数进行一个单位值的累加;当进程对队列中的一条话单处理完毕,则将队列内当前话单数减去一个单位值;当进程处理一条话单时,锁定该话单,即对该话单当前状态进行保存,不改变队列内当前话单数值。
3)负载均衡方法,建立队列与号段映射关系,根据负载均衡策略分配话单到空闲的队列。
建立队列与帐户号段的映射关系,根据该对应关系保存确定号段的话单存到与之映射的队列;进而本发明中通过调整队列所映射的帐户号段的范围达到均衡负载的目的。具体的,建立负载策略,本实施例中负载策略由一组系数和一个号段构成,对于n个进程的负载(n≥2),所述策略系数可描述为[0,f1,f2,...,fn-1,1],0<f1<f2<fn-1<1;所述号段描述为[Min,Max],如[0,99999999]。
根据策略系数和号段可以确定一个号码的所在区间范围,该区间范围对应到一个进程。典型号段为[Min,Min+f1*Δ,Min+f2*Δ,...,Min+fn-1*Δ,Max],Δ=(Max-Min)。设所述策略系数为[0,0.25,0.5,0.75,1],根据上述方法,可知该策略系数确定了范围大小相同的4个号段,各号段分别对应于一个进程;同时,由于为每个进程分配了一块共享内存对应一个队列,因而,根据话单的主叫号码所属的号段可确定该话单应发往的队列,进而由与该队列对应的进程处理。
分析比较各队列的容量、话单数目、剩余队列条目数,计算进程的载荷,并根据载荷计算负载均衡度。具体的:各队列的进程载荷的计算,进程载荷为进程队列的话单数与队列容量的比值,即进程载荷=进程队列的话单数/队列容量。进程载荷值域[0,1],0表示进程完全空闲,队列中没有话单待处理,1表示进程处理能力达到极限,队列已被待处理话单占满;负载均衡度的计算,负载均衡度为所述进程载荷中最大进程载荷与最小进程载荷的比值,即负载均衡度=最大进程载荷/最小进程载荷。负载均衡度的值域为[1,+∞),负载均衡度为1时表示各队列负载达到理想平衡状态,负载均衡度越大表示各队列间的负载均衡度越差,即部分进程处于繁忙状况而另一部分的进程处于空闲状态。
把待处理的话单插入到空闲的队列中。查找到进程组(如批价进程组、入库进程组等)的负载均衡策略,根据话单的主叫号码计算出所在的号段区间,根据号段范围,把话单发送到对应的队列中。具体的,在话单计费处理过程中,根据下一步处理的类型,得到话单可发往的目标队列,如批价、入库等;进而根据负载策略保存话单到队列。
本发明中负载均衡策略的调整可归于负载策略系数的调整。监控组件定时地(周期由参数指定)检查负载均衡度以及最大进程载荷,若负载衡度超过参数设定的门限值(如2),则触发对策略系数进行调整。调整步骤如下:
锁定进程组的队列,限制其他进程对该队列的访问;设n个队列,计算各队列的载荷[g1,g2...,gn],以及平均载荷量
g;
进而,根据以下表达式对策略系数进行调整:
其中,Wi为与号段相关的权系数。可简单设置为i/n,也可自行设定。通过对策略系数的调整,实现了对队列所对应号段范围的调整。按照[Min,Min+f1*Δ,Min+f2*Δ,...,Min+fn-1*Δ,Max]的原则,进程相对繁忙,即进程载荷相对较大的队列所对应的号段范围变小;进程相对空闲,即进程载荷相对较小的队列所对应的号段范围变大。意味着在进行话单分配时,有更多的话单被分配到空闲的队列,从而达到负载均衡的目的。
策略系数调整后的号段仍为[Min,Min+f1*Δ,Min+f2*Δ,...,Min+fn-1*Δ,Max],相应的,有益队列所对应的号段范围的调整,可能已保存在某队列中的话单的主叫号码属于其他队列所对应的号段范围,因而,负载均衡策略调整完毕,判断各队列中是否保存了不属于当前号段的话单,若有则读取并保存到该话单所述号段当前映射的队列,以保证同一主叫的话单文件将分配到同一进程处理,保证话单处理的时序性。由于本发明利用了共享内存,因而所有话单调整都在内存中进行,可以得到很快的处理速度。
4)异常状态的负载均衡方法。所述异常状态包括:队列接近全满状态、队列接近空闲状态、进程出现异常。上述实施例中负载均衡度用于判断各队列间的负载是否均衡,体现了队列最大进程载荷与最小进程载荷之间的差距,然而负载均衡度并不能体现出所有队列是否接近全满或空闲状态。因而,上述实施例的基础上,本发明还利用载荷进程用于对异常状态的判断,进而进行相应的处理。
队列全满的处理,当组件中队列的最小载荷超过了预置的上限门限值时,表明组件处理能力不足,需要系统启动更多的服务组件,并且触发进行上文所述的负载均衡处理。
队列空闲的处理,当组件中队列的最大载荷低于预置的下限门限值时,表明组件处理能力过剩,可以通知系统关闭部分封服务组件,并且关闭组件后,触发进行上文所述负载均衡处理。
进程异常处理,进程获取一条话单,将对该话单状态进行锁定,保存该话单的当前状态,进而当组件出现异常时,该话单依然保存在共享内存中;组件重起后,可找到未处理完的话单继续处理。
依据上面所述异常处理的原则,异常处理的实现流程可参见图2及相关说明,不再赘述。
上述为本发明话单计费处理方法的一完整实施例,在该实施例中,队列与号段之间建立了线性的映射关系,然而,本发明并不对所述映射关系进行限制,该映射关系同样可采用非线性函数。在上述实施例所建立的队列中,队列头中对队列属性的描述还可包括:队列容量;剩余队列空间;队列使用率等;或者,其他与进程相关联的信息,如处理状态、处理时间、处理速度等。本领域技术人员可根据业务的实际需求进行设定。
以上对本发明所提供的多进程消息处理方法以及多进程话单处理的方法进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (16)
1、一种多进程消息处理方法,其特征在于:
1)为每个进程分配一块共享内存;
2)进程读取共享内存块中存储的消息进行处理;
3)基于内存块当前占用状态,将待处理消息根据预置的负载均衡规则存储到确定的共享内存块中。
2、如权利要求1所述的多进程消息处理方法,其特征在于:
3)中所述负载均衡规则具体为:计算内存块已用容量与内存块静态容量的比值作为进程载荷,并将待处理消息发送到当前进程载荷最小的内存块。
3、如权利要求2所述的多进程消息处理方法,其特征在于:
3)中还包括:获取最大进程载荷与最小进程载荷的比值,若该比值大于预置的门限值,则根据负载均衡规则保存待处理消息。
4、如权利要求1或2所述的多进程消息处理方法,其特征在于:
3)中还包括:周期性获得共享内存块的进程载荷,判断最小进程载荷是否大于预置的上限门限值,若大于则启动更多组件,并触发根据负载均衡规则保存待处理消息。
5、如权利要求1所述的多进程消息处理方法,其特征在于:
3)中所述负载均衡规则为将待处理消息发送到当前剩余容量最大的内存块。
6、如权利要求1所述的多进程消息处理方法,其特征在于:
进程处理确定内存块中消息时,采用访问控制锁的方式限制其他进程对该内存块的访问。
7、一种多进程话单处理的方法,用于计费系统中对话单的并行处理,其特征在于:
1)为每个进程建立一块共享内存;
2)进程读取共享内存块中存储的话单进行处理;
3)基于内存块当前占用状况,根据预置的负载均衡规则分配话单保存到共享内存块,且同一帐户的话单存储到同一块共享内存。
8、如权利要求7所述的多进程话单处理的方法,其特征在于:
1)中还包括建立共享内存块与帐户号段的映射关系,根据该对应关系保存确定号段的话单存到共享内存块;以及,
3)中所述根据预置的负载均衡规则分配话单的操作具体为:调整共享内存块所映射的帐户号段范围。
9、如权利要求8所述的多进程话单处理的方法,其特征在于:
建立内存块与号段的线性映射关系或非线性映射关系。
10、如权利要求8所述的多进程话单处理的方法,其特征在于:
3)具体为:计算各内存块的进程载荷[g1,g2…,gn],所述进程载荷为共享内存块当前占用容量与共享内存块静态容量的比值;计算共享内存块的平均载荷量
其中n为内存块数;以及,所述负载均衡具体为通过
更新各共享内存块与号段的映射系数,以调整共享内存块所映射的号段范围。
11、如权利要求8至10其中之一所述的多进程话单处理的方法,其特征在于,还包括:
映射关系调整完毕,判断内存块中是否保存了不属于当前号段的话单,若有则读取并保存到该话单所述号段当前映射的内存块。
12、如权利要求8至10其中之一所述的多进程话单处理的方法,其特征在于:
获取最大进程载荷与最小进程载荷的比值,若该比值大于预置的第一门限值,则触发调整共享内存块与号段的映射关系。
13、如权利要求12所述的多进程话单处理的方法,其特征在于:周期性的获取所述最大进程载荷与最小进程载荷的比值。
14、如权利要求8至10所述的多进程话单处理的方法,其特征在于:
获取最小进程载荷,若大于预置的第二门限值,则系统启动更多服务组件,并触发调整共享内存块与号段的映射关系。
15、如权利要求14所述的多进程话单处理的方法,其特征在于:
获取最大进程载荷,若小于预置的第三门限值,则系统关闭部分组件,并触发调整共享内存块与号段的映射关系。
16、如权利要求8至10所述的多进程话单处理的方法,其特征在于:
2)中进程读取共享内存块的话单,系统保存该话单的当前状态。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200510125736A CN100596159C (zh) | 2005-12-01 | 2005-12-01 | 多进程消息处理方法以及多进程话单处理的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200510125736A CN100596159C (zh) | 2005-12-01 | 2005-12-01 | 多进程消息处理方法以及多进程话单处理的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1787588A true CN1787588A (zh) | 2006-06-14 |
CN100596159C CN100596159C (zh) | 2010-03-24 |
Family
ID=36784875
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200510125736A Active CN100596159C (zh) | 2005-12-01 | 2005-12-01 | 多进程消息处理方法以及多进程话单处理的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100596159C (zh) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008092347A1 (fr) * | 2007-01-30 | 2008-08-07 | Huawei Technologies Co., Ltd. | Procédé, appareil et système de distribution automatique de liste de chargement |
WO2010060317A1 (zh) * | 2008-11-28 | 2010-06-03 | 中兴通讯股份有限公司 | 一种话单的生成方法及装置 |
CN101206588B (zh) * | 2006-12-15 | 2010-06-16 | 国际商业机器公司 | 用于在多个进程之间分配计算操作的方法和装置 |
WO2010145385A1 (zh) * | 2009-10-30 | 2010-12-23 | 中兴通讯股份有限公司 | 话单异常的处理方法和用于话单处理的系统 |
CN101145150B (zh) * | 2006-09-15 | 2011-11-02 | 中国银联股份有限公司 | 一种批量文件处理方法及系统 |
CN102541663A (zh) * | 2011-12-28 | 2012-07-04 | 创新科软件技术(深圳)有限公司 | 一种多进程使用共享内存进行通信的方法 |
CN102754395A (zh) * | 2009-12-04 | 2012-10-24 | 纳派泰克股份公司 | 由中央控制器控制的接收和存储数据分组的设备和方法 |
CN103034733A (zh) * | 2012-12-25 | 2013-04-10 | 北京讯鸟软件有限公司 | 一种用于呼叫中心的数据监控统计方法 |
CN101763289B (zh) * | 2009-09-25 | 2013-11-20 | 中国人民解放军国防科学技术大学 | 一种基于共享内存的消息传递方法 |
CN103533081A (zh) * | 2013-10-25 | 2014-01-22 | 从兴技术有限公司 | 一种基于云计算的计费系统及其实现方法 |
CN105450784A (zh) * | 2016-01-20 | 2016-03-30 | 北京京东尚科信息技术有限公司 | 向mq中的消息分配消费节点的装置及方法 |
CN105827670A (zh) * | 2015-01-05 | 2016-08-03 | 中国移动通信集团四川有限公司 | 一种数据处理方法和装置 |
CN105828309A (zh) * | 2015-01-05 | 2016-08-03 | 中国移动通信集团广西有限公司 | 一种话单处理方法、设备及系统 |
CN105978930A (zh) * | 2016-04-15 | 2016-09-28 | 深圳市永兴元科技有限公司 | 网络数据交换方法及装置 |
CN106021000A (zh) * | 2016-06-02 | 2016-10-12 | 北京百度网讯科技有限公司 | 用于机器人操作系统的共享内存管理方法和装置 |
CN107704325A (zh) * | 2016-08-08 | 2018-02-16 | 北京百度网讯科技有限公司 | 用于进程间传输消息的方法和装置 |
CN112035231A (zh) * | 2020-09-01 | 2020-12-04 | 中国银行股份有限公司 | 一种数据处理系统、方法及服务器群 |
CN112631768A (zh) * | 2020-11-23 | 2021-04-09 | 北京思特奇信息技术股份有限公司 | 一种基于异步机制的资源共享方法及系统 |
-
2005
- 2005-12-01 CN CN200510125736A patent/CN100596159C/zh active Active
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101145150B (zh) * | 2006-09-15 | 2011-11-02 | 中国银联股份有限公司 | 一种批量文件处理方法及系统 |
CN101206588B (zh) * | 2006-12-15 | 2010-06-16 | 国际商业机器公司 | 用于在多个进程之间分配计算操作的方法和装置 |
CN101005549B (zh) * | 2007-01-30 | 2012-04-25 | 华为技术有限公司 | 一种实现话单自动分发的方法、装置以及系统 |
WO2008092347A1 (fr) * | 2007-01-30 | 2008-08-07 | Huawei Technologies Co., Ltd. | Procédé, appareil et système de distribution automatique de liste de chargement |
WO2010060317A1 (zh) * | 2008-11-28 | 2010-06-03 | 中兴通讯股份有限公司 | 一种话单的生成方法及装置 |
US8462924B2 (en) | 2008-11-28 | 2013-06-11 | Zte Corporation | Method and device for generating phone bill |
CN101763289B (zh) * | 2009-09-25 | 2013-11-20 | 中国人民解放军国防科学技术大学 | 一种基于共享内存的消息传递方法 |
WO2010145385A1 (zh) * | 2009-10-30 | 2010-12-23 | 中兴通讯股份有限公司 | 话单异常的处理方法和用于话单处理的系统 |
CN102754395A (zh) * | 2009-12-04 | 2012-10-24 | 纳派泰克股份公司 | 由中央控制器控制的接收和存储数据分组的设备和方法 |
CN102754395B (zh) * | 2009-12-04 | 2015-03-04 | 纳派泰克股份公司 | 由中央控制器控制的接收和存储数据分组的设备和方法 |
CN102541663A (zh) * | 2011-12-28 | 2012-07-04 | 创新科软件技术(深圳)有限公司 | 一种多进程使用共享内存进行通信的方法 |
CN103034733A (zh) * | 2012-12-25 | 2013-04-10 | 北京讯鸟软件有限公司 | 一种用于呼叫中心的数据监控统计方法 |
CN103533081B (zh) * | 2013-10-25 | 2017-12-29 | 从兴技术有限公司 | 一种基于云计算的计费系统及其实现方法 |
CN103533081A (zh) * | 2013-10-25 | 2014-01-22 | 从兴技术有限公司 | 一种基于云计算的计费系统及其实现方法 |
CN105828309B (zh) * | 2015-01-05 | 2019-07-02 | 中国移动通信集团广西有限公司 | 一种话单处理方法、设备及系统 |
CN105828309A (zh) * | 2015-01-05 | 2016-08-03 | 中国移动通信集团广西有限公司 | 一种话单处理方法、设备及系统 |
CN105827670A (zh) * | 2015-01-05 | 2016-08-03 | 中国移动通信集团四川有限公司 | 一种数据处理方法和装置 |
CN105450784B (zh) * | 2016-01-20 | 2019-06-04 | 北京京东尚科信息技术有限公司 | 向mq中的消息分配消费节点的装置及方法 |
CN105450784A (zh) * | 2016-01-20 | 2016-03-30 | 北京京东尚科信息技术有限公司 | 向mq中的消息分配消费节点的装置及方法 |
CN105978930A (zh) * | 2016-04-15 | 2016-09-28 | 深圳市永兴元科技有限公司 | 网络数据交换方法及装置 |
CN106021000A (zh) * | 2016-06-02 | 2016-10-12 | 北京百度网讯科技有限公司 | 用于机器人操作系统的共享内存管理方法和装置 |
US9967222B2 (en) | 2016-06-02 | 2018-05-08 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Method and device for managing shared memory in robot operating system |
CN106021000B (zh) * | 2016-06-02 | 2018-06-01 | 北京百度网讯科技有限公司 | 用于机器人操作系统的共享内存管理方法和装置 |
CN107704325A (zh) * | 2016-08-08 | 2018-02-16 | 北京百度网讯科技有限公司 | 用于进程间传输消息的方法和装置 |
CN107704325B (zh) * | 2016-08-08 | 2021-08-27 | 北京百度网讯科技有限公司 | 用于进程间传输消息的方法和装置 |
CN112035231A (zh) * | 2020-09-01 | 2020-12-04 | 中国银行股份有限公司 | 一种数据处理系统、方法及服务器群 |
CN112631768A (zh) * | 2020-11-23 | 2021-04-09 | 北京思特奇信息技术股份有限公司 | 一种基于异步机制的资源共享方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN100596159C (zh) | 2010-03-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1787588A (zh) | 多进程消息处理方法以及多进程话单处理的方法 | |
KR100817676B1 (ko) | 동적 클래스-기반 패킷 스케쥴링 방법 및 장치 | |
CN1310135C (zh) | 具有基于活动线程号的寄存器分配的多线程微处理器 | |
CN1198210C (zh) | 微调度方法和包含操作系统内核的计算装置 | |
CN1508682A (zh) | 任务调度的方法、系统和设备 | |
Li et al. | Amoeba: Qos-awareness and reduced resource usage of microservices with serverless computing | |
CN111782355B (zh) | 一种基于混合负载的云计算任务调度方法及系统 | |
CN103297499A (zh) | 一种基于云平台的调度方法及系统 | |
CN1866217A (zh) | 确定源服务器在目标服务器中的最佳分布的系统和方法 | |
CN102916905A (zh) | 一种基于hash算法的万兆网卡多路分流方法及其系统 | |
CN100542175C (zh) | 一种多处理单元负载均衡方法和多处理单元系统 | |
CN103927225A (zh) | 一种多核心架构的互联网信息处理优化方法 | |
CN103327072A (zh) | 一种集群负载均衡的方法及其系统 | |
CN115543577B (zh) | 基于协变量的Kubernetes资源调度优化方法、存储介质及设备 | |
CN109861850A (zh) | 一种基于sla的无状态云工作流负载均衡调度的方法 | |
CN102402422B (zh) | 处理器组件及该组件内存共享的方法 | |
CN108829512A (zh) | 一种云中心硬件加速计算力的分配方法、系统和云中心 | |
Li et al. | A network-aware scheduler in data-parallel clusters for high performance | |
CN101340633A (zh) | 一种增值服务消息过负荷控制装置及方法 | |
CN101341471B (zh) | 动态高速缓存管理的设备和方法 | |
CN117271137A (zh) | 一种多线程的数据分片并行方法 | |
US7460544B2 (en) | Flexible mesh structure for hierarchical scheduling | |
Huang et al. | AutoVNF: An Automatic Resource Sharing Schema for VNF Requests. | |
CN204425400U (zh) | 应用服务器系统 | |
CN103827836A (zh) | 存储数据的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C56 | Change in the name or address of the patentee | ||
CP03 | Change of name, title or address |
Address after: 100012, building 2, North American International Business Center, 108 Beiyuan Road, Beijing, Chaoyang District Patentee after: Datang Software Technologies Co., Ltd. Address before: 100083 No. 40, Haidian District, Beijing, Xueyuan Road Patentee before: Datang Software Technologies Co., Ltd. |
|
DD01 | Delivery of document by public notice |
Addressee: Gao Tingting Document name: payment instructions |
|
DD01 | Delivery of document by public notice |