发布订阅系统（精选七篇）
发布订阅系统 篇1
发布/订阅系统是一种广泛使用的用来提供事件服务的消息中间件范式,其中,数据被封装入消息中。消息的发送者( 发布者) 不是直接发送消息给特定的接收者( 订阅者) ,而是将消息发布到一个中间的消息代理服务器。发布的消息分为不同的类别,发布者不需要知道这些类别分别被什么样的订阅者订阅。订阅者对一个或多个类别表达兴趣,于是只接收感兴趣的消息,而不需要知道什么样的发布者发布了这些消息。这种发布者和订阅者的解耦具有更好的可扩展性[1,2,3],能够支持更为动态的网络拓扑。发布/订阅和消息队列,是面向消息的中间件———MOM系统[4]的两种实现范式。
随着云计算技术的快速发展,许多云系统中都加入了发布订阅服务。这样,我们只需要把消息发送到云中,而后,完全可以依靠云服务把消息匹配并分散给各个订阅者中。云系统中的数据规模是非常巨大的,对于一些大型的企业,每天都有数以亿计的消息传递,因此,如何提升发布订阅系统的消息投递性能是一个十分紧迫且意义重大的课题。
几种方法来改进消息的递送性能,如推/拉( PUSH/PULL) 消息模型的选择,提升订阅者消费消息的速率,优化服务端负载均衡的策略。然而传统的消息系统,如Kafka,Active MQ和Rabbit MQ[5,6,7,8],却很少能充分利用这些机制。
PUSH消息模式的实时性更好,它确保消息到达服务器端就会立即被发送到订阅者,当然代价就是增加了服务端负载的开销。影响订阅者消费消息速率的因素有很多,除了提高网络性能,提高机器的硬件配置,我们更关心的是多个订阅者的协同消费行为,由此,引入“消费者集群”的概念。即将单一的订阅者集合起来,组成一个集群,共同接收并处理同一个类别的消息。由于消息投递和消息处理的异步特性,集群消费模型可以很大程度上提升消息消费的速率。当然,服务端往往也是由分布式服务器组成,设计良好的负载均衡策略,可以使消息更加均衡的分布在各个服务器之间,使服务器资源得到更加合理的利用,从而在一定程度上间接地提升消息的投递性能。
关于提升消息传递的性能,目前国内外已经有一些研究,但更侧重于研究传输网络[9,10,11]的可靠性。也有一些关于消息实时性的研究,如基于优先级队列和最短路径树的模型算法,但它们不能同时保证消息传递的可靠性,并且也缺乏对系统终端( 发布者/消息代理服务器/订阅者) 的关注。
分析这些成熟的消息系统,我们得出结论,Hedwig支持PUSH消息模式,但是不支持集群消费的功能。虽然Kafka也有类似“消费者集群”的语义,但是它只能提供PULL消息模式。发布订阅系统中传统的服务器端的负载均衡策略是基于主题的或类似的概念,为了更加均匀的将消息分布在服务端,一个更细粒度的负载均衡策略是必要的。
本文中,我们在保证消息可靠投递的前提下,整合PUSH消息模式和消费者集群功能,同时我们提供了一个基于消息数量的更加细粒度的负载均衡策略。本文的后几部分组织如下: 第二部分描述了提升消息投递性能的具体设计与实现。第三部分给出了实验结果及分析。最后第四部分给出了全文的结论。
2 消息投递性能提升的设计
要提升发布订阅系统中消息投递的性能,需要同时考虑客户端和服务端的性能提升策略。在客户端我们引入了消费者集群模型,同时为了适应PUSH消息模型以及保证消息的可靠性,也为之设计了一系列的保障性措施。在服务端,提出了一种更加细粒度的基于消息数量的负载均衡策略。
2. 1 集群消费策略
2. 1. 1 消费者集群模型
大多数消息系统同时支持发布订阅语义和消息队列语义,比如最常见使用的Java Message Service( JMS) 。在发布订阅系统模型中,所有订阅了某一相关主题的订阅者都会收到服务器端发送的隶属于这个主题的消息。然而,在消息队列模型中,位于队列中的某一条消息只能推送给注册到这个队列的其中的一个接收者。这两种消息模型适用于不同的应用场景。我们把这两种模型整合起来,形成了消费者集群( 或者说集群订阅者) 的概念,如果消费者集群中订阅者实体的个数为一,那就和原本的单一订阅者没有本质区别。见图1。
2. 1. 2 设计与实现
从图1可以看出,一个消费者集群集合了若干个订阅者实体,然而,从服务端的角度来看,一个消费者集群和一个普通的订阅者并没有区别。消息都会广播给它们。当一个具体的消息被投递给一个消费者集群时,这条消息只能被集群中的某一个订阅者实体接收并处理。例如,服务端某个主题下有5条消息,一个拥有三个订阅者实体的集群订阅了这个主题,那么一种可能的情况是: 消息1和消息4被第一个订阅者实体接收,消息2和消息5被第二个订阅者实体接收,剩下的消息3被第三个订阅者实体接收。因为服务端的消息投递过程和订阅端的消息消费过程都是异步操作,所以系统的整体消息传送性能将得到很大的提升。实现这样一种消费者集群模型,还需要额外考虑三个因素: 流量控制,消息重传和服务端的消息确认。
( 1) 流量控制。在消息的异步传输模式中,客户端会缓存那些本地已经接收到的但还没有处理的消息,这时候,客户端还不会给服务器端发送成功处理的确认信号,我们称这种消息为未确认消息。如果客户端处理消息的速率低于其接收消息的速率,那么本地缓存将会持续的增长,最终可能导致内存溢出。因此,我们需要匹配服务端和客户端的消息收发速率。在我们设计的系统中,我们为每一个订阅者实体维护一个消息窗口,如果消费者集群中的某一个订阅者实体接收到的未确认消息数量达到它的消息窗口值大小,那么服务端后期就不会再继续向这个订阅者实体发送消息,除非一段时间后它成功消费了某些未确认消息。
例如,在一个消费者集群中某一个订阅者实体的消息窗口值是10,某一个时刻,恰好10条接收到的消息都没有被消费,这时,未确认消息已经达到窗口上限,此时这个订阅者处理消息的能力已经达到上限。因此服务端后续的消息就不会再发送给这个订阅者实体,而是会发送给消费者集群中其他的订阅者实体。当然,只要有一条消息被这个订阅者实体成功消费,那么它之后就又可以重新接受服务端发送过来的消息并根据情况消费这些消息。
在系统的实现中,我们创建了两个队列,Deliverable EP和Throttled EP。前者用来存放那些暂存的未确认消息小于其对应消息窗口值的订阅者实体,每次服务端投递新消息时,都会从这个队列里选出一个实体作为消息的接收者。后者用来存放那些未确认消息数量达到其对应消息窗口值的订阅者实体,当然一旦未确认消息在某一时刻被成功消费,那么对应的订阅者实体就会从Throttled EP队列中迁移到Deliverable EP中,反之亦然,见图2。
( 2) 消息重传。如果集群消费者中的一个订阅者实体接收到了一些消息,但是由于某种原因没有能够成功的处理这些消息,那么服务器端需要重传这些消息。消息重传通常有两种机制: 基于超时值的重传方案和基于连接状态的重传方案。对于基于超时值的重传方案,服务端会为订阅者设定一个超时值,一旦消息发送出去,在限定的这个超时时间间隔内没有收到订阅者传送过来的消息确认信号,那么服务端就会重新传送这条超时的消息。对于基于连接状态的重传方案,系统为每个订阅者和服务器都维护一个连接状态,订阅者定期的发送心跳包给服务器,用以表明订阅者的可用状态。一旦服务端接收不到心跳包,则认为订阅者断开连接,则需要把之前发给这个订阅者的所有未被消费的消息重新传送给这个消费者集群中其他的订阅者实体。基于超时值的消息重传方案会增加系统的负担,而采用基于连接状态的消息重传方案往往会比较简单,因为目前多数的发布订阅系统都已经集成了心跳机制,完全可以借此来实现我们需要的消息重传方案。
在我们的实现中,需要监听每一个订阅者实体和服务器端的连接状态。一旦有一个连接断开,应该把所有的发给这个订阅者实体但是还没有被消费的消息放到一个重传队列里,并且清空这个订阅者所占据的资源。最后我们从上述Throttled EP队列中选择合适的订阅者实体,并把这些消息重新发送过去,见图3。
( 3) 消息确认。当一条消息成功的被一个订阅者实体接收并消费,那么这个订阅者会给服务端发送一个成功消费的确认信号,以此来通知服务端回收这条消息所占据的空间。在传统的发布订阅系统中,同一个类的消息会传送给所有的订阅者,而某一个订阅者可以再连续接收并成功消费了若干条消息后发送给服务器一个批量消费的确认信号。但是在消费者集群的概念中,一条消息可能是由这个集群中的任何一个订阅者实体接收并消费的,因此一个订阅者实体只能对它自己消费过的消息做确认,因此,它也就不能对这个消息之前的若干条消息做批量确认了。
我们在服务端为所有的从订阅者实体接收到的消息的消费确认信号维护了一棵消息确认树,一旦若干连续的消息序号被加到这棵树上,便把服务端的消费指针指向这片消息序号的最大值,然后在服务器端集中做一次批量的消息确认操作,从而完成了服务端的消息确认工作。
2. 2 基于消息数量的负载均衡策略
在发布订阅系统中,消息是聚簇成类的,主题是类的一种具体表现形式,为了使下文的负载均衡策略更加直观便于理解,我们统一用主题来代表抽象的类。
当有新的主题发送到服务端时,系统会检测每一个消息代理服务器的负载情况,然后选择一个消息负载最轻的服务器来托管这个主题。传统的负载均衡机制是基于主题数或者相似的概念的,因此,系统会选择主题数最少的服务器去托管新的主题。以后所有这个主题的消息都会被发送到这个服务器上。但是以主题数作为唯一的负载信息做均衡决策是存在问题的。考虑下面的场景: 有两个托管服务器,b1和b2。b1托管了一个主题,这个主题有100条消息,b2托管了两个主题,每个主题分别有10条消息。如果它们向相同的订阅者投递消息的话,不考虑其他差异,很明显,b1的系统开销更大。这时如果发布者发布了一个新的主题,按默认的负载均衡策略,系统会选择主题数较少的b1来托管这个新主题,很明显,整个服务端系统的资源没有得到充分的利用。因此,我们设计了一个更加细粒度的负载均衡策略—基于消息数量的负载均衡策略。系统在做负载均衡动作时,会选择消息数量最少的服务器来托管新的主题。这样,消息会更加均衡的分布在各个服务器之间,服务端整体的性能也会得到提升。具体的描述均衡策略的过程,见图4。
( 1) 均衡触发。当发布者发布新的主题到服务端或者有订阅新主题的订阅请求发送到服务端时,服务端触发其负载均衡动作。
( 2) 负载检测。如上所述,系统应该选择消息数量最小的服务器来托管新的主题,因此我们需要在合适的时间收集服务端的负载信息。通常在服务端触发均衡动作后需要立即检测负载的信息,但是这样得到的瞬时值却不能提供一段时间内的平均的负载情况,一个更好的办法是周期性的检测负载值,并及时更新到持久化存储中。这样,在负载检测时,可以方便的从持久化存储中读取服务端的平均负载信息。
( 3) 选择消息代理服务器。当从持久化存储中读到各个服务器的负载信息后,我们根据消息数量判断各个服务器负载的大小,并依此选出最轻负载服务器。
( 4) 执行均衡动作。服务端执行均衡动作,也就是通知上一步中选出来的服务器去托管这个新的主题。随后,同一主题的消息会直接发送到这个消息代理服务器上。
3 实验和评估
为了评估提升消息投递性能的机制,在一个成熟的开源发布订阅系统Hedwig中实现了我们的设计。Hedwig本身就支持PUSH消息模型,因此具有很好的实时性,因此我们要做的: 在原生Hedwig中引入消费者集群模型,并配合PUSH消息模型提供可靠性保证; 优化服务器端的负载均衡策略。
我们在Planet Lab上做了大量的测试,将介绍测试的过程以及数据分析。
3. 1 实验环境搭建
在Planet Lab上搭建测试环境,为了测试消费者集群的性能,部署了五个节点,其中三个节点组成消费者集群,一个节点作为消息代理服务器,另外一个节点用作发布者。整体的拓扑结构见图5和图6。为了测试服务端负载均衡的性能。我们选择三个节点作为消息代理服务器,一个节点作为发布者,一个作为订阅者。拓扑结构见图7和图8。
3. 2 结论和评估
3. 2. 1 消费者集群性能测试
我们主要从两个方面来评估消息投递的性能: 消息投递速率和消息的可靠性。我们一次性的发布了500条消息到服务端,收集了4个时间段记录: 一条消息从发布开始一直到到达服务端的时延( pub - hub_in) ,服务端处理消息的时延( hub_in - hub_out) ,一条消息从服务端开始投递给订阅者开始一直到被订阅者接收的时延( hub_out - sub) ,以及消息从发布者发布到消息被订阅者接收这个整体的时延( pub - sub) 。图9和图10分别给出了在订阅者流量窗口值大小不同的情况下,原系统和引入消费者集群的系统的消息投递性能对比,可以发现,消息投递的速率得到了明显的改善提升。即当订阅者的流量窗口不受限制时,在原生的Hedwig系统中,处理500条消息大概要耗时3. 5s,但是经由我们改善的系统,处理相同数量的消息只需要约2. 5s。当订阅者的流量窗口值为50时,这种对比更加突出。在原生的Hedwig系统中,处理500条消息大概要耗时5s,但是经由我们改善的系统,处理相同数量的消息只需要约3s。
为了测试消息投递的可靠性,当集群消费者中的2号订阅者实体接收了50条消息但是并没有成功消费,这时断开它和服务端的连接。图11表明,所有的这50条消息都会投递给这个消费者集群中的另外两个订阅者实体,图11中波动较大的点表明这些对应的消息是重传的。
3. 2. 2 负载均衡策略性能测试
我们基于主题T1发布了100条消息,基于主题T2,T3,T4,T5,T6各发布10条消息。表1展现了原生的Hedwig系统的负载均衡处理过程。为了便于理解,我们把注意力集中在服务器端主题和消息的分布情况。可以看到,尽管B2服务器中的消息数量更多,但是主题数依然在三个服务器B1,B2,B3中均匀分布。表2则展现了一种基于消息数量的更加细粒度的负载均衡策略,系统会选择具有最少消息数量的服务器去托管新的主题。我们可以看到,T1主题下有更多的消息,这样,在接下来的五次负载均衡动作中,B1都不会被选择为新主题的托管服务器。托管服务器主要在消息负载量小的B2和B3之间选择。这样的策略明显是更加合理的,消息会更加均匀的分布在这三个服务器之间。表示六次均衡动作所选择的服务器分布情况,见图12和图13。
4 结束语
发布订阅系统作为一种消息中间件,广泛的应用在大规模,分布式,默认容错的应用程序中。它给应用提供了基于云的服务[12],在云计算中扮演着十分重要的角色。为了在发布订阅系统中高效地实现消息投递服务,引入了消费者集群的概念,并且为了保证消息投递的可靠性我们设计了流量控制,消息重传,消息确认方案。我们同时设计了一种基于消息数量的更加细粒度的负载均衡策略。最后在一个比较成熟的开源项目Hedwig中实现了设计和方案,Planet Lab上的测试数据也表明,完善后的系统在消息投递性能方面有着更好的表现。
摘要：研究如何提升发布订阅系统中消息投递的性能,我们发现消息的推/拉模型选择,订阅者的消费速率以及服务端的负载均衡策略是三个非常重要的影响因素。现在的消息中间件,无论是发布订阅系统还是消息队列模型,很少可以把上述三个影响因素结合起来。因此,我们在保证消息可靠性的基础上,把推送消息模型,消费者集群和一种更细粒度的负载均衡策略集成在一起,并在一个较成熟的发布订阅系统Hedwig中得以实现。Planet Lab上的测试结果反映了系统在消息投递性能上得到了有效的提升。
雷尼绍发布Primo系统 篇2
雷尼绍近日宣布推出Primo系统，它是制造技术的一项革新突破，为各类规模的制造商转向高附加值制造业提供了契机。机床测头是精密制造技术的基础。Primo系统采用“即付即用”模式，通过降低前期的投入成本、免费的自学培训和提供更换服务，在机床测头领域迈出了革命性的一步。Pr imo系统包含用于确定工件位置的PrimoRadio Part Setter（工件测头）、用于测量切削刀具长度与直径的 Primo Radio 3D Tool Setter（3D对刀仪）和Primo Interface（接口）。此外，它还包含三个重要元素：Primo Credit Token（充值币）、 Primo Total Protect（全方位无忧保障方案）和GoProbe培训组件。雷尼绍亚太区总裁Jean-Marc Meffre先生表示：“精密测量连同机床测头是达到竞争所需的高质量要求的关键。我们的研究显示，测头的购买成本、易用性及耐用性都是令客户对使用测头却步的原因。因此，我们推出了Pr imo系统，一项可解决客户顾虑的创新解决方案 —低投入成本、免费培训和更换服务。Primo系统使亚洲的制造商把握住了转向高附加值制造业的机遇。 ”（详细报道见本刊第14页）
发布订阅系统 篇3
为了对付专业窃电等违规犯法行为, 有效开展稽查行动, 有必要在实现信息化管理的同时, 在一些重点用户的用电线路上装载一个用电监测设备, 预防窃电情况的发生。该管理系统必须满足以下要求:
1) 稽查消息服务平台应符合发布/订阅模式下的应用架构, 能接收线路上的电量消息和发送巡检请求, 支持稽查人员对线路用电异常现象的消息订阅。
2) 应用软件的模块设计应该要满足稽查人员的基本查询要求, 管理界面友好, 操作简单, 能结合图表观察用户的用电量曲线, 并将一些查询结果打印成表。
3) 监测设备必须能适应国内最常见的两种线制:三相三线制和三相四线制, 以满足不同线路之间的要求。计量检测终端应采用标准通信协议传送数据, 抄表数据准确可靠, 传输抗干扰性好。
4) 线路用户的用电情况一旦异常情况, 要求检测终端能收集到事件时间、设备编号等相关信息, 要有一定的相应显示功能, 可读性强。
5) 系统通讯方式及时可靠, 平台与计量检测仪以国内流行的无线通信网进行远程数据传输, 提高数据通道的可靠性, 降低设备成本。
二、系统总体设计
(一) 用电稽查管理体系结构
稽查消息服务平台由网关接口、计费模块和电量消息数据库组成, 负责收发计量检测终端与稽查平台之间的巡检消息, 支持稽查人员对线路异常情况的消息订阅。用电稽查系统则负责维护电能用户的档案信息, 从其他电量分析、线损分析等子系统的数据库中调出每月的数据, 查询用电量数据和分析各线路的损耗情况, 从同行业当月用电量和电能用户近三年的当月用电量进行横纵式综合查询, 找出存在窃电可能的电能用户;并对稽查消息服务平台接收到的实时电量消息进行聚类分析, 区分用电异常现象。
(二) 用电稽查系统设计要点
1) 多功能查询。在用电稽查管理软件中, 各个模块设计主要以查询可疑用户名单为目的, 两个大的模块:综合查询和电量分析, 一共提供了以下几种查询功能:用户档案查询、同行业用户查询、用户用电量查询、可疑线路查询 (含单线路用户查询) 、可疑大用户/普通用户/居民用户查询 (含任意月份大用户/普通用户查询) 、大用户/普通用户量容比查询 (含最新输入月份和往月历史查询) 。2) 实时监测。因为计量检测仪装载在用电线路上, 所以该系统通常情况下也处于监听 (接收) 状态。但一旦监测到窃电事件时, 它就转入发讯状态, 将计量仪编号、事件时间等信息以报文形式, 通过无线通信网络发送短信到上位机或者稽查人员的手机, 然后又转入监听状态。为了确保串口通信的可靠性, 我们的软件设计考虑到了主MCU的容错功能, 只要主MCU或者检测终端接收到的报文不符预计情况, 则相应设备便会进行数据重发。3) 故障软化。由于计量检测仪长期处于配电设施中, 环境复杂, 干扰影响较大, 要达到长时间正常运行, 需克服大量存在的暂时性故障, 如机器出现程序走飞状态等, 所以在设计硬件及软件时我们使用了W77E58内置的watchdog技术, 以此实现故障软化技术, 帮助机器自动从死循环和走飞状态中拉出, 进入主程序。a.安全保密。为防止数据丢失, 软件设置有口令和用户身份识别的各级操作权限, 防止非授权人员误操作。原始数据存放在数据库中, 只能查询不能修改, 数据处理限定在应用数据库中。b.报表打印。为了能更好的显示数据, 在报表的设计方面用到了Fast Report2.4。该控件是个功能强大的报表控件, 综合了Quick Re prot、Re prot Buile d等报表控件的优点。能处理多达15种各类型报表, 能进行“四则运算”、统计等, 支持多国语言。支持斜线绘制, 文字的自动折行, 可与应用程序分离, 独立制作报表打印。c.操作简便。用电稽查系统软件使用基于面向客户的Delphi开发软件, 界面友好;支持模糊查询, 其中客户机可从专用的电费计算数据库中读取用户的本月用电情况, 并可以生成近3年用电曲线图。主界面附带的帮助文档图文结合, 引领操作人员轻松掌握本软件的各种功能。d.人机交互。稽查平台采用两种查询方式:一种是检测仪主动发信方式;另一种是软件稽查平台主动巡检方式。当稽查人员对部分线路上的计量检测仪召数据记录 (即主动巡检) 时, 稽查平台转入发讯态, 发出一个命令报文, 然后又转入监听状态。如果计量检测终端未能及时发回稽查平台相应的数据记录时, 操作人员等不到信息, 可自行决定是否再试。
三、稽查消息服务平台设计
在设计稽查消息服务平台时, 应用整合主要针对业务流程进行整合, 即当通信程序在接收到用户发来的信息请求时, 根据短信平台设置的内容结合用户请求查找相应的消息内容, 将用户的资料以及请求内容放在客户资料分析平台的数据库中, 以便及时分析客户情况。因此, 在设计稽查消息服务平台时要考虑到与业务流程、数据整合的协同工作, 还要考虑到我国电信运营商的网关协议, 系统设计需要考虑到以下要点:1) 短信平台支持移动、联通和电信三个运营商的网关, 对电信运营商提供的现有网关提供统一通信接口, 实现与应用层面的API调用, 短消息网关是处于短消息中心 (SMSC) 和业务提供商 (SP) 之间的设备, 它为这两个实体的数据交换提供安全、快捷的通道。2) 在通信模块中采用共享缓冲池技术, 能够以最快的速度从ISMG接收短信息放到缓冲池中, 而数据存取模块仅从共享缓冲池中提取数据, 从而实现通信处理模块和数据存取模块有效分离, 降低瓶颈效应, 大幅提高峰值时的数据处理能力。3) 考虑到不同的操作系统, 使应用程序几乎不加任何修改从一个系统移植到另一个系统, 最大限度地提高系统的可移植性和移动网关接口的通信程序。
四、结语
本文针对当前用电稽查管理忽视业务流程的集成、平台实时性和扩展性较差等问题, 本文采用消息发布/订阅模式解决过程数据集成问题的设计思想, 提出了基于发布/订阅模式的用电稽查管理应用架构。该架构主要思想是通过发布/订阅的一对多消息机制来支持各系统之间的异步通信, 为用电稽查管理各系统提供方便。
摘要：随着我国电力事业的不断发展, 各种用户的用电情况更加纷繁复杂, 而国内目前用电稽查的法规尚未深入人心, 窃电是长期以来困扰供电企业发展的一大难题, 是供电企业最现实、最直接的经营风险之一。根据“内清外查、重点在内”的用电稽查指导思想, 始终坚持“安全第一、预防为主”的工作方针, 对内堵漏增效、对外查违反窃。
关键词：用电安全,稽查,监测
参考文献
[1]詹先银.基于发布/订阅的消息中间件技术及其应用.西安:西安电子科技大学, 2005.
[2]A.Carzaniga, D.S.Rosenblum, A.L.Wolf.Achieving scalability and expressive-ness in an internet-scale event notification service.In:Proc AnnuACM Symp PrincDistrib Comput.Porland, 2000.
欢迎投稿欢迎订阅欢迎发布广告 篇4
HUSBANi S f代耆禽养殖业》杂志助您扬帆远航f投稿邮箱:nmgxmy2008@s i na.com查稿电话0471-6652261地址:内蒙古呼和浩特市乌兰察布东街70号内蒙古农牧业厅12楼·电话:0471-6652261邮编:010010国内统一刊号GN15-1150/S;国际标准刊号ISSN1005-5959o邮发代号:16^49。每期定价10元, 全年定价120元。每月5日出版通过全国各地邮局 (所) 发行, 也可直接汇款至本刊编辑部订阅。《现代农业》自治区农牧业领军期刊《现代农业》 (月刊) , 刊号:CN15—1098/Z邮发代号:16—38, 全年定价:120元。地址:呼和浩特市乌兰察布东街70号内蒙古农牧业厅办公楼电话:0471—6652260邮编:010010^一絶邮箱:x i anda i nongye@163.com欢迎投稿欢迎订阅欢迎发布广告
发布订阅系统 篇5
对于需要长期连续不断运行并且具有特殊任务的系统如航空航天、生命维持、金融、交通等,在系统需求或环境发生变化时,如果停止系统运行进行更新或维护,将会产生高额的费用和巨大的风险,同时对系统的安全性也会产生很大的影响。在这种情况下,由于静态体系结构缺乏表示动态更新的机制,难于对系统进行分析和描述,不能指导系统进行动态演化和更新,因此,软件运行时发生变化的动态软件体系结构(DSA)的研究应运而生[1]。目前,对DSA的研究主要集中在动态演化、模拟/描述动态演化的语言和支持动态演化的执行工具等方面[2]。
OSGi框架规范[3]提供了一套在Java平台上的模块化标准,该标准旨在改变基于Java应用系统的传统构建方式,采用模块化和面向服务的思想,减少系统各部件之间的耦合度并提高代码的重用性。在未来几年中,OSGi规范有可能成为Java的官方规范,具有良好的发展前景。因此,在OSGi平台上实施服务的动态演化是十分必要的。
OSGi平台上动态演化包括两个方面:服务的动态更新与模块的动态更新。服务的动态更新主要有两种方法,一种方法是利用OSGi规范中允许多个同名服务同时运行的机制实现服务动态更新[4],在更新期间让新旧服务同时运行,由于新服务具有更高的优先权,对服务的新请求会自然导向新服务,等待旧服务停止后,将旧服务的状态迁移至新服务上完成更新过程。由于在更新期间,新旧服务产生了新旧两份状态,不能保证在状态转换时将不同时间段产生的状态合并成功,破坏了服务状态一致性原则。另一种方法是利用代理机制实现服务动态更新[5],将实现和数据相分离,为保证服务状态的一致性建立了一套代理机制,如图1所示,在Proxy中保存Service中的服务状态,在Service中只保存操作服务状态的代码。由于在更新期间只存在一份服务状态,保证了服务更新前后状态的一致性。但是这种方法由于将实现和数据相分离,并且Service和Proxy耦合程度高,在增加或减少对外服务的方法时需要对Proxy进行修改,所以编程模型不佳。
针对上述两种方法存在的问题,本文提出基于发布/订阅模型的服务动态更新策略。该策略以静止状态理论为依据,保证服务更新前后的相互一致性和服务状态的一致性;使用OSGi规范中的Event Admin Service实现该策略,具有良好的编程模型,克服利用代理机制使编程模型不佳的缺点,并为后期使用AOP(面向方面编程)技术简化开发打下良好基础。本文在给出服务动态更新策略的基础上,提供一种将模块动态更新转换为服务动态更新的方法,达到模块动态更新目的,满足实际应用环境需要,实现OSGi平台上的动态演化。
1 基于发布/订阅模型的服务动态更新策略
1.1 Event Admin Service服务模型
OSGi框架提供了四个关键特性:生命周期管理、模块化、捆绑包版本控制和减少Java EE应用程序的重复开发,其静态下的Bundle概念体现模块化思想,动态下的Service概念体现面向服务编程思想。在OSGi规范中,定义了基于主题的发布/订阅模型Event Admin Service。事件发布者使用Event Admin Service发送基于主题的事件,任何对某一主题感兴趣的事件订阅者都会收到该事件并作出反应[6],如图2所示。基于这一模型,本文提出实现服务间的通信以及服务动态更新的发布/订阅策略。
1.2 服务更新模型描述
在OSGi框架下,一个服务是注册到OSGi框架中的一个普通Java对象[7],一个模块就是一个Bundle,Bundle内部有许多个Java类,即一个模块含有多个服务,由此通过对服务的动态更新就可以实现对模块的动态更新,服务与模块的动态更新是OSGi平台上两个不同更新粒度的动态演化。在演化过程中根据保证系统一致性的不同方式,比较非形式化的三种动态配置方法——恢复性方法、避免性方法和通用动态配置框架方法,得知避免性方法具有对应用系统本身没有过高要求,适用范围较广,动态配置性能较好,动态配置能力较强[8]等特点,由此采用该方法对服务更新模型进行非形式化描述,依据静止状态理论描述OSGi框架中的服务更新模型。
系统一致性由相互一致性和应用状态一致性组成,在系统运行过程中,各服务之间存在交互行为。由此:
定义1 服务间任意交互行为不能由于动态更新而被中断,这种约束被定义为服务更新前后一致性。
定义2 两个服务间一次完整的信息交互过程定义为一个事务。
由上,服务之间的所有可能状态我们用图3描述。图中BeUpdateService服务是要动态更新的服务,BeDependencyService1、BeDependencyService2、 BeClient Service1和BeClientService2是四个与BeUpdateService相关的事务服务,其中BeDependencyService1服务是参与已由BeUpdateService服务自行启动的事务服务,BeDependencyService2服务是参与将来由BeUpdateService服务自行启动的事务服务,BeClientService1是已自行启动并调用BeUpdateService参与的事务服务,BeClientService2是将来自行启动并调用BeUpdateService参与的事务服务。图中实线代表正在进行的事务,虚线代表即将启动的事务,即构成四类事务状态。
由于事务行为改变确定了服务的状态,为保证服务的动态更新具有服务交互行为的完整性,即服务更新前后的一致性,可根据服务启动和参与服务的方式,给出上述服务状态之间的交互行为定义。
定义3 服务在动态更新期间,与其他服务之间存在四种可能的交互行为即B1、B2、B3和B4。定义如下:
B1:服务当前参与自行启动的事务行为;
B2:服务将来自行启动的事务行为;
B3:服务当前参与由其他服务启动的事务行为;
B4:服务将来参与由其他服务启动的事务行为。
这四类交互行为会导致服务当前或将来处于不一致的状态中。这里,给出服务在动态更新前处于静止状态的定义。
定义4 如果服务满足以下条件,则定义服务处于静止状态。
条件1:服务当前没有自行启动的事务;
条件2:服务将来不会自行启动事务;
条件3:服务当前没有参与由其他服务启动的事务;
条件4:服务将来不会参与由其他服务启动的事务。
定义5 服务不存在自行启动的事务,只会被动参与由其他服务启动的事务,称为被动状态。
显然,基于上述服务静止状态和被动状态的定义,根据Jeff静止状态理论,可得出服务进入静止状态的定理:
定理1 服务的被动状态是可达的。
该定理说明在任何独立的系统中,服务可以从主动状态变为被动状态。
证明:
如果是被动状态,该服务必须满足:服务当前没有参与由其他服务启动的事务;服务将来不会自行启动事务;
由于该服务的完成独立于其它服务,因此该服务会在服务启动后的一定时间内完成,因此,满足第一个条件。
任何应用服务在没有被调用时,都不会自动启动和运行,因此,满足第二个条件。由此证明,服务的被动状态是可达的。
定理得证。
服务Q的被动状态集合PS(Q)是由Q以及所有可以自行启动调用Q参与的服务组成。
定理2 当PS(Q)中的服务都进入被动状态时,服务Q进入静止状态。
该定理说明在任何独立的系统中,如果PS(Q)中的所有服务都处于被动状态,那么服务Q处于静止状态。
证明:
因为服务Q属于被动状态集合PS(Q),根据服务Q是被动状态,满足定义4中的条件1和2。
PS(Q)中服务的被动状态说明可以自行启动调用Q参与的服务处于被动,那么,包含Q的所有服务完成了,并且没有新的服务将被启动,满足定义4中的条件3和4。
由定义4可知,服务Q进入静止状态。
定理得证。
定理3 服务的静止状态是可达的。
该定理说明在任何独立的系统中,如果PS(Q)中的所有服务从主动状态迁移为被动状态,则服务Q在一定时间内从主动状态进入静止状态。
证明:
由定理1得到在一定时间内,服务可以进入被动状态。根据定理2,在PS(Q)中的所有服务进入被动状态时,服务Q进入静止状态。因此,服务Q进入静止状态。
定理得证。
上述给出了被动集合PS的精确定义以及服务进入静止状态的定理,在实际系统中精确计算PS集合的方法是基于静止状态理论的服务动态更新策略的关键。为此,我们给出PS精确计算方法并驱动集合中的服务进入被动状态的算法,实现服务动态更新。
1.3 服务动态更新策略
针对图3给出的服务之间所有可能状态,基于OSGi规范中的Event Admin Service发布/订阅模型,计算BeUpdateService服务的被动状态集合。
针对所有自行启动并调用BeUpdateService参与的服务订阅BeUpdateService的“更新开始”事件和“更新完成”事件,在BeUpdateService的被动状态集合中,服务进入被动状态的算法描述如下:
(1) 设立BeUpdateService计数器,指示当前调用BeUpdateService的次数(包括自行启动的事务和参与其他服务的事务);
(2) 在BeUpdateService每次发起对BeDependencyService的调用时,先检查是否已发布了“更新开始”事件,如果已发布,则停止所有工作并保存状态;
(3) 在每个BeClientService每次调用BeUpdateService时,先检查是否已收到BeUpdateService的“更新开始”事件,如果已经收到,缓存或阻塞本次调用;
(4) 更新BeUpdateService。
服务动态更新过程是多个服务并行执行各自策略进行交互的过程。对其动态更新算法利用Petri网的图形表达方式进行直观描述,如图4所示。图中将服务当前所处的状态定义为库所(Place,圆形节点),将对服务的各种操作定义为变迁(Transition,方形节点),变迁中的数字表示了一种可能的顺序。其更新描述为:
(1) BeUpdateService发布“更新开始”事件;
(2) BeUpdateService监视计数器,等待计数器归零时才继续;
(3) BeUpdateService等待自身工作的结束,结束后才继续;
(4) 注册同名的新服务;
(5) 状态迁移,包括收集旧服务的状态以及复制状态至新服务中;
(6) 注销旧服务;
(7) BeUpdateService发布“更新完成”事件;
(8) 发送每个BeClientService中被缓存的调用;
(9) 更新操作结束。
从图4中的标号4可以看出,计数器归零代表全部BeClientService停止发起需要BeUpdateService参与的事务,并且BeUpdateService自身也停止发起调用;全部BeClientService代表所有能够自行启动需要BeUpdateService参与的服务,即PS(BeUpdateService) = BeClientService∪BeUpdateService,依据定理1、定理2和定理3,BeUpdateService在变迁A处进入静止状态,可以在保证服务相互一致性的环境下进行服务更新操作。从我们给出的服务动态更新步骤的动画演示[9]中,可以得到图4的动画演示。
2 模块的动态更新策略
在实际的应用环境中,可能需要对整个模块进行动态更新,这里给出模块动态更新与服务动态更新的关系,以服务的动态更新代替模块的动态更新。由于在OSGi框架中一个模块含有多个服务,因此给出定义6以及模块动态更新的概念。
定义6 SS(Bundle)代表模块Bundle中所有服务的集合,即SS(Bundle)={S1,S2, …, Sn},Si是Bundle运行时对外提供的一个服务。
定义7 当SS(Bundle)中至少有一个服务Si被动态更新,则称Bundle模块被动态更新。
定理4 当且仅当模块Bundle有若干个服务S1, S2, … ,Sn,即:SS(Bundle) = {S1, S2, … ,Sn},则更新模块Bundle可以被更新S1, S2, … ,Sn服务替换。
证明:
依据OSGi框架中一个模块含有多个服务,即模块Bundle中的所有服务SS(Bundle)= {S1, S2, … ,Sn},其中的一个或多个服务被动态更新,则由定义7可以得到,模块Bundle被更新。即模块Bundle更新可由更新模块中的服务替换。
定理4表明,一个Bundle模块的动态更新可以用更新其内部的服务来代替,Bundle在运行时是以服务的形式对外提供功能,替换Bundle中的服务相当于替换该Bundle在运行时的功能。由此,把更新模块的问题转化成更新服务的问题,从而对整个模块进行动态更新时避免引入新的计算。
3 实验与讨论
3.1 实 验
针对图3描述的服务,对提出的服务动态更新策略在OSGi框架下通过实验进行验证。由于BeClientService2和BeDependencyService2实际不参与动态更新过程,因此在实验中,只保留BeUpdateService、BeClientService1和BeDependencyService1三个服务。实验采用Equniox作为OSGi框架的实现产品,使用线程等技术进行模拟,实验源代码可从我们的网站[10]中得到。
● BeClientService1持续调用BeUpdateService中的hello方法。
● BeUpdateService持续调用BeDependencyService1中的hi方法。
● 1秒钟后BeUpdateService发布“更新开始”事件,服务动态更新开始。
● BeUpdateService保存被BeClientService1的调用次数作为状态。
首先,在BeUpdateService服务没有开始更新前,从图5可以观察到相关服务BeClientService1正在调用BeUpdateService, BeUpdateService正在调用BeDependencyService1,其中BeUpdateService的State随着被调用次数的增加而增加。服务正常运行,对客户端不产生影响。
其次,BeUpdateService服务更新开始,在更新过程中,客户端BeClientService1不能调用该服务,导致服务调用延迟,即等待计数器归零和服务自身工作停止所消耗的时间。同时对于不能调用正在更新的服务,在实验中采用缓存方式。
从图6中可以观察到BeUpdateService发布“更新开始”事件后,分别经历了等待调用结束即等待计数器归零和等待自身工作结束两个过程,期间BeUpdateService不再参与由BeClientService1发起的调用,BeUpdateService自身工作结束后,也不再发起任何调用,即进入了静止状态。
最后,BeUpdateService服务更新完成后,图7显示BeUpdateService服务更新完成后的相关服务工作状态,图中带cache标记的调用是更新前被缓存的调用。在服务更新完成后,对服务更新期间不能完成的服务,由于收集状态和迁移状态消耗时间而产生延时,导致服务调用延迟。
对比更新前后的服务,可以得知BeUpdateService的内部状态保持连续,说明状态迁移成功。
由此,验证了基于主题发布/订阅模型的服务动态更新策略的可行性和有效性。
3.2 讨 论
本文所提出的服务动态更新策略是在OSGi框架下实现的,在服务正常运行时对客户端不产生影响。但是,在服务更新期间,由于客户端不能调用正在更新的服务,导致服务调用延迟,根据实验分析得到延迟时间主要由两部分决定:一是更新开始后,等待计数器归零和服务自身工作停止所消耗的时间T1;二是收集状态和迁移状态所消耗的时间T2。其中T1主要由服务的响应性能和客户端数量来决定,T2由服务的应用特点来决定。所以,对客户端的影响主要取决于服务设计本身。
对于不能调用正在更新的服务,所有客户端应将调用缓存或阻塞,以解决服务更新期间对客户端的影响。采用缓存方式或者阻塞方式取决于客户端对外的接口类型。如果客户端对外提供异步接口,那么采用缓存方式,如果客户端对外提供同步接口,则采用阻塞方式。
另外,针对本文给出的服务动态更新策略算法实现,在实验源代码[10]中增加了以下四部分代码:计数器变量;在方法调用的开始处计数器自增1;在方法调用的结束处计数器自减1;客户端订阅“更新开始”和“更新完成”事件。可以看出增加的代码没有破坏通用的程序架构设计,并且针对这部分代码,使用AOP技术加以封装,使得编程模型具有松耦合的特性,符合业界标准,封装后具有良好的编程模型,明显优于使用代理机制的方法。在整个更新过程中,BeUpdateService状态始终保持唯一,从而保证状态的一致性,克服了注册同名服务方法状态不一致的缺点。
4 结 语
OSGi是Java领域未来的模块化标准。本文致力于解决OSGi框架中对服务进行动态更新的问题。针对OSGi平台的特点,提出基于事件/订阅模型的服务动态更新策略。该策略使用OSGi规范中的Event Admin Service建立一套服务与服务之间的通信机制,依据静止状态理论,建立OSGi框架中的服务更新模型,给出驱动服务进入被动状态的算法,实现服务动态更新,保证了服务在更新前后的相互一致性。通过对该策略的参考实现,验证了该策略的可行性和有效性,并对服务更新期间对客户端的影响进行了分析。下一步的研究重点是简化开发,实现该策略对开发人员透明。
参考文献
[1]张友生.软件体系结构[M].2版.北京:清华大学出版社,2006.
[2]李琼,姜瑛.动态软件体系结构研究综述[J].计算机应用研究,2009,26(6):2352-2355.
[3]OSGi Alliance.OSGi Service Platform Release4Enterprise Version4.2[EB/OL].[2010-3-1].http://www.osgi.org/Specifications/HomePage.
[4]Chen Junqing,Huang Linpeng.Dynamic Service Update Based on OSGi[C]//Proceedings of WRI World Congress on Software Engineering 2009.Xiamen:IEEE Computer Society Press,2009,3:493-497.
[5]张仕,黄林鹏.基于OSGi的服务动态演化[J].软件学报,2008,19(5):1201-1211.
[6]李三红.基于OSGi服务模型实现组件之间松耦合通信[EB/OL].[2009-12-23].http://www.ibm.com/developerworks/cn/open-sour ce/os-cn-osgicommunic/index.html.
[7]林昊,曾宪杰.OSGi原理与最佳实践[M].北京:电子工业出版社,2009.
[8]李长云,何频捷,李玉龙.软件动态演化技术[M].北京:北京大学出版社,2007.
[9]赵杰.服务动态更新步骤动画演示[OL].[2010-02-14].ht-tp://202.121.64.92:5566/zhaojie/osgi/dy-strategy-petri.pptx.
发布订阅系统 篇6
随着人类空间科学活动的逐步深入和空间应用研究的不断发展,空间信息网络的相关研究受到高度关注。空间信息网络旨在高动态条件下空间信息的快速获取、实时传输、协同处理和智能服务,将人类科学、生产和军事活动扩展至外层空间。
近年来,围绕着空间信息网络,以美国为首的西方国家相继展开了一系列研究,其中包括IPN项目[1]、OMNI项目[2]、TSAT项目[3]和SCa N项目[4]等。我国的空间信息网络的相关研究受到高度关注。沈荣骏等提出了我国天地一体化航天互联网的总体目标、组成、网络体系结构及网络协议的初步构想[5]。李德仁等对空天地一体化对地观测网进行了概念研究[6]。
空间信息网络[7]是一个立体动态异构网络,节点种类和数量多,异构特性明显。发布/订阅通信模式(P/S)与传统的网络通信模式(端到端通信)相比,减少了信息传输的中间环节,能够很好地适应节点运动带来的切换、拓扑变化及断续连接等情况,且秉承ICN[8]和DTN[9]网络的数据存储转发机制,数据将在网内进行缓存,然后通过网络直接发送给接收节点,通过多点多路劲的网络化传输机制克服单点单路径传输灵活性、鲁棒性、柔韧性及可扩展性差的缺点。因此有效的信息缓存机制和方法就成为网络有效运行和信息高效可靠传输的一个关键问题。
1 发布/订阅通信方式
发布/订阅通信模式[10]是一种使分布式系统中的各参与者,能以发布/订阅的方式进行交互的通信模式。其中,信息的生产者和消费者之间所交互的信息被称为事件。事件的生产者称为发布者(publisher),事件的消费者称为订阅者(subscriber),发布者和订阅者统称为客户端。发布者产生事件并发送给事件服务器,所有订阅者都可以表达对事件的兴趣,事件服务器可以将事件异步传播到所有对该事件感兴趣的用户上。这种基于事件的交互方式的优势在于发布者和用户之间的时间,空间和同步完全解耦。
发布/订阅通信模式为用户提供了表达自己兴趣的能力。发布者是产生事件的主体。在另一方面发布者将信息发送到事件服务器上,用户向事件服务器订阅想获得的内容。
基本的系统模型如图1所示,事件服务为订阅者提供存储与管理,和有效的发送事件给订阅者。事件服务是发布者与订阅者之间的中介。订阅者登记他们对事件的兴趣,而无需知道这些事件的资源在哪。此订阅信息直到被退订,不然一直储存在事件服务器中,而不会转发给发布者。
目前,发布/订阅通信系统分为基于渠道的发布/订阅,基于主题的发布/订阅,基于内容的发布/订阅,基于类型的发布/订阅。
2 空间信息网络体系架构概述
空间信息网络[11]是以多种空间平台(如同步卫星或中、低轨道卫星、平流层气球和有人或无人驾驶飞机等)为载体,实时获取、传输和处理空间信息的网络系统。其系统组成如图2所示。
从图2可以看出,相比其他信息系统,空间信息网络具有以下明显特征:①空间分布上是一个立体多层的网络;②节点类型多,网络具有异构性;③节点、链路随时空变化,拓扑具有动态性;④业务种类多,需求差异性大;⑤系统资源(轨位、频率、功率、处理、计算、存储)严重受限。
根据网络中节点属性、链路能力、任务特点和分布空间等,将空间信息网[12]划分为以下几个主要组成部分,系统中节点分布与相互间连接关系如图3所示。
①GEO卫星骨干网:整个骨干网由3~5个分布在不同轨道位置上的同步轨道(GEO)卫星簇组成。每个GEO卫星簇可由一颗或多颗GEO卫星组成,物理上可能包括通信、中继、遥感和导航等多种卫星,逻辑上可以看作一个卫星节点,簇内卫星协作完成包括信息获取、处理、传输、交换、存储、计算和分发等功能。GEO卫星簇之间和簇内各卫星之间可通过高速的微波或激光星间链路实现信息交换。
②服务增强卫星网:服务增强卫星网作为GEO卫星骨干网的补充,改善高纬度地区和极区的服务性能,可根据需要在空间信息网络的建设过程中逐步扩展完成。服务增强卫星可能工作在倾斜同步轨道(IGSO)、高椭圆轨道(HEO)、中轨道(MEO)或低轨道(LEO)上,可以通过星间链路或地面信关站实现与GEO卫星簇之间的信息交换。
③升空平台网:升空平台(HAPS)主要布设在应急救援、城市热点等区域,实现区域内的通信、导航和遥感增强。各升空平台之间、升空平台与地面/卫星节点之间可以通过微波或激光链路实现相互间的信息交换。
④运行控制网:其主要任务是管理整个空间信息网络,维持各类空间平台的正常可靠运行,为用户提供业务支持,满足各类用户的使用需求。
⑤接入网和地面网。
这里以针对热点地区进行信息获取、处理、传输和分发的应用场景为例,给出空间信息网的工作流程示意图,如图4所示。其业务流程主要包括以下几个步骤:
①对地观测卫星根据指令运行到热点区域上空后进行信息获取,并将获取到的遥感数据进行必要的预处理;
②对地观测卫星将信息传输到GEO卫星骨干网,在GEO卫星骨干网中进行一定的信息处理、传输和交换;
③信息在轨或者传输到地面信息栅格后生成可供用户使用的遥感产品;
④用户通过GEO卫星、服务增强卫星、升空平台等途径获取存储在地面信息栅格或GEO卫星骨干网中的遥感产品。
3 发布/订阅的空间信息网络应用架构
目前,许多学者开始关注信息为中心的网络(Information Centric Networking,ICN)在卫星网络中的运用[13],与发布/订阅通信模式相比,它们都是着重于信息本身,忽略终端用户,不同点在于ICN并非采用IP协议簇,发布/订阅通信模式是在IP协议簇的基础上结合了网络缓存。文献[12]表明网络缓存可以提高卫星网络的通信资源效率,减少卫星带宽资源浪费。
在空间信息网中,发布者是上文所指的信息产生节点可以是升空平台、GEO卫星或其他卫星系统等,订阅者并非所有的信息接收者,而是特指用户终端,因为目前发布/订阅的事件指的是遥感信息和传统的通信业务,测控信息与指控信息并不在考虑范围之类。
由于空间节点的多样性,将空间信息网络分为多个自治域[14](Autonomous System,AS),每个自治域和子自治域都设有一个边界节点,负责不同域之间网络状态和理由等信息的交换。这样,既把每个AS域内部的拓扑变化相互屏蔽,减小了网络管理和路由计算的复杂度,又便于卫星和升空平台的“即插即用”。具体网络拓扑结构如图5所示。
该模型将路由控制信息和业务信息的传输进行分离,AS域间边界节点用于路由计算与控制,地面运控中心站所发出的控制和路由信息通过控制链路发送到边界节点,边界节点再根据各自治域内部路由发给域内其它节点。而与用户相连的边界节点充当事件服务器,实现业务的发布/订阅,这样可以降低控制链路的信息传输和网络拥塞的概率,提高控制管理信息传输的效率和可靠性,确保有效的网络管理和路由信息的分发,从而提高全网运行效率和可靠性。
假定一种场景如图6所示,来描述基于发布/订阅通信模式的空间信息网络应用架构。在该场景中,遥感卫星A作为事件的生产者,将遥感信息发布到其所在的AS1域中,AS1域与AS2域相连的边界节点进行数据的交互,这样,AS2域中也就存在了此事件,此时用户F需要下载该信息,则只需要向其所对应的AS2域内边界节点D提出请求即可。如果采用点到点的通信模式,那么此时的通信距离至少是链路1与链路2的长度之和(区域内链路忽略)。假设链路1与链路2的长度相同,每段链路无差错的概率是a,那么进行一次通信,点到点的通信模式比发布/订阅通信模式的通信长度多一倍即通信时间长一倍,出错概率多1+a2倍。假设AS2是一个低轨卫星域,低轨卫星的过顶时间大约十几分钟,如果用户与D的通信中断了,由于网内有缓存,则用户可以直接向切换后的卫星提出下载要求,而在点到点通信中,切换后卫星还需再次向F提出请求。所以在空间信息网络中,由于链路的高时延,高误码率,易中断的特点,会放大点到点的通信模式的缺点。此外,安全性也是发布/订阅通信模式的优点之一,因为发布者对用户是不可见的,所以增加了非法用户对其恶意攻击的难度。综上所述,将发布/订阅通信模式与空间信息网络相结合有一定的意义。
3.1 发布/订阅通信模式软件模拟环境
在此软件模拟环境中,可以在用户端与服务器上设置发送文件的睡眠时间值来模拟空间信息网络中的时延,通过设置备用服务器,中断用户所连接的主服务器来模拟空间信息网络链路中断的情况。由于TCP协议在卫星通信系统中存在回传时间长、拥塞窗口增长缓慢、丢失数据包的恢复时间长和接收窗口受限等问题[15],所以采用UDP协议进行数据传输。此外,发布/订阅通信方式设有两种工作模式:
①如图7所示,发布者将事件发布到事件服务器上,服务器会在整个网络中泛洪,告之其它事件服务器该事件并将其缓存下来,用户可查询与之相连的服务器中所有已发布的事件并进行下载,这是一种传统的存储转发模式。为了解决网络中的可靠性问题,采用的最简单的复制冗余策略,即对每个发布的事件都在不同的节点上存储一模一样的备份。只要这些备份有一个没有发生故障,数据就不会丢失。这种复制策略结构简单,易于实现,并且节点修复也很简单,新节点只需从存活节点上找到与发生故障的节点同样的数据拷贝过来即可。但其有个严重的缺点,就是冗余存储量过高,例如假设单个节点可靠性为0.5,想要维持整个系统可靠性大于0.999的话就需要至少10个冗余节点。
②如图8所示,第二种工作模式利用纠删来码改进复制策略存储开销太大的缺点,发布者先将原始文件分成K份,原始文件长度为L。每一份子文件长度为L/K。然后产生一个N×K的生成矩阵G(N>K),该矩阵是一个范德蒙矩阵,其中的元素取自有限域(有限域的范围大于N),所以该生成矩阵的秩为K。这样原始文件经过生成矩阵产生N个子文件,获得任意K个子文件即可恢复成原始文件。客户端将个子文件上传至边缘服务器,边缘服务器将这N个子文件按照一定策略发送给其余服务器(本文所采用的策略是依次发送);其他用户下载时需将任意K个子文件取回至边缘服务器并下载到用户进行解码获得原始文件。通过对数据进行编码,来降低维持系统可靠性所需的存储开销并将风险均摊的方法来提高整个系统的可靠性,并且还有保密作用,只截获一块数据并不能还原源文件。
3.2 软件运行示例
本文采用delphi应用程序开发工具实现基于局域网的空间信息网络发布/订阅通信模式软件模拟环境。Delphi是windows平台下著名的快速应用程序开发工具(Rapid Application Development,简称RAD)。
图9给出了一个实例,文件“Delphi组件参考大全.pdf”在PC1经过4×3的生成矩阵共产生4个子文件,上传给边缘服务器A,A将子文件依次发送给B和C,B和C中分别有两个子文件,PC2下载该文件时,由于C中子文件小于3需要从A或B中任意下载一个不同的子文件即可在客户端进行解码。图10为源文件与编码后文件的示意图。
4 结束语
本文主要对空间信息网络的发布/订阅的通信方式进行研究,旨在明确P/S通信方式在空间信息网络中的重要意义。分析了发布/订阅(P/S)通信模式时间、空间、同步的解耦特点与空间信息网络的域间、域内通信架构,论述了在空间信息网络中,发布/订阅(P/S)通信模式与点到点的通信模式相比,可以减少时延降低差错概率的优势。并且,通过delphi应用程序开发工具设计了一个基于局域网的空间信息网络发布/订阅通信模式软件模拟环境。
摘要：通过对发布/订阅(P/S)通信模式和空间信息网络体系架构的分析,论证了发布/订阅(P/S)通信模式与点到点通信方式相比有一定的优势,并在此基础上,研究了基于发布/订阅通信模式的空间信息网络应用架构,设计并实现了一个基于局域网的空间信息网络发布/订阅通信模式软件模拟环境,实现了数据在网络上缓存,用户无需从数据发布者处获得资源,可直接通过网内缓存下载。
发布订阅系统 篇7
化州电视台播出系统是在2002年投入使用的, 受资金和技术条件等的限制, 当时只配备了一台播出服务器。随着设备的老化, 服务器的安全性能不断下降, 特别是去年以来, 故障率较高。为确保播出安全, 我们在化州电视台现有设备的基础上, 组装了一台备份服务器, 使用SQL数据库订阅发布机制实现两数据库准实时备份, 采用以主备播出服务的播出方式, 当主播出现故障时, 由备份播出立即接管工作, 从而保证信号不间断, 提高播出的安全性。本文以化州电视台播出系统为例, 谈谈使用SQL订阅发布机制在电视台播出数据库准实时备份应用的心得体会。
一SQL Server的复制技术
数据库复制是通过发布、订阅的机制进行多台服务器之间的数据同步备份。
1. 复制模型
复制模型有中心出版者和中心订阅者方式。中心出版者模型指一个出版服务器对多个订阅服务器;中心订阅者模型指多个出版服务器将数据发表到单一的订阅服务器。
2. 复制的基本元素
发布服务器 (出版服务器) :数据的来源服务器。
订阅服务器:是发布服务器数据的副本, 接收维护数据。
分发服务器:是执行出版物存储与转发功能的服务器。
3. 复制类型
SQL Server提供三类复制类型:快照复制、事务复制、合并复制。快照复制指在某一时刻给出版数据库中的出版数据照相, 然后将数据复制到订阅者服务器。通常使用在一定时间内出现大量的更改的操作, 但数据总量不大, 变化周期较长的场合。事务复制是将整个数据集发送给订阅服务器, 事务复制是一种接近实时地从源到目标分发数据的方法。合并复制是为移动用户设计的, 可以在发布服务器或是订阅服务器处执行修改。
二化州电视台播出系统现状及采用的订阅发布方案
化州电视台现办有无线、有线2个自办频道及多个插播频道, 使用精正自动播出软件, 数据库管理系统为SQL Server 2000。主数据库服务器计算机名为CastServer, 备数据库服务器计算机名为CastServer2。数据库名为castDB。根据化州电视台的工作特点, 我们采用中心出版者模型的快照复制技术方案 (如图1) , 即主数据库服务器生成快照, 备份库服务器读取并加载该快照。
三主备服务器与播控软件的设置
首先, 确认两台机器的名称不使用中文名称, 并在两台机器上分别安装SQL Server 2000以及SQL Server 2000SP4。安装了SQL Server 2000后如果需要修改机器名称, 必须先卸载SQL Server 2000, 并且手动完整删除SQL Server 2000的安装文件夹C:Program FilesMicrosoft SQL Server。修改机器名称后再重新安装SQL Server 2000。
第二, 将初始数据库文件castDB.mdf、castDB.ldf分别拷贝到两台机器的硬盘上。在主机CastServer上进入SQL Server企业管理器, 删除默认的 (local) 节点, 然后, 将两台机器以“新建SQL Server注册”的方式添加两台机器CastServer、CastServer2, 其中CastServer将作为主数据库服务器, CastServer2将作为备数据库服务器。
第三, 将拷贝到硬盘上的数据库文件castDB.mdf附加到主备数据库服务器中。附加完数据库后, 在主机CastServer安装播出软件 (一定要安装系统管理员组件) , 安装完毕后启动“系统管理员”, 并设置数据库登录用户名、密码、主服务器、备服务器、数据库名称 (如图2) 以及设置播出网络通行用户的名称和密码 (如图3) 。
第四, 进入Windows控制面板, 打开管理工具, 打开“服务”进入服务管理界面:MSSQLSERVER服务, 修改登录帐户。修改完成后, 右键单击服务“MSSQLSERVER”, 在弹出菜单中选“启动”或“重新启动”。保证系统托盘里SQL Server服务管理器的“MSSQLSERVER”和“SQLSERVERAGENT”两个服务都是随操作系统启动自动启动的。
四安装数据库订阅发布机制的步骤
1. 服务器CastServer节点
从菜单中选择“工具”→“复制”→“配置发布、订阅服务器和分发”。
2. 发布数据库
从菜单中选择“工具”→“复制”→“创建和管理发布”, 点击创建发布数据库。
3. 等待数据库初始快照代理程序执行完毕
展开CastServer下的“复制监视器”, 右键单击“快照”, 点击“启动代理程序”, 然后按住F5键, 直到快照状态显示为“已成功”或者“上次动作”不再变化。
4. 订阅数据库
从菜单中选择“工具”→“复制”→“创建和管理发布”, 选中castDB节点, 点击“强制新订阅”。选择备机CastServer2作为订阅服务器, 然后输入订阅数据库名称castDB。
5. 设置代理程序属性
展开复制监视器节点, 选中“castDB:castDB”, 并按F5键刷新。右键单击代理程序“CastServer2:castDB”, 选择“代理程序属性”, 选择“调度”页面单击“新建调度”按钮, 输入调度名称“第二调度”, 点击“更改”按钮设置, “发生频率”为“每天”, “发生周期”为“1分钟”。
化州电视台播出服务器采用订阅发布机制实现了播出数据库准实时备份后, 各项指标均达到播出要求, 并在突发故障中发挥了重要作用, 有效保障了安全播出。
摘要：对电视台播出系统来说, 服务器的数据库是系统的核心。特别是多频道硬盘播出系统, 应对数据库采用高技术保障和备份措施。本文以化州电视台播出系统为例, 介绍使用SQLServer的订阅发布机制实现主备服务器的数据库准实时备份的经验。
关键词：服务器,数据库,复制,订阅发布机制,准实时备份
参考文献
[1]韩高才, 徐英WINDOWS2000SERVER中文版实用大全
[2]郝兴伟计算机网络原理、技术及应用
[3]周绪, 管丽娜, 白海波等SQL Server2000入门与提高
[4]张莉SQL SERVER数据库原理及应用 (第2版)