在“全国综合气象信息共享平台”(以下简称CIMISS) 项目中，对数据收集与分发子系统 (简称CTS子系统) 的传输时效提出了具体要求。CTS子系统作为CIMISS整个系统的数据源入口，主要实现对气象数据的收集、预处理、分发及补调等任务。如何将气象数据以高时效的形态完成收集、处理工作并转发给中国气象局其他各直属单位、业务系统以及各省气象部门，是本文的重点研究目标。

卫星数据作为十四大类气象数据的一类，具有数据种类多、数据总量大、单个文件容量区间范围跨度大等特点。本文以卫星数据为例，从卫星数据容量及数据转发用户角度，分析了国家气象信息中心通信业务中接收和转发卫星数据的一些特点。通过对卫星数据转发流程的分析，可比较方便地模拟大、中、小等各种容量的文件传输。

在对现有数据收发业务模式剖析的基础上^[1-4]，提出了应用内存转发模型^[5-7]，即利用内存共享机制，将数据接收流程和数据转发流程统一联系起来，建立数据通路，减少多个中间处理环节。该模型在目前数据收发系统中应用较少，但随着对数据收集和转发时效需求不断提高以及内存自身成本的不断降低，使用内存作为中间处理环节的存储载体将成为可能。

参照内存转发模型，设计出了适用于国家气象信息中心的数据转发业务的统一数据转发流程，并通过对FTP服务端程序模块进行改造，在FTP Server端实现了统一数据转发流程。本文以卫星数据及产品的收集与分发为例，进行了原型系统的开发和测试，对内存转发模型的适用性进行了检验。

随着计算机制造技术的快速发展，CPU、内存、磁盘等电子器件价格不断降低，但性能却在成倍提升^[8-9]。充分发挥内存的潜能和优势以提高系统的应用效率，已成为目前很多应用系统设计和开发必须考虑的问题。虚拟内存、内存管理系统、内存文件系统等围绕内存产生的技术应运而生。在成本与时效的权衡方面，找到一个理想的折衷点，可利用较小的成本，获得较大的收益。在以往气象业务中，由于气象数据及产品容量相比目前还不是很大，用户对数据的传输时效要求也相对较低，所以数据收集、处理及转发均使用磁盘作为中转存储载体。但随着大规模数据种类和数据量的不断增加，对数据收集与分发的时效要求也提出了更高的指标，磁盘做为中转存储载体，其在性能方面和数据流程环节方面所存在的固有弱点日益凸显，在应用系统设计方面适当利用内存来提高系统的运行时效，成为了现实的选择。

相对于常规资料而言，卫星资料具有日增文件总量大、单个文件容量差异较大的特点。国家气象信息中心目前接收的卫星资料超过260种，涵盖FY-1气象卫星、FY-2气象卫星、FY-3气象卫星，NOAA，JASON，MTSAT，MODIS，METOP-A，METEOSAT等^[10-12]。这些数据中既包括实时传输的原始数据和各类产品，也包括已经停止更新的历史数据集和产品。截至2010年底，国家气象信息中心己接收的卫星数据总量达到214 TB，日增量244 GB。表 1列出了对170余种数据产品的27000多个日增文件数据容量的统计结果。

表 1

表 1 日接收单个卫星文件容量分析 Table 1 Capacity analysis of single satellite product file received per day 数据容量 文件个数 所占比例/% (0, 100 KB) 1980 11.7 [100 KB, 500 KB) 3298 19.4 [500 KB, 1 MB) 2550 15.0 [1 MB, 10 MB) 4726 27.8 [10 MB, 100 MB) 2400 13.9 [100 MB, 1 GB) 2074 12.2

表 1 日接收单个卫星文件容量分析 Table 1 Capacity analysis of single satellite product file received per day

通过分析可以发现，在国家气象信息中心每日接收的卫星数据中，单个卫星数据的容量最小的只有2 K，最大能够达到672 M。单个卫星数据的容量分布区间范围跨度非常大，而且各个区间在整体范围区间内分布相对比较均匀，除[1 MB, 10 MB) 占整个范围区间的27.8%外，其他每个容量区间所占总量的比例均为15%左右。

随着观测数据及业务应用的不断发展，以及国家气象信息中心存储和服务能力的不断提高，卫星数据及产品的容量将会不断增加；将来国家气象信息中心每天接收的卫星数据量将达到1.3 TB。这无疑对CTS系统的收集、处理、转发效率提出了更高的要求。

国家气象信息中心实时接收到卫星数据后，首先根据文件名判断其所属的数据种类，然后根据己配置好的转发策略表获取数据服务用户列表，并将数据一一转发给对应的服务用户。服务用户在本文中是一个广义的概念，它既可以指CIMISS系统内除数据收集与分发分系统外的其他分系统，也可以指CIMISS系统外的其他业务系统，同时也可以是个人用户。

在CIMISS项目中，卫星数据的服务用户包括数据加工处理分系统 (DPC)、数据存储管理分系统 (SOD)、CMACast系统以及国家气象中心、中国气象科学研究院等业务和科研单位。其中，大部分卫星数据经数据收发分系统 (CTS) 接收后可以直接转发，而不需要经过DPC分系统进行处理。但也有少部分数据需要经DPC分系统重命名和加工处理，例如GOES-11/12卫星图像产品、METEOSAT-7/9卫星图像产品等，需要将接收到的原始数据处理为图像产品，并将原始文件和图像产品同时对外提供共享服务；METEOSAT-9卫星定量产品需要DPC分系统将原始数据进行BUFR解码，并将原始文件和解码后的文件同时对外提供共享服务。

在现有的通信系统中，数据的收发流程可以分为3个独立的进程，即数据收集进程、数据处理进程、数据转发进程 (如图 1所示)。

图 1

图 1. 现有数据转发流程 Fig 1. The current data transmission process

数据收集进程只负责接收从各个数据来源传来的文件，将文件存放在相应的待处理目录下；数据处理进程通过目录轮询获得待处理的数据，并将处理后的结果存放在数据转发目录下；数据转发进程定期轮询每个转发目录，当发现有需要转发的文件后，根据转发策略转发给相应的用户。

转发流程中相邻环节之间缺乏及时有效的沟通。数据收集进程只负责将接收的数据落盘，而没有及时通知下游的数据处理线程；数据处理进程处理数据结束后，直接将数据落盘，没有及时通知其下游的数据转发线程；这两个环节的上下游之间互不沟通，导致处于下游位置的线程无法及时获得启动信息，从而无法及时处理上游线程已处理完的数据，因而使得转发流程的整体时效无法提高，导致最终服务用户 (业务系统或其他单位) 得到数据的时效低。

轮询目录型处理进程触发机制的效率不高。数据转发进程依靠定时轮询方式不断扫描接收文件目录，发现待转发数据，并将其转发，增加了目录轮询时间。此外，当出现一个或多个转发用户端故障，或网络线路故障时，转发失败导致未转发出去的数据文件数量逐渐积累，使得其所在目录内的文件数量和目录体积迅速膨胀，导致新接收的数据也不能及时转发出去。

存在冗余的读写操作。数据在收集、处理、转发3个进程中多次落盘和读写，对于大容量的卫星文件来说，磁盘读写次数多，浪费了不必要的时间。

为了解决或改进现有的分散式数据转发流程存在的问题，提高卫星数据转发效率，本文设计了一种基于内存直接进行转发的内存转发模型。

在内存转发模型 (图 2) 中，数据收集进程、数据处理进程和数据转发进程成为一个统一的整体，数据收发进程接收到数据源上传的数据并将其存储在内存 (或内存文件系统) 中，当文件上传完成后，数据收发进程立即启动或通知数据处理进程；数据处理进程处理完成后，立即启动或通知数据转发进程进行数据转发。

图 2

图 2. 内存转发模型 Fig 2. Memory-forwarding model

内存转发模型是一种多对多的转发模型，通过这种即时响应模式，数据收集进程可以同时接收来自多个数据源的数据，将数据保存在内存中，并及时通知数据处理进程；数据处理进程从内存中读取数据，完成文件换名、识别、解压缩、文件拆分、格式检查、格式转换等操作，然后通知数据转发进程进行数据转发。整个流程形成一个统一的整体，能够将数据以最快的时效发送到最终服务用户。即使出现某一服务用户端接收故障或者网络线路故障时，由于具备了相关的处理策略，也不会影响其他用户接收数据的时效。

在模型中，内存是指实际的物理内存，但没有限制是采用内存管理系统还是采用内存文件系统，具体实现方法有很多，可以根据系统需要和实际情况进行选择。

在CIMISS项目的数据收集与分发系统中，根据内存转发模型设计了统一数据转发流程。由于通信业务中使用FTP服务实现数据收集和转发，所以根据内存转发模型对FTP服务进行了改造。如图 3所示，统一数据转发流程包括几个主要环节 (忽略处理流程)：

图 3

图 3. 统一数据转发流程 Fig 3. The unified data transmission process

① FTP服务器端收到客户端请求数据上传后，创建内存文件并接收数据。

② 接收数据完成，记录相关信息并创建数据转发线程；否则通知发送端上传失败并释放内存空间，流程结束。

③ 数据转发线程根据本地配置表中的转发用户列表，将内存文件进行一对多转发。当转发用户中有1个或多个用户转发失败时，记录故障信息，并将文件存盘后释放内存空间。

为尽可能降低系统内部的耦合度，在统一数据转发流程中，将数据采集和转发流程设计为异步流程。即同一个时间段内，一个系统中可以同时存在多个数据采集线程和数据分发线程，一个数据采集线程完成采集任务后，不会直接启动下游数据分发线程进行数据转发，而是将待分发的任务通过消息机制与下游线程进行交互；同时，该采集线程进入等待下一个任务到来的状态。这样，就尽可能降低了各个不同线程之间的耦合度，从而提高了整套系统的可靠性。

此外，内存缓冲区通过设置上限阈值和下限阈值对内存使用率进行控制，以保障内存的使用控制在合理的范围内。

图 4

图 4. 多线程并行模式 Fig 4. The multi-thread parallel mode

根据实现4.2节的流程设计，需要对通用的FTP Server进行改造^[13-15]，使得FTP Server在进行数据接收的同时，能够一并完成数据处理及分发任务，真正实现数据收集、处理、分发的一体化。由于内存转发模型只需对FTP Server端进行改造，不需要Client端进行任何修改，所以对源数据推送用户以及数据接收用户而言，均能实现透明无缝过渡。

为了实现这个统一流程，本文相应设计3个部件单元，即数据收集单元、数据处理单元、数据转发单元。

数据收集单元主要功能及与数据处理单元接口：① 数据采集单元申请内存文件标识符；② 数据采集单元通过内存文件标识符向内存中写数据；③ 文件接收完毕，数据采集单元告知数据处理单元其所申请的内存文件标识符。

数据处理单元主要功能及与数据转发单元接口：① 对内存文件进行解压缩、重命名、格式检查、格式转换、拆包等处理；② 文件处理完毕，数据处理单元告知数据转发单元其内存文件标识符。

数据转发单元主要功能：根据分发策略，对内存文件进行一对多转发。

在FTP服务端，共考虑了4种异常，其种类及相应处理方法如下：① 接收异常。通知数据发送端，接收失败，重新发送并释放内存文件。② 转发异常。记录故障信息，包括接收端登录异常、网络链路异常、传输过程中异常等情况，并调用分发失败处理模块。③ 内存过载异常。与共享磁盘进行数据交互，过载时将文件直接存入共享磁盘，空闲时将文件重新加裁到内存进行转发。当内存使用达到上限阈值时，采集线程会自动将接收到的文件直接存入共享磁盘上；当内存使用低于下限阈值时，文件转发线程将共享磁盘中的文件加载到内存中，并在内存中进行数据转发。④ 进程异常。通过系统自身的进程守护机制进行监视和控制。

为了验证统一数据转发流程的实际效果，本文对统一数据转发流程和现有的转发流程 (模拟) 进行比较测试。测试安排在统一的服务器及操作系统环境下进行，并在测前实现了现有转发流程的目录轮询转发的模拟。测试结果仅供参考。

本次测试中，服务器为IBM JS43刀片服务器；操作系统为AIX 6.1；网络环境为千兆网。

分别取2.1节中6个范围区间内的单个文件容量进行测试，6种文件容量分别为50 KB，300 KB，800 KB，5 MB，20 MB，500 MB。每种测试各进行3次，取3次结果的平均值作为最终记录时间。在模拟现有目录轮询方案时，将目录轮询时间间隔设置为1 s。测试结果如表 2所示。

表 2

表 2 6种容量文件采用不同方案转发的测试结果 Table 2 Transmission testing result among six capacities of files with two kinds of schema 文件大小 文件数量 转发用户 平均收集 时间/ms 平均转发 时间/ms 目录轮询 /ms 内存转发 /ms 节省时间 /ms 提高效率 /% 50 KB 100 3 47 145 726 198 528 72.73 300 KB 100 3 272 826 1687 1106 581 34.44 800KB 100 3 695 2096 3853 3227 626 16.25 5 MB 10 3 438 1304 2168 1759 409 18.87 20 MB 10 3 1694 5098 7235 6804 431 5.96 500 MB 1 3 4347 13238 18324 17618 706 3.85

表 2 6种容量文件采用不同方案转发的测试结果 Table 2 Transmission testing result among six capacities of files with two kinds of schema

从测试结果能够看出，当文件容量为50 KB时，内存转发流程较目录轮询方式能够节省60%的时间；随着文件容量的不断增加，效率提高率逐渐下降，当文件容量增加到500 MB后，两种方案所用的时间几乎相同。

经过分析，当文件容量在100 MB以下时，内存转发方案能够节省至少20%的时间，而且文件容量越小，时间节省得效果越明显，最高可以节省70%左右的时间。但当文件容量超过一定大小后，制约文件接收和转发的瓶颈己经不是文件的读写和处理时间，而是网络传输时间。可以推断，当网络带宽增扩到一定程度时，即当大容量文件网络传输时间大幅缩减时，内存转发流程较之目录轮询方式的时效优势将逐渐体现出来。

本次对比测试前提是均使用统一数据转发流程，分别测试使用内存进行转发和使用本地磁盘进行转发的效率。本文选取200 MB的单个文件容量进行测试，文件数量选取40个，线程数10个；每种测试各进行3次，取3次结果的平均值作为最终记录时间。

选取4组测试条件组合进行测试：使用内存转发模型，数据库连接数选取为5个；使用磁盘转发模型，数据库连接数选取为5个；使用内存转发模型，数据库连接数选取为10个；使用磁盘转发模型，数据库连接数选取为10个。表 3是对每种测试组合条件进行测试的性能结果。

表 3

表 3 组合条件测试结果 Table 3 Testing results under different combined testing factors 测试指标说明 收集时间/s 处理时间/s 转发时间/s 并发执行收集、处理、转发总时间/s 内存转发，数据库连接数为5个 206 207 207 211 磁盘转发，数据库连接数为5个 313 320 325 331 内存转发，数据库连接数为10个 204 204 205 209 磁盘转发，数据库连接数为10个 308 305 319 325

表 3 组合条件测试结果 Table 3 Testing results under different combined testing factors

通过对4组组合测试结果进行分析，可以得出，使用内存转发比磁盘转发的时效平均可以提高37%左右。

相对于目前以目录轮询方式为主的传统的数据转发模式，内存转发模型在提高数据收集、处理、转发流程时效方面具有较明显的优势；由于内存转发模型的灵活性，使得在实际开发和部署时，可以通过建立应用级集群和设备级集群更好地将内存转发模型的性能优势发挥出来。

目前在CIMISS项目中，基于内存转发模型而实现的统一数据转发流程，已作为一个功能部件部署在核心区的数据收集与分发系统中。在CIMISS平台试运行过程中，内存转发模型和统一数据转发流程将根据实际运行结果继续进行完善和优化调整，并真正在数据转发业务系统中予以应用和检验。