发布订阅系统范文

发布订阅系统范文（精选6篇）

发布订阅系统 第1篇

发布/订阅模型是分布式网络中一种有效的通讯机制。其异步、多点通讯的特点很好地满足了Interact上松散耦合的大型应用系统的需要，基于该模型的中间件目前已被广泛应用于金融、自动化控制、物流等众多领域。

发布/订阅系统包含发布者及订阅者，前者往系统中发布事件，后者则从系统中订阅其感兴趣的事件。发布/订阅系统通常建立在由事件代理组成的虚拟网络之上，由事件代理负责发布者和订阅者之间事件的传送。

发布/订阅系统可分为两类：基于主题模式和基于内容模式。最初的订阅系统都是基于主题的，每个发布的事件都被定义为属于某个主题，订阅者按主题进行订阅，属于某主题的所有事件都会被发送到相关的订阅者，这种方式常常导致订阅者接收到一些他们并不需要的信息，优点是实现简单、有效，但表达能力较弱。后来出现的基于内容的发布/订阅系统则更加灵活、高效，订阅者可以根据事件属性的值来自由设置订阅信息，避免了订阅者对无关信息的获取，提高了网络的利用率和传输效率，缺点是给系统根据订阅条件来匹配大量事件，带来很大负担，增加了系统的复杂性。如何使事件沿着一种恰当的路径，高效、可靠地到达各相关的订阅者，这就是发布/订阅系统路由协议所要解决的问题。

文章设计了一种新型的面向移动Ad Hoc网络的发布/订阅系统路由协议，该协议控制了订阅消息的传播，提高了系统的扩展性。

2 传统网络下的发布/订阅系统路由协议

2.1 传统网络下路由协议典型算法

Siena是采用支持订阅覆盖的路由算法，优点是各事件代理负载较为均衡，缺点在于：网络中的每个节点都同时处在多棵事件分发树中，其中包含的路由信息难以被其他节点所替代;一旦某节点失效，整个系统的路由重配工作将很困难。

Gryphon采用层次性网络结构，通过并行查找树算法来进行高效匹配，并尝试利用组播来节省网络带宽。由于Gryphon中的每个事件代理都保存着有所有订阅信息组成的并行查找树信息，因而路由表更新的代价也很高，Gryphon不适合于大规模网络的应用。

2.2 一种有环图下支持订阅覆盖路由算法

在无环图拓扑结构中，目前已有一些支持覆盖的路由算法如SIENA、JEDI等，但在有环图拓扑下，这些算法会形成订阅环路，导致事件转发死循环，因而不能直接用于有环图拓扑。

文章提出了一种新型的有环图下支持订阅覆盖路由算法，能有效减小中间代理的路由表，且由于采用最短路径转发，可显著提高事件转发效率。

2.2.1 有环图下支持订阅覆盖路由的基本算法

基本算法中，每个事件代理维护一张路由表，路由表中每条记录由订阅及转发该订阅的事件代理标识符组成。事件代理B收到订阅请求Sub(s,Ba)(s表示订阅条件，Ba表示转发该订阅的事件代理)，并设Br为该订阅请求客户所在的访问点代理。处理算法可简要描述为：1)如果Ba不是B到Br逆向最短路径上的下一跳，B丢弃该订阅;2)如果路由表中已存有等价或覆盖s的订阅，B丢弃该订阅;3)否则，事件代理保存该订阅，将所有被订阅s覆盖且转发者为Ba的订阅删除，并将其转发给除Ba外的所有邻居代理。

一般情况下，基本协议能正常工作，但仍存在事件转发形成环路的问题。例如，发布/订阅系统的系统拓扑为图1(a)所示，客户C1订阅S1，客户C2订阅S2，根据基本算法，各代理生成的路由表如图1(b)所示。客户C3发布事件e时，如果该事件同时匹配订阅S1和S2，则由图1(b)的路由表，事件e可沿着D-F和D-C-B-E-F两条路径到达F，使事件转发形成环路。

2.2.2 避免事件转发形成环路的机制

文章采用目的地动态更新及划分策略来避免事件转发形成环路。目的地动态更新策略是指如果中间代理发现新的目的地，且自身处在发布事件代理到目的地的最短路径上，则将该目的地加入到目的地集合中。目的地动态划分是指事件代理将所有与该事件匹配的目的地，根据不同的转发方向划分成各个子目的地集合。由于存在订阅覆盖，单个事件代理可能不具有完整的目的地集合，通过目的地动态更新策略，可使每个中间代理在转发事件的过程中，根据自身路由表补充新的目的地，从而使事件到达所有目的地。事件转发过程中，可能存在多条路径到达某个目的地，通过目的地动态划分策略，使事件仅通过其中一条路径到达目的地，避免事件转发形成环路。目的地动态更新及划分策略需要目的地信息，因而路由表中每条记录除订阅及订阅转发者外，需添加目的地的标识符。

以图1(a)所示拓扑为例，改进后协议的路由表与图1(b)所示的路由表基本相同，只是每条路由表记录增加相应的对事件感兴趣客户所在的事件代理标识符。客户C3发布同时匹配订阅S1和S2的事件e时，事件代理D先根据路由表获取目的地集合{A,F}，由于事件e发布时目的地集合为空，{A,F}即成为该事件的初始目的地集合;然后，根据转发方向将目的地集合划分成{A},{F};最后，将Event(m,D,{A})、Event(m,D,{F})分别转发给事件代理C和F;当该事件到达B时，将获取新的目的地F，但由于B并不在D到F的最短路径上，因而B不将事件转发给E。改进后的协议事件将沿着D-C-B-A和D-F分别到达A和F。

2.3 路由自重构策略

一般来讲，发布/订阅系统的自重构策略需解决如下三个问题：

1)事件代理网络的重建。

2)在不影响P/S系统的情况下，重配各个节点订阅表以保持订阅信息与事件代理网络的一致性。

3)减少或避免路由重配过程中的事件丢失。

现有的重构算法如Strawman、Helge算法等都是针对自重构策略某个问题展开讨论，本节设计了一种新型的拓扑重构算法，从整体上考虑底层网络拓扑变化时，事件代理网络的重构问题，包括事件代理网络拓扑更新、避免事件丢失的机制、以及重配各个节点的订阅信息。算法基本设计思想是通过周期性交互HELLO消息来维护与更新邻居状态表，并依据邻居状态表来完成事件代理拓扑的重建;通过引入挂起及激活两个操作实现与订阅对应的事件缓存方法，并使得重构过程能保证各事件代理订阅信息与事件代理拓扑的一致性。

本节引入的订阅挂起(Suspend)操作是指事件代理挂起与之断开链接的事件代理的订阅，当事件代理接收到匹配该订阅的事件时，将该事件在本地缓存。当断开的事件代理重新加入时，通过激活(Active)操作来通知当前事件代理所在拓扑的其他事件代理。其他代理收到激活消息后，再将缓存事件发布。这种方式将事件缓存机制与订阅条件相结合，只缓存匹配该订阅的事件，从而减少了各个事件代理的事件缓存数量。此外通过订阅挂起/激活操作，事件的缓存被分布在各个发布事件代理中，提高了事件的缓存效率及可靠性。

3 移动Ad Hoc网络下的发布/订阅系统路由协议

3.1 移动Ad Hoc网络下典型路由协议的分析与比较

RAFT-CBR协议通过重传确认机制，可以保证事件到达每一个目的订阅者。但该协议需要每个发布事件的代理在全网周期性广播事件公告，这将导致大量的网络开销;重传确认机制需要每个事件代理知道所有匹配的订阅者，这在大中型网络中较难实现的。

PSMR协议将发布/订阅路由与底层多播路由协议(ADMR)相结合，共同完成数据分发，从而提高了数据传送效率。PSMR协议的订阅表达能力受到协议数据包主题选项的限制，表达能力较弱，目前只支持主题方式的内容过滤。

HDRP协议是一种无结构的路由协议，通过线索来决定是否需要转发事件。优点是减少了网络维护开销，缺点是线索值的计算是根据未曾收到信标的周期数，存在线索值计算结果与实际邻居距离不一致的情况，可能造成事件丢失，仅适合于对可靠性要求不高的场合。

3.2 一种新型的基于Ad Hoc网络的发布/订阅系统路由协议

3.2.1 PSCR协议基本设计思想

文章设计了一种新型的基于移动Ad Hoc网络的发布/订阅系统路由协议：发布/订阅分簇路由协议(P/S ClusteringRouting Protocol,PSCR)。该协议具有更好的可扩充性，能保证事件投递的可靠性。

PSCR协议采用了分级结构，将网络内的节点分成两类：事件代理节点和客户节点。客户节点不参与订阅及事件的转发。事件代理节点的选择是通过底层的分簇算法实现。通过分簇算法将Ad Hoc网络分成多个簇，每个簇的簇头节点被作为事件代理为本簇内其它节点转发消息，其它非簇头节点则作为客户。在分簇网络结构之上，PSCR构建了一个事件代理拓扑，用于完成各个事件代理间通信。事件代理拓扑的维护主要是维护充当事件代理的簇头间的链接。采用这种方法将复杂事件代理拓扑维护分层，通过底层的分簇算法以及上层的拓扑重构算法共同来完成Ad Hoc网络下事件代理拓扑的维护。

在分簇结构的网络中，当客户跨簇移动时，若客户与原有的事件代理链接被断开，而新的链接未建立，将导致事件的丢失。针对这一问题，PSCR协议设计了一种能避免消息丢失的客户移动维护机制。该机制核心算法与同步切换算法基本相同，思想是通过周期性发布测试事件来完成新旧事件代理的同步，以避免事件丢失。

3.2.2 客户移动处理机制

在分簇结构的网络中，客户移动可分为簇内移动和跨簇移动。由于簇内移动不影响客户接收事件，一般无需任何处理。当客户跨簇移动时，由于客户与原有的事件代理链接被断开，而新的链接未建立，将导致事件的丢失，针对这一问题，PSCR协议采用客户路由切换算法来完成客户订阅的迁移。为检测客户链接的断开，客户需周期性向事件代理发送“心跳”消息(heart msg)，事件代理根据该消息来更新客户状态。如果一段时间内事件代理没有收到客户的“心跳”消息，即认为客户离开。当客户C移动至其他簇时，客户C向新的事件代理发送订阅请求以重新建立路由。为了区分是簇内新加入客户，还是跨簇移动客户的订阅请求，客户需要在订阅请求中加入原有事件代理标识符。

当事件代理收到跨簇客户的订阅请求时，事件代理首先判断原有订阅路由是否覆盖该订阅，若覆盖，则事件代理将发送取消缓存事件命令给原有事件代理，通知原有事件代理取消对该客户的事件缓存。若原有路由不存在，则事件代理为该客户建立路由。

4 系统测试

文章从协议正确性和事件投递率两个方面来考察PSCR协议的正确性。实验相关配置如下：六台内存为1.00GB普通台式电脑;网络拓扑如图2所示，A、B、C、D为事件代理，c1和c2为客户;属性类型(Type)

使用基本数据类型String，属性名称(Name)为Season，属性值为集合{SPRING,SUMMER,AUTUMN,WINTER}内的值;参数定义：初始时事件代理A、B、C、D首先分别向其邻居请求订阅：

每个事件大小100字节，事件代理的缓冲区大小设为1024个事件。

4.1 协议正确性测试

实验步骤：实验时间200s，测试开始后客户c1与c2随机发布事件。80s后，B,C间链接断开，20s后A与C建立链接，实验5次求总和。

实验结果：c1和c2发布事件及各事件代理收到及缓存事件数的统计如表1所示。

结果分析：A、B、C、D各事件代理均没有丢失事件或重复事件，表明了协议在事件代理间链接断开重建后，能维护路由表的正确性，并且能保证事件投递的可靠性。A总共缓存事件数为135，其中64件为与订阅“Season=SPRING”匹配的事件，71件为与“Season=SUMMER”匹配的事件，A为其他订阅缓存的事件为零。表明协议仅对满足订阅条件的事件缓存，其他事件不缓存。事件的缓存被限制在发布事件的代理上。

4.2 协议可靠性测试

实验步骤：c1以每秒15件的速度发布随机事件，c2订阅“Season=WINTER”，实验时间150s，测试开始后客户c1随机发布事件，30s后c2与D的连接断开，延迟30s后c2与C建立连接(模拟c2漫游至事件代理C)。

实验结果如表2所示。

结果分析：在不同延迟时间下，客户c2均收到了所有c1发布的匹配事件。但同时c2也接收了少量的重复事件，这是由路由切换过程引起的。为此需要标识每个事件，代理根据事件标识符来合并重复事件。在延迟时间为30s、60s的情况下，D为c2分别缓冲了162、246个事件。表明随着延迟时间的增加，需要更大的缓冲区来避免事件丢失。

5 结论

发布订阅系统 第2篇

Laharsub是一种构建在三层架构之上的发布-订阅消息服务器： 前端――客户端，中间层――web服务，后端――带有发布-订阅功能和存储能力的系统。 客户端一般是浏览器，但是可以是所有已知能够做出HTTP请求的程序，

中间层是一种WCF的HTTP服务，它会从客户端接收消息，并向其发送消息，而后端会包含真正的与消息相关的逻辑。

客户端可以创建主题，并通过RESTful 的API向它们提交消息，而其它客户端会通过HTTP的长轮询机制（long polling）来订阅多种主题。 客户端使用一个请求就可以订阅多个主题。 Laharsub提供了jQuery、Silverlight和.NET 4.0的客户端，负责设计结构、多路传递以及长轮询的管理。 据项目的协作者Tomasz Janczuk所说，Laharsub在将来会使用WebSockets。

性能图示：

发布订阅系统 第3篇

关键词：发布/订阅系统,CCBMTRC算法,小世界网络,邻居集,组播树

0 引言

发布/订阅 (Publish/Subscribe, Pub/Sub) 系统是一种新型的面向应用和服务的通信模式, 改变了原来按地址寻址的通信方式, 建立了以内容语义寻址的通信方式, 具有松耦合、多对多、异步以及匿名等通信特征, 适应了大规模分布式计算的要求, 直接反映了以信息为导向的应用的内在特征, 近年来对这一问题的研究正在向多个领域扩展, 包括传感器网络、Ad hoc网络及机会网络等。

传统的Pub/Sub系统由于匹配和路由算法的复杂性, 难以向Internet规模的网络扩展, 主要原因是Pub/Sub系统在路由时, 一方面需要进行匹配和路由计算;另一方面由于Pub/Sub系统的匿名性, 需要遍历网络内的所有代理, 会增加网络代理的计算开销和网络负载, 限制网络的可扩展性。

研究表明:现有的各种网络大都具有复杂网络的特性, 与随机网络相比, 复杂网络具有集群系数高而且平均最短路径小的特点。

本文结合复杂网络的特征和路由遍历算法, 为减轻由于事件匹配所带来的网络负载压力, 基于复杂网络及其邻居关系, 提出了基于集群系数特性的组播树构造 (Clustering Coefficient-Based Multicast Tree Constructing, CCBMTRC) 算法, 并对该算法进行了理论分析和仿真实现。

1 相关工作

影响Pub/Sub系统路由性能的关键在于系统通信的匿名性, 为了寻找特定的通信对象, 系统必须采用遍历算法。目前, 主要的遍历算法包括:洪泛法 (Flooding) 、匹配优先法、Gossip算法以及感染算法。但这4种算法都是基于广播的, 由于广播容易造成系统内事件不具有定向属性, 使得无关的代理也必须接收遍历信息, 并进行匹配, 甚至可能将事件转发给没有订阅该消息的消费者。

很多Pub/Sub系统将事件代理网络预先组织成特定的拓扑结构, 并针对特定的拓扑结构, 建立特定环境下的订阅和事件转发, 如生成树转发算法、基于逆向路径转发算法和CBCB算法等。

CBCB (Combined Broadcast and Content Based) 算法采用广播算法和基于内容的路由算法相结合。该路由算法在两个层面实现:广播层和基于该广播层上的内容层。广播层把每个消息当作广播消息, 并对广播树进行基于内容的裁剪形成所需的组播树, 来限制消息的传播, 使消息仅仅到达那些发布了相应匹配订阅的节点。但CBCB路由算法中, 采用Flooding算法来遍历代理, 同样也给网络带来了巨大的负载压力。

这些基于静态拓扑的算法虽然在一定程度上简化了原有的路由算法, 优化了某些网络特性, 如流量、负载平衡等, 以期实现高效、低负载的事件传播, 但是这些算法普遍都采用Flooding或Gossip等方法来遍历代理网络。随着Pub/Sub系统规模的扩大, 以及网络内部的海量事件, 基于Flooding或Gossip的代理遍历方法, 大大增加了网络负载。为此, Pub/Sub系统需要在传统遍历算法基础上进一步动态、快速地完成遍历以进行匹配。

2 CCBMTRC算法

本文将代理网络构建为小世界网络, 并采用CCBMTRC算法来实现网络遍历。

小世界网络的构造方法为:采用有N个节点的一维规则格子, 每个节点的顶点度为K;循环选择所有的边, 以概率p将边的一端重新连接到随机选择的节点;节点间只能有一条连接, 且不允许自连接。依据这种方法, 使得在规则图中出现了pNK/2条“捷径” (Shortcut) 。

CCBMTRC算法中, 组播树构造的过程即为构造信息传播的过程, 构造信息数据格式如图1所示。

该算法的主要思想是, 每一个节点仅保存整棵组播树的局部信息, 利用节点保存的局部拓扑信息来构造整棵组播树, 具体算法描述如下:

CCBMTRC算法可以分为两个阶段:

第1阶段:获取邻居集

(1) 网络中的每个节点周期性地向各自的直接邻居发送只包含节点ID的“心跳”数据;

(2) 节点接收到其它节点的“心跳”数据后, 将该数据中的ID记录在自己的邻居集中, 然后将该“心跳”数据丢弃;如果该ID记录已存在, 则直接将其丢弃;

(3) 运行一段时间后, 网络中每个节点都获得了自己的邻居情况, 称为邻居集;

(4) 网络中每个节点向自己的直接邻居发送自己的邻居集, 经过一段时间后, 每个节点都获得了直接邻居的邻居集。

第2阶段:转发构造信息

(1) 当一个节点以它为根生成一棵组播树时, 首先转发具有如图1所示数据格式的构造信息, 将节点ID设置为自身节点ID, 并将标志位设为“0”。接着将自身的邻居集设定为转发集;

(2) 当一个节点接收到构造信息时, 如果该构造信息是重复收到的, 则将该构造信息中的节点ID设置为自身的ID, 并将标志位设为“2”, 回传给上一跳节点;

(3) 若第一次收到该构造信息, 检查标志位, 若标志位为“0”, 则

a) 将该构造信息中的节点ID设置为自身的ID, 并将标志位设为“1”, 回传给上一跳节点;

b) 接着获取原构造信息中的节点ID, 并将转发集设定为自身的邻居集, 同时从转发集中去除原构造信息中的节点ID;

c) 依据该ID获取邻居的邻居集, 并与自身的邻居集对照, 从而获得共同的邻居, 并从转发集中去除共同的邻居;

d) 依据最终所得转发集进行构造信息的转发。

(4) 若第一次收到该构造信息, 检查标志位, 若标志位为“2”, 则从转发集中删除反馈信息中的节点ID;若标志位为“1”, 则转发集中保存反馈信息中的节点ID。

当网络中所有的节点不再转发该构造信息时, 构造信息转发过程结束, 依据最终各节点的转发集构造组播树。算法流程如图2所示。

图3中, 节点3转发构造信息时, 首先按自身的邻居集转发该构造信息到节点集[1、2、4、5];节点2收到该构造信息后发现在构造信息表中没有此构造信息, 节点2首先将该构造信息记录在自己的构造信息表中;接着按照ID=3, 从邻居的邻居集中获得节点3的邻居集[1, 2, 4, 5];从自身的邻居集[1, 3, 4, 16], 去除共同的邻居和节点3后获得最终的转发集为[16]。

在图3中, 以节点1为根节点, 依据CCBMTRC算法构造出的组播树如图4所示。

3 实验与评估

本节通过在J-Sim环境中构建仿真系统, 对Flooding、Gossip以及CCBMTRC算法进行性能评估。主要考察以下指标:

(1) 构造信息的覆盖率:当网络中一个代理发布构造信息后, 能准确接收到此构造信息的代理占整个网络代理的比率。

(2) 构造信息的重复收到数:指网络中某个代理发布一个构造信息后, 其它代理节点重复收到此构造信息的数目:

其中, grepeating表示单个代理节点重复收到某构造信息的数目, gnew表示单个节点收到新构造信息的数目。对于整个网络, 其重复收到数定义为:

其中, N表示网络中所有节点的数目。

(3) 构造信息转发次数:指当一个构造信息被发布后, 系统需要经过多少次消息转发, 才能到达网络中所有的代理, 定义如下:

其中, (gtransmitting) i表示第i个节点的转发次数。

实验从4个方面对网络性能进行仿真, 本文采用遍历算法来构造组播树, 在仿真过程中, 实现了著名的遍历算法Flooding, Gossip以及本文中提出CCBMTRC算法。

所有的仿真结果是在特定网络节点数目下, 运行10次的统计平均。图中显示的是网络中随机的一个代理节点发布一个构造信息的结果, 而在仿真实验中, 网络中的每个节点都发布一个构造信息, 再对所得结果进行平均, 因此, 最终的统计结果相当于次的统计平均, 其中为网络中的节点数目。

图5显示了在不同网络规模下传统遍历算法及本文提出的遍历算法的构造信息覆盖率, 其中Flooding和CCBMTRC算法的覆盖率接近100%, Gossip算法的覆盖率较差, 且随着网络规模的增大有恶化的趋势。

图6显示了在不同网络规模下遍历算法Flooding、Gossip和CCBMTRC的构造信息重复收到数, 可以看出Flooding算法要收到3.5个重复的构造信息, Gossip平均收到大概1.5个重复构造信息, 而CCBMTRC算法只有0.5个左右。

从图7显示了遍历算法Flooding, Gossip及CCBMTRC的构造信息转发次数。CCBMTRC算法的构造信息转发次数最少, Flooding算法最多。

对于耗时的统计结果不仅取决于算法本身的设计还取决于运行平台的性能, 所以从单个算法去查看整个耗时情况是无实际意义的。但是让所有的遍历算法在同一平台上进行运行, 来观察它们之间耗时的差异却具有实际的参考价值。

图8显示了各遍历算法的耗时情况。从图中可以看出Flooding算法的耗时随节点数目的增加呈现出指数的增长趋势, 而其他两个遍历算法的耗时跟网络规模是线性关系, 并且在相同规模的情况下, 耗时情况为:CCBMTRC算法的耗时少于Gossip算法。

4 结论

基于固定拓扑结构的Pub/Sub系统路由算法, 通常将代理网络构建为组播树。在大规模网络中, 传统的路由遍历算法会带来巨大的负载压力。本文针对传统的组播树构建算法, 提出了一种高效的基于邻居集关系的CCBMTRC构造算法, 降低了网络中的负载压力。通过理论分析与仿真实验, 表明:CCBMTRC算法在网络覆盖率、遍历耗时等性能方面都要优于传统遍历算法。

参考文献

[1]马建刚, 黄涛, 汪锦岭等. 面向大规模分布式计算发布订阅系统核心技术[J]. 软件学报. 2006.

[2]薛小平, 张思东, 张宏科等.基于内容的发布订阅系统路由算法[J].电子学报.2008.

发布订阅系统 第4篇

随着网络技术的飞速发展,各领域网络应用软件越来越复杂,系统集成的难度和风险都在大幅度提高,现在通信需要解决的关键问题就是如何将这些基于不同平台的系统连接起来,使通信更为方便。中间件技术作为架构在应用层和底层操作系统之间的桥梁能够很好地解决该问题,保证了应用软件在不同平台、不同操作系统之间的互连、互通和互操作。数据分发服务是一个用于实时分布式应用程序的网络中间件,传统的客户端/服务器( C /S) 的数据传输方式存在低效和信息传递不及时的问题[1],DDS使用发布/订阅通信模型,在数据分发服务中建立以数据为中心的发布订阅模型,并能解决高效、实时的数据分发问题,能够使分布式应用程序的参与者有效地分配数据服务,各种需要信息分发的应用都能够使用这种以数据为驱动的网络结构。在2004 年12月,OMG组织正式颁布了该规范,本文将对DDS的关键技术进行讨论和相关研究,对DDS的Qo S策略进行可靠性配置,并试验验证了其可靠性性能。通过分析提出了DDS在无线网络下的可行性观点。

1 数据分发服务

以数据为中心的发布/订阅(Data Centric Publish-Subscriber,DCPS)是DDS的核心,它提供了一个与平台无关的数据模型。使应用程序能够实时地进行信息发布,并订阅其需要的信息。作为网络中间件层可以认为是架构在应用层与传输层之间的桥梁,使系统集成从传统的硬集成转变为以数据为中心的软集成,达到信息按需获取、应用功能即插即用和系统灵活重构的目的[2]。

1. 1 DDS规范

DDS规范目的是为了简化分布式系统以能够有效地发布数据,主要应用于要求可预见性、高性能和能有效使用资源的关键领域。DDS规范有2 个层次的接口:

低层的DCPS: 将数据发布者发布的信息高效准确地传送给数据订阅者,DCPS层提供了数据发布的基础架构,是DDS规范的核心。

可选的高层DLRL: 允许将服务简单地集成到应用层[3]。DLRL层建立在DCPS之上,主要规定应用层和DCPS层之间的接口,该接口将接收到的数据进行处理并传递给应用层,经由底层DCPS层提供服务,进而简化编程工作。

1. 2 DDS特点

DDS是一种轻便的、能够提供实时信息传送的中间件产品。其特点整理如下:

1 DDS是针对网络编程的一个公开标准;

2 是一套支持发布/订阅设计思想的应用程序接口( API) ;

3 体现了以数据为中心进行结构设计的方法学;

4 是专为高性能,实时系统设计的通信中间件;

5 降低成本,用户专注于自己的设计,没有自己设计系统中所有的组件,不需要DIY. ; 降低集成成本,减少首次设计和后继测试等时间开销;

6 采用公开标准,减少了被供应商特定技术禁锢的风险;

7 可以同时使用多种传输途径,如UDPv4、UDPv6、共享内存、WAN和DTLS。

2 以数据为中心的发布/ 订阅层

作为DDS规范的核心,DCPS层为应用程序的发布/订阅数据提供了基础架构[4]。它允许:

①发布者应用程序识别即将发布的数据对象,并提供发布值给这些对象;

②订阅者应用程序识别其感兴趣的数据,并获得这些对象值;

③应用程序定义主题以及和主题关联的类型信息,创建发布者和订阅者实体并给这些实体关联Qo S策略[5],进而创建并初始化所有实体。

2. 1 基本概念

DCPS的实体包括: 域( Domain) 、域参与者( Domain Participant) 、数据写入者( Data Writer) 、发布者( Publisher) 、数据读取者( Data Reader) 、订阅者( Subscriber) 和主题( Topic) 。各个实体间的关系如图1 所示。下面将详细介绍这些实体的概念以及实体间的联系[6]。

域是DDS中特有的一个通信环境,应用程序实现互相通信的前提是在同一个域内,这一约束对隔离优化那些共享相同需求的通信有很大帮助。每个分布式系统可以由1 个或多个域组成。

数据写入者是发布者的类型化的接入器,数据写入者将数据提供给发布者,由发布者完成数据分发,发布者根据其自身的Qo S策略和数据写入者的相应的Qo S策略进行数据分发。

数据读取者负责获取订阅者接收到的数据,并传递给应用程序的DCPS层。而订阅者负责接收来自发布者的数据,然后将接收到的数据传给相应的数据读取者,从而使应用程序获得它所感兴趣的数据。数据读取者可以通过调用函数从DDS中获取数据,这为开发人员程序的开发提供了灵活性。调用的函数有2 种: take( ) 函数和read( ) 函数。在获取数据后take( ) 函数会把数据删除,而read( ) 在读取数据后不删除该数据,所以下一次依然可以读取该数据。

主题作为发布者和订阅者之间的基本连接点,2 个节点上的发布者主题和订阅者主题相匹配才能够进行通信[7]。一个主题由主题名称( Topic Name)和主题类型( Topic Type) 组成。在一个域中,Topic Name是能唯一标识主题的字符串,而Topic Type则是对在主题中数据的定义。在一个特定的域中主题必须是唯一的。在DDS框架结构中,即便2 个主题是不同的Topic Name但是相同的Topic Type,也说明这是2 个不同的主题。此外,每个主题都可关联其相应Qo S。

DDS的对称架构,使用户应用程序更加强健。没有中央服务器和中心节点,这样解决了断点失效的问题。这一点可以很好地适应无线移动网络的特点。

2. 2 模块描述

DDS提供的是一个与平台无关的数据模型,数据模型图如图2 所示。它允许应用程序对其拥有的信息进行实时的发布,并可订阅需要的信息,能够较好地处理不可靠网络通信中数据的自动发现、冗余性和可靠性等问题。DDS规范的关键之一就是使分布式应用的底层通信模型和应用程序接口( API)标准化。

以数据为中心的发布/订阅模式清晰地定义了接口和模型信息。有了清晰的接口,各个部件很容易接入。可见,DDS是模块之间成为松耦合的方式,这使得集成各个系统成为可能。

DDS作为一个高性能、支持容错的数据分发服务,也适于需要高可靠性的系统。DDS中没有任何特殊的节点。如果某个节点发生故障,其他部分能照常继续工作; 同样,如果有新的节点加入,也不会对原有的系统造成任何影响( 这同时也反应了可扩展性) 。DDS网络能够进行自愈,即使网络被劈成两半,每一半都能独立的工作; 如果网络被修复,将会自动重新连接,继续提供服务。

DDS规范提出了全局数据空间的概念,它的发布/订阅模型是通过主题将发布者和订阅者相关联的。当订阅与发布的主题相同并且相应的Qo S相匹配时,DCPS全局数据空间通知发布者和订阅者进行数据传输,即DDS规范的核心。

2. 3 DDS的Qo S策略

Qo S是指一系列可控制DDS服务行为的特性集合,它由独立的Qo S策略组成,DDS的功能依赖于Qo S的使用[8]。DDS中的所有实体都可以与Qo S策略关联,Qo S策略是DDS规范的最大亮点,DDS提供了包括数据可靠性、持久度、周期数据的超时、基于时间的过滤、数据的历史记录、数据的分区、所有权和资源限制等20 多种Qo S策略。每种Qo S策略对应一种功能,并且能在不同层次上进行配置。因此,用户可以按需求进行不同的配置,只有当发布者与订阅者Qo S策略匹配成功,二者才能进行通信。如: DEADLINE策略决定数据的有效期限,LATENCY_BUDGET策略用来优化调节数据传输时订阅者最大可接受时延,RELIABILITY策略用来保证接收数据的可靠性。TRANSPORT _ PRIORITY、PRESENTATION和DESTINATION _ ORDER策略可以解决优先级的问题,DISCOVER、USERDATA和GROUPDATA等策略可以实现DDS的发现机制,使新接入的节点能够被原组网内成员识别并进行通信。由此可以看出,DDS规范只是定义了一系列的Qo S策略和接口来控制实体间的数据交换,但并没有指定如何去实现这些服务或DDS资源的管理。因此,DDS开发者可以根据规范自由地发挥和创新[9,10]。

3 RTPS DDS互操作协议

互操作是指一种能使分布的控制系统设备通过相关信息的交换,能够协调工作,从而达到共同目标的能力。也认为是“不同平台或编程与语言之间交换和共享数据的能力”。为了实现这一目标DDS规范使用模型驱动体系结构( MDA) 方法来精确描述了以数据为中心的通信模型,该通信模型解决了如下问题[11]:

①应用程序希望如何发送和接收的数据模型;

②应用程序如何与DCPS中间件交互并指定它所希望发送和接收的数据以及Qo S需求;

③数据是如何被发送和接收;

④应用程序如何访问数据;

⑤应用层从中间件的状态获得的各种反馈。

DDS规范还包括一个映射到交互式数据语言( Interactive Data Language,IDL) 特定的平台。因此,应用程序使用DDS能够在DDS运行和重编译之间切换。DDS因此具有应用程序的可移植性。

随着在大型分布式系统采用DDS,定义一个标准的“线协议”是可取的,以允许来自多个供应商的DDS实现互操作。理想的 “DDS线协议”应该有能力利用DDS的Qo S可配置性,来优化基础传输功能。特别是,理想的线协议必须具备组播、高效,连接许多DDS Qo S的设置的能力。

4 应用软件的设计与实现

以RTI公司为例,DDS中间件是执行数据分发服务标准的一个典型代表。编写好发送数据的结构体IDL文件后,只需RTI Launcher中的Code Generator代码生成器,即可生成相应的发布/ 订阅程序[12]。

使用Code Generator代码生成器即可生成相应的发布/订阅程序,包括可以配置Qo S的XML文件,可以在此XML文件中设置自己需要的服务质量策略。高可靠传输的策略设置如表1 所示。这组策略配置了数据写入者和数据读取者的服务策略,能够有效保证数据传输的可靠性,避免丢包的发生。

为了证明DDS的可靠性传输,用8 台计算机、交换机和路由器搭建了如图3 所示的树形网络拓扑结构,在100 M网域网环境下,网络背景流量占带宽百分比分别为10% 、50% 和90% ,数据包大小分别为32 bytes、1 024 bytes和8 192 bytes,总发包数为10 000个包情况下进行实验。试验结果如表2 所示。实验验证丢包数全部为零,可以认为满足可靠性传输。在不进行可靠性设置下进行相同条件试验则偶尔会出现丢包现象。

5 结束语

DDS可以说是目前相对较先进的网络中间件,它提供一个以数据为中心的网络设计手段,是一个分布式网络的首选网络中间件,并且专注于数据通信领域; 为数据通信提供良好的系统架构和丰富的通信质量服务策略,通过Qo S设置可以使各种复杂的数据通信方式变得容易,从而为整个系统的开发节省了大量的时间和资源; 它高度的灵活性以及与生俱来的高性能就是为大系统而产生,提高了分布式系统的可扩展性,为后续复杂系统的搭建和实现提供了基础。

摘要：为了探索数据分发服务中间件(DDS)在移动自组织网络中的通信性能,深入研究了DDS的规范和特点,描述了DDS规范中以数据为中心的发布订阅层(DCPS)和数据本地重构层(DLRL)的2个接口内容,阐述了DDS数据分发的基本思想,分析了DDS的服务质量(Qo S)策略。OMG DDS定义了以数据为中心的发布/订阅模式,对分布式实时系统中数据分发、传递和接收的接口行为进行了标准化,提供一个与平台无关的数据模型,该模型能够映射到各种具体的平台和编程语言。以RTI公司的数据分发服务为例,对中间件模型的数据分发进行了分析。

关键词：数据分发服务,中间件,实时发布订阅,服务质量策略

参考文献

[1]张大海,赖兰剑,陈鼎才.DDS在分布式系统仿真中的应用[J].计算机技术与发展,2011,21(3):250-252.

[2]任昊利,李旺龙,张少扬,等.数据分发服务——以数据为中心的发布/订阅式通信[M].北京:清华大学出版社,2014:8-9.

[3]朱华勇,张庆杰,沈林成,等.分布式系统实时发布/订阅数据分发服务[M].北京:国防工业出版社,2013:16

[4]裘楷,沈栋,李娜,等.基于DCPS模型的数据分发服务DDS的研究[J].电子科技,2006(11):68-76.

[5]CASTELLOTE G P.OMG Data Distribution Service:Architectural Overview[J].IEEE Military Communications Conference,2003(1):242-247.

[6]杨传顺,钱幸存.实时数据分发系统软件的设计与实现[J].微型机与应用,2011,30(6):3-5,10.

[7]BASAGNI S,CONTI M,GLORDANO S,et al.Mobile Ad Hoc Networking[M].西安:西安交通大学出版社,2012:13-17.

[8]Real-Time Innovations,Inc.RTI Connext–Comprehensive Summary of Qo S Policies[M].U.S.A:Real-Time Innovations,Inc,2012.

[9]Real-Time Innovations,Inc.RTI Core Libraries And Utilities Qo S Reference Guide[S].U.S.A:Real-Time Innovations,Inc,2012.

[10]冯国良.基于DDS的数据分发中间件的设计与实现[D].南京:南京航空航天大学,2011:8-10.

[11]谢蓓,刘毅,曹万华,等.实时系统数据分布服务DDS技术综述[J].舰船电子工程,2006(2):16-19.

发布订阅系统 第5篇

关键词：发布订阅,消息转发,调度自动化

电网调度自动化系统中存在着大量的实时消息, 这些消息按通信节点属性可分为服务器与服务器之间消息通信和服务器与工作站之间消息通信。

服务器作为后台复杂应用的运行载体, 硬件配置普遍比较高, 服务器之间交换机普遍采用高速千兆网交换机, 因此服务器之间消息传递性能非常高, 消息延迟也非常小, 通常采用高性能的消息中间件作为通信平台。工作站作为用户与系统交互接口, 主要用于数据展示与数据交互, 硬件配置普遍较低, 且工作站与服务器之间网络配置一般为百兆网。因此工作站与服务器之间通信延迟要大很多, 消息传递性能也要低很多。

消息中间件在这2种性能差异比较大的通信环境下会降低, 原因在于, 调度自动化系统中大量传递的消息是一对多消息, 如果一个消息既发给服务器又发给工作站, 必然出现一个消息很快传递完成, 一个需要等待较长时间才能传递完成。当数据量瞬间快速增加时, 这种现象所引发的问题就更加明显, 若消息中间件采用串行发送方式, 会导致发送其他服务器的消息传递速度大幅降低;若消息中间件采用并行发送方式, 消息中间件为保证消息可靠性需要缓存发送低性能工作站的大量消息, 导致内存快速增加。

同时, 现今调度自动化系统的规模已经非常大, 服务器规模达到上百台的系统已经非常普遍, 工作站规模一般在50~100台之间, 这么多的节点如果放在同一个网段内, 系统管理的广播报文会导致整个网络性能下降, 因此系统建设时, 会把服务器和工作站划分为各自独立的网段。在不同网段下, 消息中间传递消息的复杂度会大幅增加。

本文提出一种基于发布订阅模式的消息转发服务设计, 采用优化的调度策略和消息传递机制, 通过该服务可以方便地解决服务器和工作站之间消息传递问题。

1. 发布订阅模式消息转发服务应用场景

调度自动化系统中, 需要把系统运行的异常信息、故障信息、必要的状态信息实时发布到工作站上的告警展示平台, 用户根据这些信息做出相应分析处理, 避免引起大的损失。

告警展示平台启动时, 先向消息转发服务订阅相应类别的告警信息, 之后就只关心是否接收到告警信息及告警信息的具体内容。告警展示平台不关心网络是否发生故障、服务器是否发生故障、故障何时解除、网络是否发生拥塞等底层问题。

消息转发服务接收到订阅信息后, 会持续将告警信息发布到所有订阅的工作站上, 经告警展示平台显示到用户面前。

当发生服务器故障、网络故障时, 告警信息展示平台仍然可以正常运行, 当故障解除后, 可以恢复正常运行, 中间过程不需要用户进行干预。

2. 消息转发服务客户端的设计

从应用场景中可以分析到, 客户端运行在工作站侧, 需要自动屏蔽服务端故障和网络故障, 并能在故障解除后恢复正常运行。根据这个目标, 客户端需要具备服务检测、网络监测、通信功能。客户端流程图如图1所示。

客户端先检查网络状态, 当网络发生故障时, 则等待一个周期后再检查网络状态;若网络状态正常, 则检查消息转发服务是否正常, 若消息转发服务异常, 需要重新定位下一个可用消息转发服务;若消息转发服务正常, 则读取消息;若读取到消息则继续读消息;若没有消息, 则进入开始的循环。

3. 消息转发服务端的设计

消息转发服务服务端运行在服务器侧, 接收客户端发出的订阅信息, 从消息中间件中接收消息, 并将收到的消息转发给客户端。

(1) 客户端TCP连接管理。

服务端收到客户端的订阅请求信息后, 需要将连接信息管理起来, 以便于管理和维护。连接信息包括TCP套接字、客户端IP地址、客户端端口号、连接建立时间等信息。

(2) 订阅信息管理。

服务端将客户端的订阅信息按类别进行划分, 同一类别的客户端放在一个集合中。服务端可以得知需要向消息中间件订阅哪些类型的消息, 同时当服务端从消息中间件中收到此类别的消息后, 可以快速找到需要转发此消息的客户端集合。

(3) 消息缓冲策略。

调度自动化系统中, 工作站的性能、网络拥塞差异都比较大, 因此需要为每个客户端建立一个缓冲区, 但工作站的数量可达50~200台之间, 每个客户端的消息发送缓冲区不能太大, 否则会导致服务端占用非常大的内存空间, 会对其他服务造成影响。服务端采用按消息类别建立一个比较大的组缓冲区, 每个客户端建立小的私有缓冲区, 消息先被放到组缓冲区中, 再放到每个客户端缓冲区中。组缓冲区和私有缓冲区组合的方式, 可以既适应不同工作站性能差异比较大的问题又能解决服务端占用内存空间问题。

(4) 消息发送策略。

由于TCP特性, 单条消息数据量比较小, 组条消息发送方式性能非常低, 将多条消息组包发送可以大幅提高整体性能发送性能。

(5) 发送线程调度策略。

由于工作站数据多, 采用每个工作站分配一个发送线程的策略不可取, 同时由于服务器CPU内核限制, 一个服务程序中线程的数量并不是越多越好, 线程数量越多, 线程之间调度开销增加, 反而会导致整体性能下降。因此消息转发服务根据客户端数量创建有限的发送线程, 同时同一客户发出的请求放在同一发送线程上, 这样可以将影响限制在特定工作站上, 而不会影响到其他工作站。

4. 结语

本文提出的基于发布订阅模式的消息转发服务, 客户端具备自动检测网络状态、服务状态功能, 故障解除后自动恢复通信功能, 服务端将链路信息和订阅信息分别独立进行管理, 服务端采用多级缓冲区管理策略, 组包发送消息, 发送线程按地址聚合, 性能高、易维护, 可以适应工作站之间性能差异大的环境, 同时避免服务端占用内存大的问题, 整体发送性能高, 具备隔离异常工作站的功能。目前该方法已在多个省调、地调系统中得到实际工程应用, 取得了预期效果。

参考文献

[1]姚建国, 杨胜春, 高宗和, 等.电网调度自动化系统发展趋势展望[J].电力系统自动化, 2007 (13) :7-10.

[2]徐晶, 许炜.消息中间件综述[J].计算机工程, 2005 (16) :73-76.

[3]张哲, 宋敏, 刘大昕, 等.基于发布订阅的信息集成模型[J].哈尔滨工程大学学报, 2009 (12) :73-76.

发布订阅系统 第6篇

如何保证数据库的安全性, 目前应用较多的有双机热备和群集两种方式。双机热备方式是通过镜像软件让两台服务器成为主备服务器, 通常称为纯软件方式或镜像方式。它的工作原理是通过镜像软件将数据实时复制到另一台服务器上, 所以两台服务器各存储一份数据, 如果其中一台服务器出现故障, 另一台服务器可以及时接管并继续提供服务。群集方式是通过操作系统提供的群集技术, 两台服务器作为主备服务器, 共享同一份数据 (数据保存在共享存储中) , 通常也将这种方式称为共享方式。

一双机热备方式的优缺点

1. 双机热备方式的优点

由于不采用磁盘阵列进行共享存储, 所以避免了磁盘阵列的单点故障。对于双机热备方式, 本身即是防范由于单个设备的故障导致服务中断, 但磁盘阵列恰恰又形成了一个新的单一故障点;

由于不需购买昂贵的磁盘阵列等存储设备, 可以节约成本;

由于两台服务器不需通过SCSI电缆进行连接, 所以不受距离的限制 (光纤通道的磁盘阵列也不受距离限制, 但投资额要大得多) 。可以更灵活地部署服务器, 包括通过物理位置的距离来提高安全性。

2. 双机热备方式在实际工作中的使用效果和不足

江西电视台的播出控制系统于2005年投入使用, 数据库采用了LifeKeeper4.0实现的双机热备方式, 如图1。

根据以往的使用经验, 双机热备方式对数据的安全备份具有较高的保障性。江西台在播控中心开播初期, 数据库服务器硬盘曾出现故障, 由于我们采用了双机热备方式, 所以没有造成数据丢失甚至影响到节目的正常播出。但经过一段时间的工作之后, 这种方式也暴露出了一些缺陷, 主要在以下几个方面:

第一, 双机热备方式在服务器操作系统重新启动之后首先进行硬盘镜像, 大约需要6~8小时, 在此期间主备服务器不能倒换。此外双机热备方式对硬盘的要求较为严格, 比如磁盘不能出现坏道, 否则会出现磁盘镜像中断。

第二, 服务器发生故障时, 主备切换时间比较长。在一些情况下, 镜像软件不能有效侦测一些错误的发生, 导致切换不能正常进行。

第三, 在运行中我们发现, 有时备数据库服务器出现故障也会导致主数据库服务器无法正常工作。原因可能是这样的, 在LifeKeeper的扩展镜像环境下, 当主服务器收到一个写请求时, 系统首先决定这个请求是否针对某个镜像卷。如果不是, 写操作可以完全正常地完成。如果主服务器的写请求是针对镜像卷的, 那么请求首先被送到从镜像卷去。从系统在自己的镜像卷上执行写请求后, 向主系统发送写回状态。主服务器在收到这个写回状态前不做任何写操作。当从系统返回一个成功状态时, 主系统在自己的镜像卷执行写操作, 并返回到请求方。如果从系统执行镜像卷写操作时发生错误, 那么从系统上的写操作将被中止, 主系统结束自己的镜像卷写请求, 镜像状态从Normal变为Broken。

这种机制往往会造成一种情况, 比如当两台服务器Server1 (主服务器) 和Server2 (备服务器) 在运行中, 如果出现Server2数据库服务器出现坏道或磁盘损坏等问题时, 数据将无法写入, 这种情况下, Server1在等待过程中会出现服务停顿甚至挂机。由Server2的故障导致Server1无法正常工作, 这种情况在工作中是无法令人接受的。

经过长时间的应用, 数据库服务器硬件的性能也在不断下降, 纯软件方式所暴露出来的问题也越来越突出, 有时会出现数据库服务器宕机、主备服务器无法切换等情况。针对纯软件方式所暴露出来的问题, 我们对数据库进行了重新设计。为提高系统的稳定性、可靠性, 我们决定采用服务器集群共享方式, 经过一段时间的测试及试运行, 这种数据库系统的架构运行更加稳定, 在模拟故障测试环境下主备切换未发现异常。

二群集方式的特点

服务器群集是一组协同工作并运行Microsoft Cluster Service (MSCS) 的独立服务器。如果群集中的某一台服务器由于故障或维护需要而无法使用, 资源和应用程序将转移到可用的群集节点上。服务器群集为资源和应用程序提供了高可用性、故障恢复能力、伸缩性和可管理性。

1. 特点

Windows群集技术和LifeKeeper的容错技术相比, 能提供更高层次的弹性和恢复能力。容错服务器通常使用深层硬件冗余, 虽然能在一定时间内恢复任何单一的硬件或软件错误, 但在主备倒换与状态恢复时会出现暂时的“真空”而完全失去对服务的访问能力。而当资源发生故障时, 同服务器群集连接的用户可能经历短暂的性能下降现象, 但不会完全失去对服务的访问能力。并且这些解决方案从设备资源有效利用率的角度而言, 这要比Windows群集解决方案昂贵得多, 因为必须为处于空闲状态等待错误的冗余硬件支付费用。

服务器群集功能可将多台服务器连接在一起, 从而为在该群集中运行的数据和程序提供高可用性和易管理性。采用群集共享方式较以往的LifeKeeper方式还有其他更强的优势, 表现在:

群集方式使用独立的磁盘阵列存储数据, 避免了双机热备镜像数据的时间;

群集方式可以利用服务器负载均衡功能, 提高了系统处理数据能力;

群集方式采用的软件系统均为微软软件系统, 保证了各个软件模块的兼容性;

更高的可用性。允许服务器群集中的服务和应用在硬件或软件组件故障下或在计划维护期间仍能不间断地提供服务。通过服务器群集, 资源的所有权会自动从故障服务器转移到可用的服务器。当群集中的某个系统或应用程序发生故障时, 群集软件会在可用的服务器上重新启动故障应用程序, 或者将工作从故障节点分散到剩下的节点上。在此期间, 用户只在瞬间感觉到服务的暂停, 而不会以往模式在故障切换时出现数据库长时间的访问停顿。

2. 群集方式的软件和硬件要求

(1) 软件要求

群集中所有计算机必须安装Microsoft Windows Server 2003 Enterprise Edition;

安装一个名称解析系统, 本系统需安装DNS;

建立域控制器, 所有节点必须是同一个域的成员, 同时需要一个域级账户, 此账户必须是每个节点的本地管理员组的成员。

(2) 硬件要求

群集硬件必须可以在群集服务硬件兼容性列表中找到;

两个海量存储设备控制器。一个本地系统磁盘, 用于在一个域控制器中安装本地操作系统;一个用于共享磁盘的独立外围组件互联的存储控制器;

群集中每个节点拥有两个PCI网络适配器;z共享存储设备附加到所有计算机的存储电缆。

(3) 网络要求

一个惟一的NetBIOS名称;

每个节点上两个网络接口均拥有静态IP地址。两个网络接口的作用是, 一个用于两个节点之间的心跳检测, 一个用于对外进行客户端访问。

(4) 共享磁盘要求

一个经HCL认可, 连接到所有计算机的外部磁盘存储单元。此存储单元用作群集共享磁盘;

共享磁盘所在的控制器必须不同于系统磁盘所使用的控制器;

最少500M仲裁分区;

所有节点看到附加到共享总线上磁盘, 所有共享磁盘配置为基本磁盘, 并且格式必须为NTFS。

三数据库复制技术

数据库复制技术用于在数据库服务器之间拷贝数据和其他对象 (如视图、存储过程、触发器) , 保证这些备份保持更新。数据库复制技术通过发布服务器、分发服务器和订阅服务器来实现。发布服务器是数据源所在的服务器, 分发服务器是从发布服务器收集信息, 并分发给订阅服务器。

我们根据当前的工作情况, 采用了快照复制方式, 每隔15分钟发布一次快照文件。发布服务器和分发服务器同时布置在群集服务器 (即Server服务器) 上, 订阅服务器布置第3台服务器上 (即Server3服务器) , 采用拉预订方式, 减少Server服务器的负担。

四江西台数据库系统设计方案

在新数据库设计过程中, 我们分析了实际中可能会遇到的问题:

双机热备方式可以防范单个设备故障而导致的服务中断, 但是群集方式中所用的共享磁盘阵列又形成了新的单一溃点, 目前我们采用的DS3200存储控制器没有备份, 出现故障一时间难以解决;

由于病毒等原因导致群集服务停止工作, 如何采用应急措施;

当群集中的一台服务器出现故障时, 只有一台服务器正常工作, 在故障排除期间内如何保证数据库的安全性。在这种情况下, 系统维护人员担心的是, 如果另一台服务器再出现故障如何应对, 并且即便短时间内能找到备件那也需要对故障服务器进行重新配置和系统的安装测试等;

如何有效分担系统数据库的访问连接负荷, 如在进行日志或信息检索时, 将占用数据库较大的开销。

综合以上情况, 我们采用了“2+1”架构方式, 2台数据库服务器通过群集技术互为主备, 1台数据库服务器作为第三台备份服务器, 定期从群集服务器中同步数据。通过这种架构方式, 有效解决了上面的疑问。

此设计方案不仅可以帮助我们解决上面所提到的问题, 而且具有更高的安全性。改造后的架构具有以下特点:

无单一溃点。任何一台硬件或软件的故障不会导致数据库崩溃;

群集方式中如果采用两台磁盘阵列作为冗余备份, 避免磁盘阵列的单一溃点, 但成本过高。此方式虽选用一台磁盘阵列, 增加一台服务器Server3 (实际我们只是选用了一台普通工作站) , 预算成本大大低于双磁盘阵列方式;

可将系统数据、日志查询和垫片播出等在Server3上进行, 更加有效地分担Server1和Server2数据库的负荷;

如群集方式不能对故障有效侦测进行倒换时, 发现问题后, 可以及时手动将播控机连接到Server3上继续进行工作。

本系统的相关配置为:

1. 硬盘配置

本系统采用两台IBM 3650服务器, 一台DELL计算机, 一台DS3200磁盘阵列。两台服务器分别有两块硬盘和两块千兆网卡, 每台服务器配备两块硬盘做RAID1镜像, 两块网卡分别用于心跳检测和网络访问。DS3200配置RAID3, 两个分区, 一个500M的分区用于仲裁分区, 另一个分区用于数据共享分区。

2. 软件配置

两台服务器分别安装了Window Server 2003 Enterprise Edition、DNS服务组件、域服务组件 (一台为主域控制器) 、IIS服务组件和SQL Server 2005。

3. 发布服务器、分发服务器、订阅服务器的配置

在Server和Server3中分别创建具有管理员权限的账户和密码。由于Server上安装了域控制器, 所以Server上创建的是域账户;

在Server和Server 3中将“管理工具”“服务”“Sql Server Agent”项, 在属性中改为以sqluser用户启动;

在Server的P分区 (共享存储中的数据存储区) 中, 创建文件sqlcopy, 添加账户sqluser对它的共享访问权限。此文件夹用来存放生成的快照文件;

分别在Server和Server3中, 打开SQL Server 2005Managerment Studio, 在Server中注册Server3, 在Server3中注册Server;

将Server和Server3的SQL Server 2005改为Window和Sql Server认证。

具体配置步骤不再赘述, 可参考相关资料。

原数据库系统和改造后数据库系统配置对照如表1。

五实施过程中遇到的问题及解决的方法

在群集服务器中作数据库自动备份时, 主服务器可以自动备份, 但是在转移到备数据库工作时, 自动备份无法完成。原因是SQL Server 2005 Integration Services不为故障转移群集提供特殊安装选项, 需要分别在群集的每个节点中安装Integration Services, 进行手动配置, 使其作为群集服务运行。

在配置分发服务器时, 对快照文件夹sqlcopy有特别的要求, 第一要添加sqluser对它的完全控制权限, 否者SQL Server Agent无法正确执行, 导致的结果是生成的快照文件越来越多, 无法自动删除;二是手动设置sqlcopy为共享文件夹时, 重启服务器之后, 共享属性会自动消失, 将导致快照文件无法生成。针对这种情况, 我们放弃了设置共享文件夹, 采用了分区共享方式。由于Windows操作系统中, 每个分区是默认共享的, 所以其下的所有文件夹也共享, 将快照文件夹设置为serverServerP$sqlcopy即可解决上述问题。

为了防止升级到SQL Server 2005后会出现兼容性错误, 我们在实施初期, 还定期地将SQL Server 2005的数据导出到SQL Server 2000。开始时采用的是微软公司提供的插件, 但是这种方式转换时间太长, 而且必须在命令行方式下运行, 运行期间没有任何提示, 因此很难辨别运行的状态。后来我们采用了纯数据导出导入方式, 就是将SQL Server 2000数据库中的表删除, 然后在SQL Server 2005上将每个数据库表中的数据导出到SQL Server 2000中, 这样就可以实时观察每个表转换的状态和进度。新的数据库运行一周之后, 因为系统运行没有出现任何问题, 我们就停止了这种数据导换。

在数据库管理中, 根据以往的管理经验, 我们配备了3个作业, 分别为数据库完全备份、索引优化和数据合法性检测。这三个作业每天分别在1:00和13:00自动执行, 另外在每天晚上23:00时, 还安排专人手动执行一次数据库完全备份作业, 然后将备份文件复制到Server3中作为备份。

六总结