数据分发服务中的全局数据空间(GDS)的研究与设计*
2010-04-26李军
李 军
(武汉市74223信箱 武汉 430074)
1 引言
随着分布式计算和网络的飞速发展,分布式应用系统在金融、电信、军事领域中得到广泛应用。为了实现分布式异构网络环境下不同应用的互联、互通和互操作,一般采用中间件技术来屏蔽系统平台的差异。但是目前中间件产品并不能很好地解决通信的实时性、伸缩性和灵活性问题,如当前较为流行的CORBA技术,由于它是以对象和服务为中心,采用了C/S通信模型,通信机制较为复杂,数据收发需要建立连接,不能完全满足系统对实时性能的需要。早先的分布式共享内存是一种以数据为中心交换的经典模型,然而这种模型很难在网络中高效地执行,很难为用户提供可衡量性和灵活性,特别是很难满足系统的实时性需求。OMG意识到需要一个基于以数据为中心的发布/订阅(DCPS)通信模型[1]的数据分发服务来满足分布式实时应用的需要,提出并最终采纳了“OMG-DDS”规范。为了实现网络中各节点通信的实时性、异步独立性和松耦合性,该规范建立了“全局数据空间(Global Data Space)[2]”的概念并指定了发布者和订阅者以及如何访问该空间。在DCPS通信模型中,全局数据空间代替了中心服务器,用来管理整个分布式系统中的主题发布,主题订阅,节点信息的维护以及节点的关联。因此,GDS的设计成为了DCPS通信模型实现的关键。本论文根据DDS[3,5]中以数据为中心的发布/订阅模型,提出一种全局数据空间的总体框架及各组织结构设计,最后给出了一些管理策略。
2 全局数据空间的概念
如图1所示,DDS中以数据为中心的发布/订阅(DCPS)模型[3~4]建立了一个“全局数据空间”的概念,通过全局数据空间来管理数据对象(每个数据对象由“主题(T opic)”和“类型(Type)”共同标识,“主题”提供了一个标志符,在全局数据空间中唯一地标识某些数据项。“类型”提供了中间件如何操纵这些数据所需的结构信息)的发布及主题的订阅。需要说明的是全局数据空间并不存放实际数据,它只管理订阅主题信息。
想要向数据空间提供主题信息的应用程序声明为“发布者”,同样,想从数据空间中获取主题信息的应用程序成为“订阅者”。发布者(Publisher)负责发布数据,它可能发布不同类型的数据。订阅者(Subscriber)负责对发布的数据进行接收并使数据能被接收应用所使用(根据Subscriber的QoS)。主题在逻辑上将发布者和订阅者关联起来。发布者必须能够让订阅者非常清楚地查阅它。主题能够完成该目的:它将一个名称(在领域domain内唯一)、数据类型(data-type)和数据本身的QoS关联在一起,使空间上、时间上关系松散甚至毫无关联的发布者和订阅者之间产生了互通。
每当发布者将新主题信息发送到当前节点的全局数据空间,中间件就会把主题信息广播给所有感兴趣的订阅者。当订阅者能从自己的数据空间中找到需要的主题信息时,就向发布主题节点发送订阅请求信息,发布者根据订阅信息中的订阅者地址,发布该主题下的数据给指定的订阅者,两者即完成数据的分发。
图1 DCPS数据模型及全局数据空间
3 全局数据空间设计分析
在DDS中间件设计中采用基于侦听的通信机制,由侦听者来进行信息的分发并触发相关实体的动作,即各节点之间通过侦听者来传递发布和订阅的主题信息。所有与主题相关的信息都保存在GDS中,侦听者收到来自其他节点的信息后通过与GDS进行交互来进行主题和QOS的匹配,从而进行任务的分发,通知相关发布者/订阅者调用与主题相关联的数据写入者/数据读入者进行数据传送。
由于DCPS通信模型采用的是基于主题发布订阅机制[6~7],各节点之间的交互通过主题来关联,而且新节点的接入和节点的退出信息也保存在全局数据空间中,因此全局数据空间上的主题信息的同步更新则成为了设计的关键。GDS一方面与本地发布者、订阅者、数据读入者、数据写入者进行交互,协助这些实体完成主体的发布或订阅。另一方面,它为侦听者进行信息处理和分发提供参考。
由于传统C/S通信模式需要一个中心服务器来处理并提供数据,而且如果多个节点同时向服务器请求,服务器需要花很长时间来处理消息,增加了服务器的负载,不适合数据流大的实时系统,所以全局数据空间并不在一个集中式服务器中,而是采用分布式的设计,分布到每个分布式节点上。于是,在设计GDS的时候需要考虑以下几个方面:
◦当需要发布主题时,DDS中间件需要查询GDS是否已有其他节点发布过该主题;若没有,发布方采取广播的方式发送主题到所有接入的节点,各节点需要同步更新GDS主题信息表,所以各节点保持一样的主题信息;
◦当订阅者订阅主题时,DDS中间件通过查询GDS主题信息表得到该主题的发布者,确定向哪里订阅;
◦当确定主题发送者之后,即向发布者发送订阅信息;订阅信息存储在发布者的订阅登记表中;
◦当某个主题上有数据产生时,需要在GDS订阅登记表中查询找到所有该主题的订阅者,来确定数据的接收地;
◦当侦听者收到订阅主题或退订消息时,通过查找GDS确定是否需要保存该信息。
4 全局数据空间的设计
基于以上的需求分析,提出了一种基于DCPS模型的发布订阅中间件框架并设计了全局数据空间的的组织结构。如图2所示。
图2 基于DCPS模型的发布订阅中间框架及数据空间结构
通过以上对DDS规范的研究和对实际应用的需求分析,GDS主要需要保存所有发布者的主题信息、本节点的订阅信息、需要保存的数据、所有订阅失败的信息。所以设计的GDS由发布主题表、订阅登记表、发布数据缓存区和订阅失败队列四部分构成。
1)发布主题表
定义发布主题表PT_Table(ID,P_IP,T_QOS)保存所有发布主题的状态信息,其中ID为发布的主题标识;P_IP为发布者IP地址;T_QOS表示发布者所提供主题的服务质量,T_QOS主要包括:(1)Durability数据持久性,其中 VOLATILE表示非持久性数据,不需要保存,T RANSIENT表示需要暂时保存,PERSISTENT表示持久性数据,需要永久保存;(2)Reliability为传输方式的可靠性,Best-effort表示尽力方式传输,Reliable表示采用可靠方式传输;(3)Priority表示订阅时间的优先级,值越小其优先级越高。
所有节点上的发布主题表保持一致并实时更新。对于一个有多个分布节点组成的具有特定功能的系统来说,所有节点应用具备一张一致的发布主题表,描述了该系统的基本主题状况。
2)订阅登记表
定义订阅登记表SR_T able(ID,S_IP,T_QOS)反映当前订阅该节点的订阅信息,其中ID表示订阅主题;S_IP为订阅者地址;T_QOS表示订阅方要求主题的服务质量,与PR_Table的 T_QOS参数和意义相同。
不同节点的订阅登记表各不相同。节点在订阅主题时,通过发布主题来确定提供该订阅主题的节点;在发布数据时,通过订阅登记表来确定数据该发往何处。
3)发布数据缓冲区
Data_pool保存由本节点发布且需要保存的发送数据,即主题的Durability_QOS属性为TRANSIERNT或PERSISENT的数据。其结构如图3所示,数组每一项表示同一主题已发送的数据,num表示现有数据条数;ID为主题标识;ptr指向所有主题数据的链表,链表的每一项保存了一条数据信息,通过指针指向数据的内存区;Livaspan表示该主题数据需要保存的时间,若 Livaspan为0xffff则永久保存,否则在规定的时刻后删除该主题下的首条消息;
GDS根据每种主题下数据的Livaspan来决定何时更新缓冲区。
图3 发布数据缓冲区结构示意图
4)订阅失败队列
Sub_fail_que保存本节点向其他节点失败订阅的历史记录,数组每一项表示在同一主机上订阅失败的记录。中间件在收到发布方开机信息或间隔一定时间再进行重新订阅。
5 GDS管理策略
GDS是本模型实现主题订阅和数据分发的关键。如何更新各节点上的发布主题表使其保持动态一致,以及维护和更新订阅登记表是GDS管理的核心环节,所以GDS最后需要一些管理策略来进行更新维护。本文提出了如下策略:
◦每个节点开机时向所有节点广播开机信息,收到开机信息后,各个节点检查自己的订阅失败队列,将在开机节点上订阅失败的订阅消息重新发给开机节点,订阅成功后从队列中删除。
◦订阅者变更订阅记录时通知相应发布者更新其订阅登记表。发布者变更发布主题信息时通知所有节点更新发布主题表,以保持发布主题表的全局一致性。
◦订阅方根据发布主题表向发布者发送订阅信息,若发布主题表中没有相关发布记录,则进行广播订阅,若订阅成功就在发布者的订阅登记表中登记订阅记录。发布节点上的GDS在发布数据缓冲区查找是否存在该订阅者所订阅主题的数据,然后激活相应数据写入者将数据发送给订阅方的相应数据读入者。若订阅失败就将该订阅记录记入本节点的订阅失败队列。
◦节点离开或失效的情况:当节点离开时,向其他节点发送离线消息,其他节点删除订阅登记表中离线节点的订阅记录,并终止与离线节点间的所有发布/订阅关系,离开节点同时清空节点上的订阅登记表;各个节点通过定期向其他节点发送心跳信息来表示该节点还“活着”。一段时间内收不到某节点的心跳信息表明该节点已“死亡”,其他节点要删除订阅登记表中“死亡”节点的订阅记录。
6 结语
传统的中间件包括CORBA、EJB、DCOM 都采用C/S通信模式,它需要一个中心服务器来处理数据信息,增加了服务器的负载,产生了不可预测的时延,不适用于数据量大的实时系统。而DDS规范采用的以数据为中心的发布/订阅(DCPS)模型,根据主题进行点到点消息发送,实现了按需发送。而全局数据空间概念的提出,实现了发布订阅模型的异步性和松耦合性,同时本文提出一种全局数据空间分布式设计方案,大大提高了系统的可靠性和可扩展性。因此,DDS中间件在高性能、高可靠性、高实时的数据传输中应用前景广阔。
[1]OMG Data Distribution Service for Real-time Systems Version 1.2,2007
[2]Giddings V Tutorial on the OMG Data Distribution Service[R].Objective Interface Systems.Inc,2005
[3]TAO Developer's Guide Excerpt Object Computing,Inc,2007
[4]Data Distribution Service(DDS)and the RTPS protocol Gerardo Pardo Castellote gerardo@rti.com,2004
[5]Addressing the Challenges of Tactical Information Management in Net-CentricSystemswith DDS Douglas C.Schmidt Angelo Corsaro Hans van't Hag PrismTech Corporation,2005
[6]Middleware Solutions for automation application-case RTPS Helsinki University of Technology Seppo Sierla,2003
[7]Designing and debugging real-time distributed systems By Geoff Revill,RTI,2008