目前，我国已经积累了相当规模的数字化空间信息资源，据初步计算，基础性地质空间信息约为1 250 GB，涉及到地质、地球物理、矿产、地质灾害、环境等领域(李超岭等，2006).但是由于运行体系的原因，零散地分布在各个地区、各个单位，造成了“信息孤岛”的局面.随着国家信息化建设脚步的加快，如何实现空间信息资源的共享成为摆在我们面前的重要课题.传统的解决方案是将数据进行集中式管理，其优点是便于共享数据的集中管理和维护(崔伟和汪诗林，2007)，从而确保数据的一致性并减小数据冗余.但是方案也存在着一些问题：一旦公共数据库由于某种原因崩溃，各个结点就不能共享彼此之间的数据.

近年来，随着计算机和网络技术的迅速发展以及分布式计算模式的日臻成熟，分布在不同地区的数据库存储同一数据的不同副本，就能较好地解决上述问题.目前，在分布式数据库领域，主要有以下方法维护数据的一致性：

(1) 数据库复制技术：包括同步复制和异步复制.同步复制是一种实时远程存取和实时更新数据的技术，虽然保证了复制环境中没有数据冲突的存在，但为了保证实时性，降低了系统处理速度，且对网络和系统资源的随时可用性依赖度较高.异步复制通过生成一个延迟事务进行数据的同步，使得各个结点副本保持松一致性，在某一时刻各结点的副本之间可能不一致(王婉菲和张志浩，2003).

(2) 基于触发器的数据同步机制：主要的功能模块包括触发器、同步数据提取、同步数据发送、同步数据接收和同步数据加载.通过同步数据提取模块、发送和接收模块以及加载模块读取更新日志表、同步数据发送表和基础数据表实现数据的同步.在该机制下，需要为每个需要同步的数据表建立相应的触发器，此外，其监控数据更新的粒度为单条数据记录，不能对多个表的数据更新进行一次同步(谈永奇等，2005).

(3) 消息队列法：目前主流采用公共数据库技术和消息队列相结合的方法实现数据的共享，也就是说将公共数据库作为数据中转站，各结点通过该媒介实现数据的共享.在该机制下，整个系统在逻辑和物理结构上都存在中心和结点的概念，是一种星线型体系结构，容易诱发数据集中式共享管理存在的问题(吴信才和吴亮，2006).

为了实现各个结点之间的数据同步共享，整合上述同步方案的优势，规避其不足，在基于“国土资源信息集成与共享平台机制”项目的基础上(徐世武等，2006)，笔者自行设计消息队列模式，提出了一种基于XML(extensible markup language) Web服务的数据同步机制.

1.   相关概念以及技术介绍

1.1   XML Web服务

XML Web服务是在Internet上进行分布式计算的基本构造块，是一种面向服务的架构的技术，通过标准的Web协议提供服务.XML Web服务的主要目标是通过使用统一标准，能够统一封装数据、消息、行为等，在无需考虑具体应用环境下让不同系统跨越平台，彼此兼容，进行无缝通信和数据共享(刘晓华，2002).而XML Web服务协议族中的核心协议——SOAP(simple object access protocol)是一个基于XML用于在Web上交换结构化的类型信息的协议(黄序鑫等，2004).SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制，SOAP会话是通过“绑定”另一个更低层的协议而实现的，而且大部分应该是绑定Http、Ftp或者Smtp协议，因此SOAP会话可以轻松地跨越防火墙等界限(陈红亮等，2006).

考虑到数据的同步涉及到不同种类的数据，在元数据服务接口的实现过程中采用了“公共接口”的概念，可动态增加需要同步的不同种类的数据(沈敏等，2005).

1.2   消息队列

消息队列在本文设计的同步机制实现过程中具有十分重要的作用，数据的同步是通过消息来驱动的.它与传统消息队列，如微软消息队列(microsoft message queue，MSMQ)具有较大的不同.MSMQ的实现原理：消息的发送者把想要发送的信息放入一个容器中(称为message)，然后把它保存至一个系统公用空间的消息队列(message queue)中，本地或者异地的消息接收程序再从该队列中取出发给它的消息进行处理.也就是说消息队列是发送和接收消息的公用存储空间(microsoft message queuing，MMQ)(时俊苓和叶丹，2008)，在实现数据同步之前，还必须实现同步消息的上传和下载，无疑增加了时间复杂度，降低了系统的同步效率(吴信才，2009).

本文自行设计的消息队列只需在本地操作，无需对消息进行上传和下载，较好的规避了普通消息队列一致存在的问题.每个结点都有一个结构相同的消息队列表用于记录同步消息的状态，每一条消息包含源结点和目标结点的IP地址信息、同步数据的信息(来自于哪一个数据表，标识数据的ID号)、消息的处理标志位(未同步、同步失败以及同步成功)、消息创建的时间和同步的操作类型(添加、删除、更新)等字段.消息处理标志位是数据同步的主要依据，因此本文也对其做了特别处理，具体如下所示：

a.“0”表示数据未处理；

b.“255”表示数据处理成功；

c.其他值(1~10，包含1和10)，表示数据处理失败的次数，若小于10，表示可以重新处理该条消息，否则就不进行处理，并在客户端进行提示.

对消息队列的操作主要包含两部分：同步前的消息录入和同步后消息状态的修改.消息的录入，通过自行设计的元数据管理工具将数据上载到本地元数据库或者是对本地元数据库中的数据进行更新和删除操作之后，在消息队列表中为相关数据的操作记录消息，并将状态设置为未同步.消息状态的更新，同步机制读取消息队列表获取未处理的消息，主动调用其他结点的元数据服务，将本地数据推送到其他结点，同步操作完成之后返回一组操作是否成功的标志，本地结点根据这组标志更新相关数据的同步状态.

在该模式下，各结点的消息队列表相互之间完全独立，只处理本地数据.由此，每个结点在物理结构层次上的地位是对等的，弱化了中心和结点的概念，实现了物理结构模式下无中心的架构，使得结点之间能够直接进行数据同步共享，而无需通过共享数据中心这个“中转站”实现数据副本的拷贝.

2.   数据同步模型

基于消息队列的设计模式，各个结点的元数据库都需包含全局路由信息以及所采集、管理的地理数据，需要同步的数据都有一个能唯一标识的字段.整个机制从横向上来看，所有结点组成一个网状结构，假设有N个结点，若某个结点上有数据的更新，那么同步机制主动调用其他N-1个结点的元数据服务实现数据的同步.从纵向上来看，各个结点的体系结构由元数据库、同步工具、元数据服务组成，同步工具获取元数据库中的同步消息，调用目标结点的元数据服务实现数据的同步共享，并根据返回的同步结果更新本地消息的状态.

如图 1所示，用A、B、C、D模拟分布式环境下的4个结点，每个结点上的同步工具间隔性的探测消息队列，一旦捕捉到新的消息，就实施数据同步.数据的同步是结点之间的数据共享，是一种无中心的架构.每个结点具有较强的独立性，摈弃了传统中心结点的做法，调动所有结点参与元数据及服务的搜索工作，同集中式搜索方式相比，将大大提高搜索效率，从而实现信息搜索方式的网格化、快速化、透明化与所有结点信息的无缝集成.

图  1  分布式地理元数据同步体系结构

Fig.  1.  Synchronization system structure of distributed geographic metadata

下载: 全尺寸图片 幻灯片

3.   数据同步技术的实现和流程

数据同步的各步骤都可以是离线模式，如果某两个结点之间出现网络断线状况，在网络连接恢复时，同步机制依然可以读取消息队列表，继续工作而不产生更新的遗漏.其具体的过程如下：

(1) 数据的本地上载.通过本地元数据管理工具将元数据导入到本地元数据库的各个相应的表当中，并同时在消息队列表中为其他结点记录消息，状态标志为“未处理”，即ChargeFlag=0.

(2) 获取路由信息.数据的同步是通过调用其他结点的服务进行的，那么首先就要获取其他结点的路由信息.通过读取本地数据库中全局路由表中的所有信息，将其存放在缓存中，当需要调用目标结点的服务时，与缓存中的路由信息进行匹配，获取目标结点的IP地址.

(3) 数据同步的设计.设置一个Timer控件，同步工具间隔性地循环读取消息队列表，按照时间顺序获取定额(设置为每次10条)的未处理或者是处理失败次数小于10的消息.根据获取消息中的数据接收表的标识，进行相应数据的添加、删除和更新等同步操作，各操作的具体内容如下：

当操作类型为“添加”，即OpType=1时，根据本条消息的IDList(同步数据的id列表)，从相应的数据表中获取数据，封装成XML文件，主动调用目标结点的元数据服务InsertDataInfo，将数据插入到目标结点的相应数据表中，此时返回插入是否成功的标志.若全部插入成功，则将本地消息队列表中相应消息的状态ChargeFlag=255.若有一条插入失败，就按照处理失败的次数修改对应的那条消息的ChargeFlag的值(处理失败的次数超过10次，视为由于某种原因不能处理，同时在日志中记录处理次数超过10次的消息).当下一次同步过程启动，重新读取消息队列表时，继续对这条消息进行处理，此时，对已插入的数据不进行操作，直接返回true.

当操作类型为“删除”，即OpType=2时，主动调用目标结点的元数据服务DeleteDataInfo，根据本条消息的IDList中的值，删除目标结点下相应数据表中相应的数据.首先查询该表中是否存在对应的数据，如果没有，返回false；否则，继续操作.最后返回本条消息所包含全部数据操作的标志，如果全部删除成功，则改变本地消息队列表中相应的消息的状态ChargeFlag=255，否则，就按照处理失败的次数修改对应的那条消息的ChargeFlag的值(处理失败的次数超过10次，视为由于某种原因不能处理，同时在日志中记录处理次数超过10次的消息).当下一次同步过程启动，重新读取消息队列表时，对这条消息继续进行处理.

当操作类型为“更新”，即OpType=3时，根据本条消息的IDList，从数据库相应的数据表中获取数据，封装成XML文件，主动调用目标结点的元数据服务UpdateDataInfo，更新目标结点的相应数据表中的相应数据.首先查询该表中是否存在对应的数据，若无，返回false，否则，继续操作.最后要返回本条消息所包含全部数据的操作标志，如果全部更新成功，就改变本地消息队列表中相应的消息状态ChargeFlag=255.如果有一条没有更新成功，就按照处理失败的次数修改对应的那条消息的ChargeFlag的值(处理失败的次数超过10次，视为由于某种原因不能处理，同时在日志中记录处理次数超过10次的消息).当下一次同步过程启动，重新读取消息队列表时，对这条消息继续进行处理.

在同步机制的实现过程当中，还需考虑到以下问题：某次读取的消息数组当中，若有两条以上的消息涉及到同一数据的操作，可能会出现同步紊乱的情况，具体分析如下：

对某一条数据实行先插入，后删除，再插入的操作.假设按照时间顺序产生的3条消息的id分别是100、101、102.某次同步操作，同步工具依次处理3条消息，id=100、101的两条消息处理失败，id=102的消息处理成功，第二次同步过程启动时，id=100、101的两条消息依旧会被处理，若该两条消息也处理成功，那么源结点的元数据库和目标结点的元数据库中包含的数据并不一致.同样地，当对某条数据实行先更新，后删除，再插入的操作的时候，也会出现类似的同步紊乱.

为了避免这种问题，可以采用以下解决方案：某次同步操作，同步工具所读取的消息数组中，若有两条以上的消息所包含的DesNode(目标结点信息)和DesTab(同步的数据表)是相同的，表明是对同一个结点的同一个数据表进行数据同步，那么在这样的同步过程当中，当第一条消息处理失败了，就不再处理剩余的信息，否则继续处理，保证同步过程按照消息的时间顺序进行处理，避免出现同步紊乱的情况.

如图 2所示，分布式地理元数据同步机制的系统流程图，其主要流程介绍如下：

图  2  分布式地理元数据同步机制流程

Fig.  2.  Synchronization mechanism of distributed geographic metadata

下载: 全尺寸图片 幻灯片

(1) 通过元数据管理工具将本地元数据上载到本地数据库或者是对元数据库中的数据进行删除、更新操作，之后在消息队列表中写消息，并设置消息的状态为“未处理”，即ChargeFlag=0；

(2) 同步工具从消息队列表中读取未处理或者处理失败次数小于10的消息，根据消息包含的内容从相应的数据表中获取数据；

(3) 根据数据的操作类型，调用目标结点的元数据服务，进行数据的同步；

(4) 根据返回的数据操作的标志，修改消息队列表中对应消息的状态.

4.   总结

本文在基于“国土资源信息集成与共享平台机制”项目的基础上，提出了一种基于Web服务的数据同步机制，实现了分布式环境下地理元数据的同步共享，保证了每个结点较高的独立性和自治性，每个结点只需读取本地消息队列表就可进行数据的同步更新，无需接收其他结点的同步消息.本设计通过自行设计消息队列，利用消息驱动和远程调用元数据服务的方式实现了各个结点之间的数据同步，较好地保证了数据同步的一致性.