订阅—发布模式

订阅—发布模式（精选5篇）

订阅—发布模式 第1篇

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

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

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

消息中间件在这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.

订阅—发布模式 第2篇

现场总线通信方式在变电站自动化系统中应用获得了巨大的成功, 但其在速度、兼容性以及互操作性等方面的缺陷始终制约着它的发展。随着特高压技术以及计算机技术和通信技术的发展, 系统网络化和体系开放性成为变电站自动化系统发展的趋势。基于IEC61850标准的综自变, 数字变和智能变电站迅速发展, 以太网技术顺应这种趋势, 正越来越多的被引入变电站自动化系统过程层的采集、测量单元和间隔层的保护、控制单元中, 构成基于网络控制的分布式变电站自动化系统。

1 基于IEC61850的变电站自动化系统结构和数据流

1.1 系统结构的划分

IEC61850标准提出了变电站内信息分层的概念, 按照所要完成的测量、保护、控制从逻辑上将系统分为三层, 即变电站层、间隔层和过程层。各层之间的通信方式全部采用以太网方式, 实现了变电站内通信“一网到底”。为了保证数据传输高可靠性, 采用双机双网冗余配置, 从系统结构看, 重要的自动化设备都直接接入以太网, 从而减少了通信处理及转换的中间环节, 增加了系统的可靠性。

1.2 自动化系统网络通信数据流分析

数据流是指在给定的时间内的数据交换, 这种数据交换可能是连续的或由事件驱动的, 实时应用程序必须处理不同种类的数据流。为了满足变电站自动化系统对于实时性的要求, 必须理解这些数据的类型和属性。在基于IEC61850的变电站中, 数据流可以归纳为信号量、命令量、状态量、事件量、查询量5种类型。

2 以太网通信协议讨论

2.1 TCP和UDP协议

以太网本质上是物理层和数据链路层符合IEEE802.3标准的一种总线型网络, 主要通信协议有TCP/IP、SNA、XNS等, 其中TCP/IP参考模型已经成为事实上的业界标准。

位于TCP/IP模型传输层上的协议有传输控制协议TCP和用户数据报协议UDP, 由于TCP协议需要建立握手信息, 仅支持点对点的通信, 而变电站设备间状态信息和互锁信息的交换, 则属于异步对等以及点对多点通信模式, 采用TCP是无法有效实现的。而且TCP不能保证数据在有限的、确定的时间期限内到达接收方, 如果接收方没有收到数据, TCP协议就会控制重发, 同时阻塞应用程序进程直到收到数据或发生超时。换句话说, 在数据的接收方必须在确定的时间范围内收到数据的情况下, 就不能使用TCP协议了, 而UDP是一种无连接的服务, 不需要建立握手信息, 速度快, 实时性好, 系统开销小且具有多播组播的能力, 采用UDP协议的数据报结构简单, 便于组织, 但数据容量较大时可靠性不能得到保证。

2.2 RTPS通信模型

RTPS通信模型是为了适应实时通信, 在继承Publish Subscribe模型优点的基础又进行了必要的扩展而来的。相对传统的发布订阅模式, RTPS提供了实时通信服务, 如传送时间控制、可靠性控制、可变带宽控制、容错能力和效率控制等。它定义了实时发布和定购的参数和特性, 通过设置这些参数, RTPS模型可以支持所有的数据流类型。RTPS模型发布方发布一个Publication, 每个Publication由Topic和Type作唯一标志, Publication无源地址位与目标地址位, 要接收数据仅需要识别Topic和Type。其模型本身的灵活性使得能够轻而易举地用它实现复杂的多对多, 多对一的应用。模型采用事件驱动, 对发送者, 当其准备好后就可以发送数据, 对定购方来说, 它将阻塞进程直到接收到数据。

3 变电站自动化系统RTPS通信模型实现

3.1 报文传输实时性和可靠性实现

为了保证多种类型报文的实时性和可靠性, RTPS为应用程序的Publish输出端引入5个参数, 即在输出数据流中插入数据流标示TOPIC, 标志数据类型TYPE, 数据序列号SEQ, 数据版本号V＿SEQ, 及数据存活时间DUR, 输入端Subscribe引入插入超时时间TIMEOUT, 不接收新数据的时间段MINISEPRATION及等待时间DEADLINE3个参数和数据序列号校验功能。

通过设定TOPIC和TYPE参数, 使RTPS模型可以方便地将站内各类数据流加以区分。每一个序列号SEQ赋予一个版本号V＿SEQ。SEQ用于将发送的数据按序编号以检测其是否丢失或重复, V＿SEQ使用SEQ初始化时的系统时标定义, 用于重新设定发送数据的SEQ, 例如当发送数据的SEQ初始化时产生V＿SEQ, 如果发布节点关闭后又重新启动时, SEQ会重新设定, 这时接收节点可能会误认为SEQ丢失, 为了防止这种情况发生, 为发送数据的SEQ加上V＿SEQ, 用来表示开始了新一轮数据发送, SEQ重新开始计数。

通过TYPE设置可以标明所发布的数据是否需要进行可靠性检查, 如需要, 则检查数据的传输序号和序列版本号, 否则, 直接接收数据并进行处理。MINISEPARATION参数定义接收方不接收新的数据的时间段, 防止发送方发送过快而导致接收方缓冲区溢出的情况, 保证了既有设备因硬件配置差别较大而导致的稳定性。如果需要数据在某个确定的时间内到达, 则可以用DEADLINE参数来处理, 超过DEADLINE的数据将被丢弃或重传。这样就保证了保护和监控系统不断变化的状态信息采样的实时性。

3.2 报文传输优先级实现

为了人为控制报文的优先级别, Publish输出端引入PRI参数, 将数据由低到高分为7个不同的优先级别。发送方在发送数据前首先要根据要发送数据的实时性分配1-7范围内的优先级, 然后将该数据传到输出缓冲区等待发送, 如果没有优先级要求则PRI设为0;对于接收方首先检查接收数据的PRI, 如果优先级在1-7的范围内, 则节点根据指定的优先级接收数据并传送给应用程序。如果节点接收到优先级为0的数据, 则使用最低的优先级处理。

PRI参数引入有效解决了系统中优先级问题, 比如实时性能最高的保护命令, 该命令发出, 其他所有数据自动被屏蔽, 等候处理完该命令后才能继续处理其他数据。在保证了优先级的情况下, 可靠性必然会受到影响。目前国内在220kV及以上的变电站可靠性要求较高, 采用备用节点来提高系统的可靠性, 这两个节点可以发布相同类型的数据, 但是备用节点的优先级比主节点的优先级低, 并且每个节点采用DUR参数指定数据的有效时间。当节点接收到TYPE相同的数据时, 如果已经存在一个高优先级的数据, 并且处于DUR参数指定的有效时间内, 则只处理优先级高的数据, 丢弃优先级低的数据, 如果主节点停止发送数据, 则备用节点可以正常接收。

通过在应用中不断改进和完善, 实时发布订阅通信模型已经很好的解决了分布式变电站智能电子设备之间的实时性、可靠性及优先级的机制, 克服了以太网在实时通信中的诸多弊病, 是变电站自动化系统通信的一个较好解决方案。随着变电站智能电子设备增多, 相互之间的联系也越来越复杂, 自动化通信系统的开放性, 互操作性等都是今后丞待进一步解决的问题。

摘要：介绍了实时发布订阅通信模式在基于IEC61850的变电站自动化系统的应用, 结合IEC61850标准, 分析了分布式变电站系统结构, 自动化网络通信系统数据流的特点以及以太网在变电站自动化系统的实时性和可靠性要求, 简述了实时发布订阅RTPS模型的基本概念和特点, 以及基于此模型的变电站自动化系统报文传输实时性、可靠性和优先级的解决方案。

关键词：IEC61850标准,以太网,通信协议,数据流,RTPS模型

参考文献

[1]陈轶玮.数字化变电站实用化研究[D].浙江大学, 2007.

[2]张沛超、高翔.数字化变电站系统结构[J].电网技术, 2006, 24.

[3]刘贺锋.基于RTPS的实时通讯中间件[D].西南交通大学, 2002.

订阅—发布模式 第3篇

发布/订阅模型是分布式网络中一种有效的通讯机制。其异步、多点通讯的特点很好地满足了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 结论

订阅—发布模式 第4篇

1.1发布/订阅技术

Internet的广泛应用使得传统的基于请求/应答的点对点的同步通信不能满足大规模的动态分布式应用环境。发布/订阅(Publish/Subscribe,Pub/Sub)模型是支持大规模分布式系统的有效通信方式。

如图1所示,信息的消费者称为订阅者(subscriber), 信息的生产者称为发布者(publisher),发布者和订阅者统称为客户端。订阅者发出一个订阅条件,表示对系统中某个或者某类信息感兴趣;如果不再感兴趣, 也可以取消订阅。这些信息通常称为事件(event),事件通过通知(notify)来提交。发布者将事件发送至事件管理器,然后由事件管理器对这些事件进行内部处理,保证将发布者发布的事件及时、可靠地传送给所有对之感兴趣的订阅者。这种匿名的基于事件的交互模型支持发布者和订阅者之间的非耦合、多对多通信,在时间、空间和流程方面完全非耦合[1]。

1.2 PKI原理

PKI(Public Key Infrastructure的缩写)公开密钥基础设施体系结构[2,3],即:采用证书管理公钥,通过第三方的可信机构CA,把用户的公钥和用户的其他标识信息(如名称、E-mail、身份证号等)捆绑在一起, 在Internet网上验证用户的身份。PKI主要目的是在开放网络环境中管理、制作并使用数字证书,其中最主要的安全技术包括两个方面:公钥加密技术和数字签名技术。其技术核心是一对密钥,其中任何一个密钥加密的数据,只能由另外一个密钥解密。将其中的一个密钥公开,称为“公开密钥”;另外一个密钥由密钥持有人专用,称为“私有密钥”。加密时将消息用公开密钥加密,只有相应的私有密钥持有人才能解密, 因此,该消息成为私有密钥持有人的秘密。签名时将消息用私有密钥加密,只有相应的公开密钥才能解密,因此,可以证明该消息来自私有密钥持有人[4]。

1.3 CA相关原理

数字证书就是互联网通讯中标志通讯各方身份信息的一系列数据,提供了一种验证身份的方式,其作用类似于司机的驾驶执照或日常生活中的身份证。 它是由一个权威机构———CA机构,又称为证书授权(Certificate Authority)中心发行,人们可以在网上用它来识别对方的身份。数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。公开密钥技术解决了密钥发布的管理问题,商户可以公开其公开密钥,而保留其私有密钥。购物者可以用人人皆知的公开密钥对发送的信息进行加密,安全地传送给商户,然后由商户用自己的私有密钥进行解密[5]。

1.4 PKI/CA技术与发布/订阅技术的结合

如上所述,发布/订阅技术往往采用异步方式进行信息交换,信息订阅者与发布者,通过发布/订阅中间件进行通讯。而PKI/CA技术往往应用于传统客户机/服务器的结构。在将PKI/CA技术应用于发布/订阅系统的过程中,发布/订阅中间件为服务器端,信息的订阅者和发布者都可以视为发布/订阅中间件的客户端。

如图2所示,通过将PKI/CA技术与发布/订阅系统相结合,CA证书颁布系统直接运行在发布/订阅服务器之上,可以实现安全的发布/订阅系统。安全的发布/订阅系统的工作流程如下:

(1)发布/订阅服务器将证书颁布给信息订阅者和信息发布者;

(2)信息订阅者和信息发布者向服务器提交证书信息;

(3)服务器验证证书,并通过验证(如果不通过验证则直接结束);

(4)信息订阅者通过加密通道将订阅信息提交给服务器;

(5)信息发布者通过加密通道发布信息;

(6)发布/订阅服务器对收到的订阅信息和发布进行匹配;

(7)如果匹配成功,服务器将匹配结果(发布的信息)通过加密通道推送给信息订阅者。

在房产交易平台中,将安全技术引入到发布/订阅平台中,可以有效地防止未经授权的恶意用户进入系统滥发数据、攻击系统、发布虚假房源信息;防止用户与一个未经授权的黑中介,发生交易,造成经济损失;防止在用户交易过程中窃取房产交易信息和商业秘密。

2系统概述

针对房产中介行业中存在的房产信息本地化管理、房产信息共享等需求,开发了房产交易平台系统, 该系统以房产中介经纪人为服务对象提供了一系列管理功能,并且实现网络数据同步功能。它不是通过网站对信息进行静态整合,而是通过发布/订阅机制进行动态整合,从而实现信息在提供方和需求方之间的有效流动。房产中介经纪人通过客户端软件,设定自己的求租和买房需求后与服务器通讯,如有可用信息则显示,如无匹配信息则可以进行订阅,在以后有相关信息或者信息更新时以邮件或手机方式进行通知。客户端的订阅软件从发布服务器上获取所需信息,发布服务器负责对信息整理收集并组织分析。

3结构设计

本平台由3个部分组成:房产信息集成平台、房产中介客户端和个人用户管理,如图3所示。房产信息集成平台将个人用户的订阅信息与房产中介发布的房产信息进行匹配,并实现信息向个人用户的推送。房产信息集成平台中集成了证书管理模块,可向房产中介颁布证书。房产中介通过提交证书实现安全认证,获得确认后可以在平台上发布房产信息,发布的信息在网络传输过程中通过PKI技术进行加密。个人用户可通过网页直接登录至房产信息平台,对所需房源进行查询和订阅。房产信息通过房产信息集成平台在不同房产中介间共享,客户信息则不共享,分别由各自所属房产中介管理。

3.1房产信息集成平台设计

本平台采用模块化设计,由界面操作模块、发布/ 订阅管理模块、用户数据管理模块、证书管理模块、安全加密模块和网络通信模块组成。这些模块的主要功能描述如下:

界面操作模块:该模块提供给房产信息集成平台中的管理员使用,为管理员提供系统运行状态、用户信息、数据管理、证书管理的接口。

发布/订阅管理模块:该模块实现对来自用户的查询请求的执行以及对发布信息、订阅信息的本地保存。该模块通过与用户数据管理模块交互完成用户房源查询;房产集成平台的服务器端程序负责接收客户端传送过来的订阅信息并按照用户订阅的内容对数据库进行检索匹配得到用户想要的房源记录,并且通过网络通信模块将结果推送给个人用户。

用户数据管理模块:该模块负责维护房产中介和普通用户的账户信息。同时管理中介提交的房产信息数据,以供发布/订阅管理模块使用。

证书管理模块:该模块负责管理房产中介的证书信息,包括证书的生成、维护、验证,证书有效期管理等。中介通过提交安全证书,通过平台认证,从而得到发布房源的权限。对中介身份进行必要的审核,可以防止发布虚假信息,滥发信息等现象的出现。

安全加密模块:该模块实现房产中介的身份鉴别,访问控制,实现平台数据的安全加密保护,提供加密传输的通道。

网络通信模块:该模块实现房产中介交易平台和房产中介,普通用户之间的通信传输。房产中介交易平台和房产中介之间基于安全加密认证,实现加密的网络通讯。交易平台和用户之间实现普通的网络传输。中介对数据库的各项操作都需要通过网络传送到房产信息集成平台,然后由平台的服务器程序执行操作,并返回操作结果。个人用户对房源的每一条订阅信息都需要通过网络传送到房产集成平台上,对于匹配的房产记录,平台需要通过网络把它们发送回个人用户。

3.2房产中介客户端设计

房产中介客户端采用模块化设计,由发布管理、 用户数据管理、安全加密和网络通信模块组成。这些模块的主要功能描述如下:

发布管理模块:该模块实现将客户的房产信息发布至房产信息集成平台。

用户数据管理模块:该模块负责维护录入至本房产中介数据库的房源信息和客户信息。不同于房源信息,客户信息不能共享于不同的房产中介。客户包括两类,一类是提供房源的房主,一类是需要租房的房客。对客户本身的信息需要进行管理,包括显示、添加、修改以及删除等。此外,需要建立房主与房源、房客与租房查询条件之间的关联关系。当房客提出的查询条件符合要求时,需要自动给出提示信息。客户信息存储在本中介数据库中,并且可以同房产集成平台数据库进行同步,由此满足业务员异地办公的要求。 连接房产集成平台服务器,可以按照时间检索的方式返回可以更新的房源的数量。可以显示历史查询条件记录,直接使用记录进行远程查询,并且返回可以更新的房源信息。

安全加密模块:该模块确认房产中介的身份,访问控制,实现平台数据的安全加密保护,提供加密传输的通道。

网络通通信模块:该模块实现房产中介和房产中介交易平台间基于安全加密认证的通信传输。中介对数据库的各项操作都需要通过网络传送到房产信息集成平台,然后由平台的服务器程序执行相应操作, 并返回操作结果。

3.3个人客户设计

个人客户管理也采用模块化设计,由数据查询模块、订阅管理模块和网络通信模块组成。这些模块的主要功能描述如下:

数据查询模块:该模块通过网络访问房产集成平台的数据库,个人用户输入查询条件搜索目前系统中已有房源,如有匹配房源存在,相应的房源信息以列表的形式显示给个人客户,用户选择逐条房源,可以看到房源的相关信息。并且数据库中需要记录个人客户的搜索历史或者搜索习惯,以方便在下次用户使用搜索操作时,直接显示个人客户上次的搜索条件,以简化用户的使用。

订阅管理模块:该模块实现向房产集成平台订阅符合个人用户需求的房源信息。个人用户在提交查询请求的同时可以选择进行该查询所对应的订阅,每一个用户可以在服务器端保留最多3个房源订阅,服务器为每个订阅最多保存1个月。用户下次登录的时候,服务器根据存储的订阅请求为用户进行检索,如果存在结果,则通过界面通知用户。用户可以查看、修改和删除自己当前有效的订阅,订阅对应的信息到达后需要在界面上通知用户。

网络通信模块:该模块实现个人用户和房产中介交易平台之间的通信传输。个人用户对房源的每一条订阅信息都需要通过网络传送到房产集成平台上,对于匹配的房产记录,平台需要通过网络把它们发送回个人用户。

摘要：文章借鉴了发布/订阅技术的思想,设计了房产信息集成平台。它提供了松散耦合的数据集成方式,帮助使用者在浩瀚的信息中根据自身的需求筛选有价值的信息,提升了信息的有效性和准确性。同时,在用户认证及信息网络传输的过程中使用PKI等加密技术,可以很好地满足身份认证、完整性保护及不可抵赖验证等信息安全需求。

订阅—发布模式 第5篇

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

一双机热备方式的优缺点

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中作为备份。

六总结