分布式应急调度系统的设计与实现

第31卷第8期2010年8月微 计 算 机 应 用M I CROCOMPUTER APPLI CATI ONSV o l 31N o 8A ug 2010分布式应急调度系统的设计与实现刘 捷 冼 进(华南理工大学 计算机科学与工程学院 广州 510006)摘要:该系统作为分布式应急调度数字化系统的软件部分,基于V C++、Socke t编程、UDP组播等技术,将集群系统与调度中心座席连接,实现调度台服务端与座席的相关功能。

该系统采用了分布式的结构,各座席之间相互独立,协同工作,有效地保证了系统的稳定性,确保系统在恶劣的环境下依然能正常运行。

该系统实现了一个基于工作量的协商算法,以解决座席间的潜在应答冲突,并自动调节各座席的负载。

关键词:分布式 应急调度 基于工作量的协商算法Desi gn and I m ple m entation of a D istri buted Em ergency D ispatch Syste mLI U Jie,X I A N Ji n(School O f Co m pute r Sc i ence&Eng i neer i ng,South China U niversity of T echno l ogy,Guangzhou,510006,Ch i na)Ab stract:T his syste m is the soft w are components o f a distr i buted em ergency dispatch dig ital syste m,based on V C++,Socket pro gra mm i ng,UD P mu lti cast,connecti ng the c l uste r hardware system and d i spatch center agents to ach i eve dispatche r server and agent s related features.T h i s syste m uses a distri buted structure,so a ll the agents are i ndependent o f each o t her and w ork together e ffective l y.T he struct ure ensures the stab ility o f this syste m so t hat t h i s syste m can w ork correctl y even i n a poor env iron m ent.Th is syste m i m ple m en ts a nego ti ation a l go rith m based on w ork l oad to reso lve the potenti a l confli ct a m ong agents and to auto m aticall y adjust t he wo rk l oad.K ey words:distributed,e m ergency dispatch,negotiati on a l gor it hm based on wo rk l oad1 引言分布式集群应急调度数字化系统是按照公安业务实际需要,切实围绕应急、防暴、防恐和重大保卫工作需要进行设计,以恶劣自然条件、重大事件可能的破坏为使用客观条件,单基站可通、一个基站剩下一个信道还可通、多基站可通、有线联网可通,有线链路中断后自身系统具备的无链路技术迅速自动启动继续保障通信。

系统的无线网专用链路技术,确保在任何恶劣情况下,基站之间的自愈环联网,不受任何客观链路条件制约,为整个系统无线通信提供整体网络通畅。

本系统是分布式集群应急调度数字化系统的软件部分。

基于VC++、Socket编程、UDP组播等技术,将集群系统与调度中心坐席连接,实现调度台服务端与座席的相关功能,是集通信、指挥和调度于一体,是高度智能化的分布式应急调度系统。

本系统采用了分布式的结构,由指定网段内登陆的座席自动组成,数量不限。

各座席之间相互独立,协同工作,任意座席故障不会对系统产生任何影响。

本系统的核心在于实现一个基于工作量的协商算法,以解决座席间的应答冲突,并自动调节各座席的负载。

为了实现更短的响应时间、更高的效率并且减轻网络负载,我们采用UDP组播的方式发送所有会话协商信息。

本文于2010-06-08收到,2010-07-16收到修改稿。

微 计 算 机 应 用 2010年2 系统结构分布式集群应急调度数字化系统分为硬件部分和软件部分。

图1 系统结构图硬件部分为单片机系统,由物理上分散的基站和若干特制的移动台组成。

每个基站包括4条或8条可分配的信道,负责呼叫的应答、信道的分配、通话的维持等功能。

各基站采用无线通信的方式与特制的移动台连接,工作在350兆赫兹的频率上,也可以通过已有的PSTN 网络接入普通的固定电话。

移动台和固话统称为终端。

每次通话时,终端可以呼叫某个终端(即单呼,需要指定终端号)或者呼叫若干个终端(即组呼,需要指定组号,被呼叫的终端需要在同一个组中),也可以选择呼叫座席。

软件部分为纯数字化,采用VC++进行编写。

各个座席完全相同,在系统中处于同等地位,具体座席的存在与否、具体座席数量对系统无影响。

每个座席运行在单独的计算机上,与终端进行通信,实现接警、呼出(单呼或组呼)、监听,加入和退出组、转接等功能。

服务端为系统可选部件,负责集中存储通话记录,保存通话语音内容,提供语音内容的检索和下载,以及实现服务器硬盘空间管理。

座席之间采用UDP 组播技术发送协商信息,以此减轻网络的负担。

3 座席功能描述座席分为普通座席和管理座席,后者在前者的基础上加入了额外的管理功能。

所有的座席在部署时,都预先分配一个座席号,并加入到特定的组中。

普通座席包括以下功能:(1)接警:移动台发送呼叫请求,座席响应请求的过程称为接警。

移动台在发送请求时无需指定具体座席号。

每当有外部呼叫进入时,呼叫请求信号将由硬件以组播的形式发送给所有的座席。

座席在接收到呼叫请求信号时,在界面上显示图形化提示。

用户点击 接警!按钮后,经过所有座席的内部协商,决定由哪个座席发送响应信号给基站(具体协商算法见第5小节),由基站分配信道之后形成实际的通话通路。

通话时的语音信号全部记录到本地,并在结束通话时上传至服务器保存。

668期刘 捷等:分布式应急调度系统的设计与实现(2)呼出:座席发送呼叫请求,移动台响应请求的过程。

座席在发送请求时需要指定移动台号或移动台组号。

具体流程类似于普通电话通信。

(3)监听:座席上显示移动台之间正在进行的通话,并可以选择加入到通话进行监听。

(4)加入和退出组:座席可以选择加入或退出某个组。

组呼建立时,座席可以选择加入本次组呼,并可在任意时刻退出或再次加入。

(5)音频转接:由座席将呼叫请求通过有线PSTN转接到热线。

(6)语音记录查询:座席可以连接服务端查询语音历史记录,并且可以下载到本地播放。

普通座席可以查询该座席相关的语音记录,管理座席可以查询所有的语音记录。

管理座席还包括以下功能:(7)统计:包括所有座席的在线状态、在线时长、通话时长等等。

(8)插话:加入到座席与终端正在进行的通话。

4 服务端模块划分服务端分为四个模块:记录存储模块、磁盘管理模块、配置管理模块和记录查询模块。

记录存储模块作为W i n do w s系统服务常驻内存,负责监听固定端口,与座席通信,接收通话语音内容文件,并存储在本地硬盘中,同时在数据库中存储通话记录。

磁盘管理模块作为W i n do w s系统计划任务定时触发。

启动后,先扫描存储文件夹,如果未超出最大存储空间,则结束运行;如果已超出存储空间,则根据清盘策略进行清盘操作。

清盘策略包括:按日清盘(清除最久的一天的全部音频记录),按月清盘(清除最久的一月的全部音频记录),等等。

配置管理模块为系统管理员提供管理界面。

使用前需登陆为系统管理员。

系统管理员可在本程序中修改系统配置,启动和停止系统运行,设置系统为W i n do w s系统服务,删除指定语音记录等等。

记录查询模块为用户提供了一个远程查询语音记录的W EB界面。

服务端所有的配置信息均保存在单独的Config.x m l文件中,内容包括监听端口,是否设置为W in do w s系统服务,音频记录文件存储路径,最大存储空间(单位MB),清盘间隔时间,清盘策略,清盘时是否考虑优先级,数据库信息(地址,端口,用户名,密码等等)。

5 协商算法5 1 系统模型本系统由多个地位相同的座席组成,座席的数目无法预知,系统由存活的座席自组织形成网络并提供服务。

本系统的特点:∀对于业务的实时性要求很高,因此协商过程不能太长,协商的步骤要尽量少,不能采用复杂的算法;#协商结果只要保证选出的节点唯一,不需要绝对的公平;∃没有中心节点保存系统全局信息,因此需要由各座席在协商过程中交换实时运行信息和同步呼叫请求队列。

另外,算法还需要满足两个要求:(1)短时间内同一移动台的重复呼叫,有可能是对同一事件的多次协调,因此会需要由同一个座席进行响应。

算法应能保证其对该呼叫请求的优先响应,即只要该座席空闲,则协商的最终结果必然是由该座席响应请求。

但考虑到业务对实时性的需求,这样的优先响应又是有实效性的,在该座席忙的情况下,需要有别的座席做出响应。

(2)在实际应用中,只将座席响应请求后的处理请求过程视作实际工作,希望各座席的实际工作量大体相等,因此协商算法需要参考座席的历史响应,从而影响到当前的竞争中,让工作量较小的座席先获得响应权,实现负载的平衡。

5.2 算法原理在本系统中,座席间协商之后响应呼叫请求的过程类似于分布式系统中各节点申请分布式锁互斥访67微 计 算 机 应 用2010年问关键资源的过程。

经典的分布式互斥算法基于时间戳[1]并采用广播的形式发送消息,节点发送包含时间戳请求消息,其他节点在收到消息后,如果参与竞争,则发送FA I L信息;如果不参与竞争,则发送OK信息。

每个节点只有在收到所有回复消息之后才竞争成功。

可知,每次竞争需要2(N-1)条消息交换:N-1条用于节点P发送请求,N-1条用于其它节点回复应答。

在k个节点同时提出请求的时候,需要交换的消息数将为2k(N-1)。

我们对算法进行了修改:(1)将时间戳改为工作量。

每个节点维护一个本地计数C;i所有协商信息中均包含发送节点的当前计数,节点在竞争时根据本地计数与所有协商信息比较,计数最小的节点竞争成功;每次竞争结束后,节点更新本地计数。