空管实时运行系统数据库架构的设计与应用

曹烨琇，陈晓建，李学忠

0 引言

空中交通管制是对航空器的空中活动进行管理和控制的业务，包括空中交通管制业务、飞行情报和告警业务。它的任务是；防止航空器相撞，防止机场及其附近空域内的航空器同障碍物相撞；维护空中交通秩序，保障空中交通畅通，保证飞行安全和提高飞行效率。随着飞行活动的频繁增加、飞行航程的加长、载客量的大幅增加以及飞行速度的增加，迫使空管系统快速发展，渐渐从单一系统发展成综合性服务系统，并且系统所覆盖的地域也由单一城市向地区型发展。

在信息化系统变迁的过程中，传统的系统设计架构已难以适应空管大型运行系统的设计要求，其中数据库架构直接影响到应用系统的整体设计；常用的集中式数据库系统无法满足各地区或各部门系统地域自治能力的需求，而传统分布式数据库系统又受网络带宽限制较难做到数据实时同步应用实时响应以及数据一致性的要求，因此我们可以通过寻求各种数据库架构模式各自的架构特点，并结合行业本身的数据处理特点，设计出一套科学、合理的数据库架构方案，并通过实践应用以验证其可行性。

1 问题的出

在整个航班生命周期从航班的计划编制→计划实施→统计的过程中，系统涉及到了不同部门的协调、不同的数据其处理标准也不相同，某些数据对一致性要求较高、某些数据实时性较强；并且系统的覆盖范围及网络带宽的限制，这些都给数据库架构的设计带来了不少难度，以下提出一些具体问题是在整个架构设计时需要考虑和解决的：

（1）区子系统具有自治能力，甚至自治能力能达到某一客户端，使核心系统或子系统在发生故障瞬间能保证终端独立运行，完成当时的飞行指挥，保证飞行安全。

（2）与网络带宽限制之间的矛盾，在带宽只有1M或更低的前提下如何提高系统的响应能力与数据库的设计密不可分。

（3）致性要求，例如在航班计划处理阶段，由于航班还未执行，系统对其相关信息处理实时性要求并不高，但该计划信息必须是唯一的，当数据被多头修改过后数据如何同步、系统如何仲裁唯一性，以保证数据的一致性是我们需要考虑的问题。

（4）据存储与数据高效检索之间的矛盾。

2 模型的设计

2.1 传统数据库架构的特点

集中式数据库系统

（1）一致性；如果由一组中央程序控制所有数据项，则容易避免数据的多重目录一多重目录可能导致不一致性。

（2）可检索性；控制程序可保证所有的数据项是标准格式的，对信息的访问也是标准的，而且是兼容格式，这样任何数据都不可能轻易丢失。

（3）数据的独立性；用户应用程序应不受数据存储和访问方式变化的影响，这种功能在中央程序控制所有内部级以及所有概念级数据存储和所有概念级用户接口时，比较容易实现。

2.2 分布式数据库系统

（1）分布性；它可以解决组织机构分散而数据需要相互联系的问题。比如银行系统，总行与各分行处于不同的城市或城市中的各个地区，在业务上它们需要处理各自的数据，也需要彼此之间的交换和处理，这就需要分布式的系统。

（2）扩展性；如果一个组织机构需要增加新的相对自主的组织单位来扩充机构，则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充。

（3）可靠性；相等规模的分布式数据库系统在出现故障的几率上不会比集中式数据库系统低，但由于其故障的影响仅限于局部数据应用，因此就整个系统来讲它的可靠性是比较高的。

2.3 新架构的设计

随着计算机应用领域的不断扩大，为了满足数据库的规模变化和数据库查询复杂度要求及各个行业的特殊业务要求，基于传统数据库系统的发展，不断有新的数据库技术涌现，例如：实时数据库、内存数据库、嵌入式数据库、并行数据库等；我们希望能够借鉴不同数据库技术特点和设计思路，设计出满足空管实时生产运行系统要求的数据库架构。

考虑到某些数据实时一致共享的需求，在系统设计中，结合集中式数据库和分布式数据库各自的特点，采用共享数据集中写入，实时分发到各分节点的架构模式。

如下图2-1所示，中心节点在更新共享数据时，将通过消息传递机制直接写入共享数据库；共享数据库数据实时被复制到本地在线数据库分节点；系统需要使用共享数据时直接从本地在线数据库中读取。这种构架模式，能够保证远程共享数据库短暂中断时，系统仍可以利用本地数据继续工作。中心共享数据库恢复时，存在于信息交换平台队列中的数据将写入共享数据，实现业务的不间断运行。并且为满足海量数据的存储及提高在线系统的响应能力，则引入了数据仓库的概念，系统周期性地将在线数据库数据移入数据仓库作为历史数据，一方面为数据分析统计和数据挖掘提供数据源，另一方面限制了在线数据库的容量，提高数据库的检索效率。另外，在每个客户端的本地设置了本地数据库，通常保存支持日常的业务数据，平时在访问服务端正常的情况下，本地数据库是不参与系统主体流程计算的，一旦服务端发生故障或通信出现问题的瞬间，客户端还能由本地数据库作为支持，使得每个客户端也具有独立地自治能力以保证业务的联系性。

图2-1 数据库架构模型图

3 应用的实现

3.1 系统总体架构设计

根据以上的模型设计，我们在实际运行系统中进行了充分的应用和实践，该系统总体架构设计如图3-1所示，其中：

将各节点需要一致使用的共享数据独立出来，形成共享数据库。共享数据库部署在空管中心，当系统需要修改共享数据时，应用直接修改共享数据库。共享数据库将实时分发到各节点的在线数据库中。保障本地在线实时可读取。共享数据库数据主要包括基础元数据和共享的常变数据如航班计划等数据。

在线数据库是系统生产过程中最主要的数据库，存储基本元数据和在线处理实时数据。在线数据库要求响应快，数据集合小，便以在线实时响应。在选择存储时考虑高性能快速反应存储如固态存储。在线数据库的数据将被实时同步到数据仓库中，在线数据库数据中的非基础数据只保留设定的时间长度。

数据仓库在线数据库的近线积累，主要用于分析查询报表等经营性数据挖掘应用。以隔离这些应用对在线实时应用的影响。也便于统一部署智能数据挖掘分析工具包。数据库仓库的数据经过一定周期后，生产业务数据将不再使用此时将被数据生命周期管理工具进行磁带归档。以隔离出生产系统，提高生产系统的性能，减小高性能存储的规模，降低成本。

本地数据库作为一种应急手段，通常可以使用文本文件或规模较小的关系型数据库（如：access），数据量不宜过大，可根据业务特点保存支持本地客户端运行 1～2天的业务数据，在每天业务非繁忙期间更新，以避免与客户端在繁忙时期争抢资源，使得用户体验下降。

图3-1 系统总体架构设计图

3.2 数据同步方式

基本设计原则（如下图3-2）：

✧共享数据库与在线数据库、在线数据库与近线数据、在线数据库与本地数据库之间数据同步在应用层完成

✧近线数据与离线数据之间数据同步在物理层完成

图3-2 数据库同步示意图

传统数据同步基本采用物理层表复制方式来完成，其对网络带宽要求较高（通常千兆网络以上），一旦有“脏”数据影响系统应用时，同样被复制的数据也会影响应用；而在应用层解决数据库之间的数据同步，其优点在于实时性强、带宽要求低、可靠传输、配置灵活、避免“脏”数据传染等。

在本系统中主要采用中间件技术在应用层完成数据库之间的同步，图3-3展示了基于MB/MQ中间件交换模式数据库同步的工作原理。数据由源数据库端应用程序通过MQ的管理器QM，与MB的Adapter建立MQ通道进行数据接入。MB通过对消息内容的Mapping和交换路径的Routing，动态引接由源QM到目的QM之间的数据交换通路，并可利用MQ Cluster功能实现消息队列的群集，达到数据交换的纵向扩展和负载均衡。MB的接入方式不仅局限于MQ（其它比如文件、web service），为各种数据源协议和格式提供了异构接入便利。数据接入后，作为消息交换总线的MB根据源队列、目的队列和数据信息的运行时状况，进行源与目的地之间的映射，以及动态路径搜索，最终再次通过 MQ通道接入目的QM，从而形成一个消息交换的完整路由，目的端应用程序读取相应的数据后写入目的数据库。

图3-3 数据库同步原理示意图

MB起到运行时消息路由的作用，在数据源和数据目的系统之间动态建立可靠的消息传输通路，并实现不同格式数据之间的转换功能。由于MQ可采用cluster的方式，因此在繁忙的业务系统之间可以实现负载均衡，并达到高可用性。系统节点可通过MQ/MB平台更新共享数据，将信息写入共享数据库；并且三类数据库（共享、在线、仓库）之间的数据读写和同步也通过MQ/MB数据交换平台来完成，从达到数据流动的稳定、可靠和安全。

4 系统仿真结果分析

4.1 仿真系统的结构

根据上述本系统的模型设计和应用设计，通过搭建系统仿真平台，以验证数据库架构的可行性。系统硬件架构如下图4-1所示，整个仿真系统通过一台千兆交换机，分别连接了4台服务器和2台用户终端，并在这些服务器/终端设备上分别部署了相应的数据库及应用软件，为下一阶段的测试调试提供环境基础。软件部署见表4-2。

图4-1 仿真系统硬件结构示意图

表4-2 软件部署表

4.2 调试方案

以空管行业处理航班计划过程为例，其正常处理流程为：数据中心处理长期航班计划（除当日）通过共享数据库统一发布，各分节点处理当日航班计划，读写操作仅与本地在线数据库有关，但处理结果需及时回送于数据中心；数据统计功能各地均通过本地数据仓库实现。以下将模拟若干故障发生情况，预期达到验证效果应为：任何故障均不能影响当时的管制安全，确保业务的连续性。

调试案例1：

案例描述：中断数据中心数据共享服务器网线“C”（如图5-1示）连接，共享数据库数据无法发布至分节点本地在线数据库；过若干时间恢复连接。

预期结果：①故障发生时检查分节点端数据库无新发布数据；②故障发生时检查数据中心数据共享服务器上，MB/MQ软件队列中有待发布消息堆积；③故障恢复后，检查分节点端数据库有新发布数据并数据无缺失；④故障发生期间未影响分节点客户端操作。

调试案例2：

案例描述：中断数据中心应用服务器网线“A”（如图5-1示）连接，共享数据库数据无法通过数据中心应用服务器发布至分节点本地在线数据库；过若干时间恢复连接。

预期结果：①故障发生时检查分节点端数据库无新发布数据；②故障发生时检查数据中心数据共享服务器上MB/MQ软件队列中有待发布消息堆积，同时分节点应用服务器上MB/MQ软件队列中有待发布消息堆积；③故障恢复后检查分节点端数据库有新发布数据并数据无缺失；④故障发生期间未影响分节点客户端操作。

调试案例3：

案例描述：中断分节点应用服务器网线“X”（如图5-1示）连接，分节点客户端无法访问应用；过若干时间恢复连接。

预期结果：①故障发生时用户终端本地access数据库被启用，允许被客户端软件访问；②故障发生时检查分节点应用服务器上MB/MQ软件队列中有待发布消息堆积；③故障恢复后检查用户终端access数据库被刷新；④故障发生期间未影响分节点管制安全，业务操作可连续。

调试案例4：

案例描述：中断分节点数据仓库服务器网线“Z”（如图4-1示）连接，分节点客户端本地数据统计功能失效；过若干时间恢复连接。

预期结果：①故障发生时用户终端本地数据统计功能失效；②故障发生时检查分节点应用服务器上MB/MQ软件队列中有待发布消息堆积；③故障发生时检查分节点数据仓库无新同步数据；④故障恢复后检查分节点数据仓库有新同步数据并数据无缺失；⑤故障发生期间未影响分节点管制安全。

4.3 结果分析

根据上述的调试方案在仿真系统测试后，记录形成下表4-3；

表4-3 结果记录表

结果表明本系统的模型设计和应用设计符合实时运行系统的业务要求，在故障发生时当地具备系统自治能力，能够保证业务的连续性，不影响当前的安全生产；同时无论是系统日常运行阶段或故障恢复后都能确保数据的一致性，有效保证各地处理数据的统一性及后期用于统计的数据的可用性。

5 结束语

本文提出了一套适应于空管实时运行系统的数据库架构，该架构设计通过实际应用满足了系统安全性、可靠性的运行需求，同时也为其他类似实时运行系统的建设提供了一种可行的解决方案。

[1]Ryan K.Stephens，Ronald R.Plew. Database Design[M].何玉洁,译.北京:机械工程出版社,2001:1-333.

[2]王涛.多层分布式数据库实战[M].北京:清华大学出版社,2000:1-212.

[3]张龙祥,黄正瑞,龙军.数据库原理和设计[M].北京:人民邮电出版社,2002:1-364.

[4]许骏,柳泉波,李玉顺.面向服务的网格计算:新型分布式计算体系与中间件[M].北京:科学出版社,2009:1-340.

[5]张志伟,隋品波,郭长国,吴泉源.分布对象中间件异步消息的研究与实现[J].计算机学报,2004,(12): 1626-1632.

[6]徐罡,黄涛,刘绍华,叶丹.分布应用集成核心技术研究综述[J].计算机学报,2005,(4):433-444.

[7]Blair G.S,Coulson G,Andersen A,Blair L,Clarke M.The design and implementation of OpenORB[J]. IEEE Distributed System，2001,2(6):34-56.

[8]Kon Fobio,Costa Fabio,Blair Gordon,Campbell Roy H.The case for reflective middleware[J].Communications of the ACM,2002,45(6):33-38.