基于消息通信中间件的数据共享系统

基于消息通信中间件的数据共享系统

0消息中间件通信模式现状随着网络技术的快速发展，公司的计算环境已经从传统的集中集中转变为分布。企业应用系统的信息交互也不再局限于企业内部,为了消除信息孤岛、实现互联互通,提出了跨企业跨系统的信息交互需求。与此同时系统间需要交互的信息空前多样化,信息源、信息内容和信息格式种类繁多,可能是数据库中的表、也可能是文件系统中的文件,甚至实时数据流。各种应用系统对信息通信服务的需求也不尽相同,实时数据流可能需要可靠、即时的通讯服务;而文件和数据库中的数据则可能更需要安全、批量的服务。因此在分布式计算环境下,企业应用系统间为了实现信息交互、消除信息孤岛、实现互联互通,要求系统提供可靠、安全、异步的数据传输服务。在分布式网络环境中构建基于消息通信中间件的数据传输系统,通过消息中间件在不同的计算机之间异步传递数据消息,能有效的满足数据传输的可靠性、安全性和异步性等企业级需求,因而被广泛使用。消息中间件通过消息队列为分布式应用提供了一种可靠的信息交换的机制;采用核心的异步机制保证并发的效率;采用多种通信机制使得不同需要得到更好的解决;采用优先级机制,区别不同的消息的优先级,有效提高网络资源的利用效率;采用断点续传、加密传输机制有效的提高了消息传输的安全性、可靠性。因此在分布式计算环境下构建以消息中间件为基础的数据传输系统,可以很好的满足大多数分布式应用对数据传输的可靠性、安全性和异步性的需求。然而随着企业经营规模的扩大,数据传输系统提出了参与方多、交互数据量大等新的需求,现有的消息中间件由于其通信模型的制约难以很好的满足这些新的需求。现有的消息中间件的通信模型主要分为点对点模式(PTP)和发布/订阅模式(Pub/Sub)两种,它们在不同的应用环境和系统模型中各有优缺点。在PTP通信模式中(如图1所示),通信方式建立在消息队列的基础上,每个客户端对应一个消息队列,发送客户端(生产者)发送消息到消息队列中,接收端(消费者)从消息队列读取消息。其中消息在队列以FIFO或优先级方式存储。PTP的通信模式的最大优点是实现简单,而其缺点是数据提供者和订阅者的耦合度太高、扩展性较差,使得系统通信灵活性受到较大限制,每当接收方发生变化时,发送方的应用程序都必须作相应变更,难以支持多方参与者的交互。在Pub/Sub通信模式中(如图2所示),发布者通过发布代理把消息主题发布到消息代理服务器,由消息代理服务器向订阅代理发布所订阅消息;订阅者通过订阅代理向消息代理服务器“订阅”感兴趣的消息主题。Pub/Sub通信模式的主要优点是通过消息代理服务器实现了发送方和接收方之间的松耦合,但其明显的缺点是中央的消息代理服务器负责处理消息的转发和管理,在大数据量交互时,其性能瓶颈和单点失效的局限性越发明显,严重影响了系统的可用性。本文根据大规模数据传输系统的应用特点,结合Pub/Sub和PTP通讯模型各自的优点,提出一种基于点对点的发布/订阅消息中间件通信模型(PBPS),使消息中间件能有效的用于大规模的数据传输系统的构建。本文的内容组织结构如下:首先提出PBPS通信模型,介绍系统的设计,并详细介绍其各个关键技术及运作流程然后介绍PBPS模型在中科院软件所研发的消息中间件ISMQ基础上的实现及应用情况,介绍相关工作,最后对本文的工作进行总结并展望下一步工作。1pbps系统模型PBPS(PTPbasedpub/sub)是一种基于点对点的发布/订阅消息中间件通信模型,它充分结合了Pub/Sub模型和PTP模型的优点,适用于构建大规模的数据传输系统。其基本思想是基于Pub/Sub通信模型来实现系统命令消息的交互,从而达到仅利用小数据量的命令消息,完成多方参与的交互,并保持系统良好的可扩展性;基于PTP通信模式实现真正的数据消息的传输,能够充分利用PTP模式在传输方面的高效性,从而实现大数据量的可靠传输。PBPS系统由4个部分组成:发布代理(PubAgent)、代理服务器(BrokerServer)、订阅代理(SubAgent)和消息队列(MQ),如图3所示。PBPS系统模型涉及的术语:命令消息:用于PBPS系统内部交互的满足一定格式的指令消息,包括:发布消息、订阅消息、退订消息和答复消息。数据消息:系统要传输的数据,通过点对点的模式传输。主题:能反映数据消息特征的信息。PubAgent:主要用于处理来自外部应用的信息发布请求和数据消息的发送,同时维护一个待发布队列。当收到外部应用发布主题的请求,将发布请求中含有的发布主题通过命令消息发布到BrokerServer。相对于外部应用这是一个异步的过程,外部应用将请求提交给PubAgent后,可以通过PubAgent查看提交的请求的执行情况;同时因为所有消息是通过MQ通信的,所以可以保证消息传输的可靠性。当在指定时间未收到来自BrokerServer的答复,PubAgent自动将该请求放入待发布队列中,并在指定周期后再次发布,直到收到针对该请求的答复并完成相应数据消息的传输后,通知外部应用发布成功并将请求删除。BrokerServer:主要用于处理来自PubAgent的发布消息和来自SubAgent的订阅消息及退订消息。BrokerServer自身维护订阅者主题树,对于发布消息,BrokerServer从订阅者主题树中查找订阅该主题的订阅者信息,生成答复信息回复发布者;对于订阅消息,BrokerServer根据订阅主题和订阅者信息,将更新订阅者主题树;对于退订消息,BrokerServer根据退订消息中含有的订阅者的信息和主题,将该订阅者从相应的订阅者主题树中删除。SubAgent:主要用于处理来自外部应用的订阅、退订请求和数据消息的接收,同时维护一个订阅队列。当收到外部应用订阅主题的请求,先将该请求放入订阅队列中,然后含有订阅主题和订阅者信息的订阅消息发送到BrokerServer;当收到外部应用的退订请求时,将含有订阅主题和订阅者信息的退订消息发送到BrokerServer,同时将该请求从订阅队列中删除。MQ:实现数据消息和命令消息的底层消息通信,保证消息可靠、高效、安全的传输。2系统的关键技术本节首先介绍了PBPS系统的核心订阅者主题树的设计;然后对系统中的另一个关键技术:命令消息进行了介绍;最后对PBPS系统的运作流程进行了介绍。2.1在线购票者主题树的生成PBPS的设计是基于内容的Pub/Sub模型和PTP相结合,在大数据量交互的应用背景下,单次交互的大数据量是本系统的主要关注点,因此BrokerServer查找订阅者的算法,基于订阅主题树匹配。图4中Topics为根节点,主题的组织结构为层次型;根据订阅消息内含有的订阅主题属性和订阅者信息,动态生成订阅者主题树。(1)生成订阅者主题树:BrokerServer根据订阅消息内含有的订阅主题属性和订阅者信息,动态生成订阅者主题树。SubAgent通过如下规定的语义规则组织主题属性:Attr(A):主题属性;连接符:“/”,关键字;主题属性规范表示:(A/)+。其中属性的组织为层次型(如图4所示),前一属性为后面属性的所属,一个主题属性层次越多,该主题描述的越具体;同时订阅父节点主题者,意味着订阅了以该结点为根的主题树。如图4所示,其中:Sub1、Sub2订阅的主题属性为:a/a/,Sub3订阅的主题属性为:a/b/,Sub4订阅的主题属性为:a/,Sub5订阅的主题属性为:b/。(2)查找:BrokerServer根据发布消息的主题,查找满足条件的订阅者信息节点。当发布主题属性为:a/a/时,满足条件的订阅者信息节点为:Sub1、Sub2和Sub4。(3)插入:当插入订阅信息时,先根据主题属性查找该主题属性节点是否已经建立。若没有则根据属性的层次性,依次建立属性节点,最后建立一个订阅者节点将其设为相应主题属性节点的子结点;若主题属性节点已经建立则看其是否已经有该订阅者信息结点,若有则更新该订阅者信息节点,无则新建子结点。(4)删除:当处理退订消息时,先根据主题属性查找主题属性节点,查看是否含有订阅者信息的子节点,有则删掉该字结点,无则退出。然后查看该主题属性结点是否还有其它订阅者子节点,有则退出;无则将该主题属性结点删掉,并依次遍历上层节点进行删除。2.2消息实现机制在PBPS系统内所有的事件服务使用消息实现,引入了4种命令消息用于代理和服务器间的交互,分别是:发布消息、订阅消息、答复消息和退订消息。(1)提取数据消息PubAgent向BrokerServer发送的发布消息的格式,command属性值为:“pub”,messageid属性值:消息id(自动生成),source属性值:发布者地址,topic属性值:主题,size属性值:描述用于发送的数据消息的大小。(2)消息的生成SubAgent向BrokerServer发送的订阅消息的格式,command属性值为:“sub”,messageid属性值:消息id(自动生成),source属性值:订阅者地址,topic属性值:主题。(3)提取信息的格式BrokerServer向PubAgent发送的答复消息的格式,command属性值为:“reply”,messageid属性值:消息id(自动生成),replymsgid属性值:应答消息id(发布消息id),dest属性值:订阅者的地址。(4)退订消息的属性SubAgent向BrokerServer发送的退订消息的格式,command属性值为:“unsub”,messageid属性值:消息id(自动生成),source属性值:订阅者地址,topic属性值:主题。2.3brker东南角发布请求,背景接收者身份,导致用户体验无下降在PBPS系统模型中,外部应用通过代理基于发布、订阅模式与BrokerServer通过命令消息交互,获取订阅者信息,直到通过点对点模式完成数据消息的发送和接收。图5系统序列图,描述了3个主要阶段处理的流程。主题订阅阶段:(3)SubAgent向BrokerServer发送含有订阅主题和订阅者信息的订阅命令消息,同时启动接收队列;(4)BrokerServer处理来自SubAgent的订阅请求,根据订阅主题和订阅者信息,更新订阅者主题树。主题发布阶段:(5)外部应用向PubAgent发送发布请求;(6)PubAgent向BrokerServer发送含有发布主题的发布命令消息;(7)BrokerServer根据发布主题查询订阅者主题树,查找订阅该主题的订阅者;(8)若当前没有订阅者,或者网络原因造成超时等待,则PubAgent将该发布请求插入持久化队列并且在指定周期后再次发布;(9)BrokerServer根据查找地结果,向PubAgent返回相应发布请求的答复消息;(10)PubAgent根据收到的答复消息,发送数据消息给相应的SubAgent;(11)PubAgent通知应用发布完成;(12)SubAgent从接收队列取出数据消息;(14)外部应用向SubAgent发出退订请求;(17)BrokerServer处理退订请求,查找更新订阅者主题树。3brker东南角事件获取及处理我们在中国科学院软件研究所研发的消息中间件ISMQ中提供了PBPS的实现,并提供了一个系统的应用案例。PBPS主要功能由5个包(如图6所示)实现:Broker、Message、TopicTree、MQ和Task。Broker完成了3种代理的操作方法,其由4个主要类构成:Broker、BrokerServer、PubAgent和SubAgent(如图7所示);Message用于完成命令消息的处理,其对外的功能方法由Message类提供;TopicTree用于完成订阅者主题树的维护,主要包括:树的生成、结点创建、更新、插入和删除操作,其对外的功能方法由ManageTopic类提供;MQ建立在ISMQapi的基础上,实现了对消息队列操作的基本方法,对外的功能方法由MQService提供;Task主要实现了数据消息操作的基本方法,包括:数据的发送、接收、查询和管理等。PBPS应用模板模式设计代理类的组织(如图7所示),Broker类实现了所有代理的基本功能,包括:消息的发送、接收和一个抽象消息处理方法;Broker有3个子类,分别为:BrokerServer、PubAgent、SubAgent。其中BrokerServer,完成发布消息、订阅消息、退订消息的处理,并生成相应的答复消息,而目录树的维护依赖ManageTopic类完成。PubAgent,主要完成外部应用发布请求处理,生成发布命令消息,同时依赖Task类完成数据消息的发送;外部应用在使用PBPS进行主题发布时,可用通过调用包中接口:pubRequest(Stringpara1,Stringpara2),来将订阅请求发送给PubAgent,pubRequest接口参数1为主题信息,参数2为数据信息位置(系统当前只处理文件)。SubAgent,主要完成外部应用订阅请求和退订请求处理,生成订阅、退订命令消息,同时依赖Task类完成数据消息的接收。外部应用在使用PBPS进行主题订阅和退订时,可通过调用包中接口:subRequest(Stringpara1,Stringpara2),来将订阅请求发送给SubAgent,subRequest接口参数1为主题信息,参数2为数据信息接收目录(系统当前只处理文件);通过调用包中接口:unSubRequest(Stringpara),将退订请求发送给SubAgent,unSubRequest接口参数为主题信息。在PBPS系统中,一个PBPS系统由3类不同的代理组成,这3种代理可以集中于一个物理结点,也可以是分布于不同的结点上,结点之间通过ISMQ进行可靠的命令消息和数据消息的通信,PBPS在每个结点上提供了消息的处理操作:processMsg,不同类型的代理有着不同的实现,为了简洁性,图8显示了BrokerServer中processMsg方法的伪代码。在伪代码中使用了下面的变量:subs表示订阅者信息数组,msg表示收到的消息,msg.type表示消息的类型,msg.topic表示主题,msg.source表示消息的发送者。当有新的命令消息到达时,消息处理操作被调用,针对BrokerServer代理消息处理该方法处理3类消息类型:订阅、退订、发布。当收到订阅命令消息时processMsg(图8中第3、4行)调用insertNode操作,将在msg中含有的订阅者信息和主题信息插入订阅者主题树;若消息为退订命令,processMsg(图8中第6、7行)根据主题和订阅者,查找主题树,若找到则删除该订阅结点;若消息为发布命令,processMsg(图8中第9到12行)查找主题树中订阅该主题的订阅者信息,若有订阅者则生成答复消息,回复发布者。PBPS系统在普通话语音教学系统中得到了应用。由多个教学中心组成的发布者集合,通过定期将不同的语音数据信息通过PBPS系统发布到代理服务器;由不同教学单位组成的订阅者集合通过PBPS订阅感兴趣的语音数据。这样对于教学中心和教学单位只需将数据的发布请求和订阅请求发送到PBPS系统,既可以自动完成语音数据的发送和接收。实际应用表明PBPS系统可以有效的支持大规模数据集成应用。4基于主题的发布/约束条件以及具有不同表达能力的特征在基于渠道的系统中,订阅是通过指定渠道来实现的,订阅者接收所有发布到渠道中的事件,事件的接收和事件的内容无关。CORBA事件服务规范就是一个典型的基于渠道的系统。在这类系统中,订阅者不能指定它对渠道中的一部分事件感兴趣,表达能力很弱,但是实现简单。基于主题的系统将所有的事件按照主题划分成组,每个事件只属于其中一个主题。订阅者在订阅信息时,指明他对哪个主题感兴趣;将来一旦出现该主题下的事件,系统都会自动将其发送给订阅者。早期的Pub/Sub系统一般都是基于主题的系统,例如TIB/Rendezvous的较早版本、IBMMQSeries的较早版本、Scribe和Bayeux等。这种系统不去理解事件的内部结构,而将其看成是一个封闭的黑盒子,订阅者不能更细粒度地表达他对某主题下的一部分事件感兴趣。这类系统优点是实现简单有效。有些系统既具有基于主题系统的特点,又具有基于内容的Map系统的特点,可以被看作是混合型的发布/订阅系统,典型系统包括JMS规范和CORBA通知服务规范每个事件的内容包括一个Map形式的事件头和一个系统不能理解的事件体,同时每个事件必须属于某个主题。客户在定义订阅条件时,必须先指定主题,再在其基础上根据