民航旅客信息系统HTH报文成组并发控制优化

毛军为，郝 鹏

（中国民航信息网络股份有限公司，北京 100710）

IATA Host to Host通信协议，是旅客和机场数据交换协议中的一部分，由IATA制定。该协议描述内容等同于OSI参考模型中第4～6层的服务内容。协议主要关注于实时报文交互以及有保护的点到点报文转发功能。由于该协议基于SLC、X.25或AX.25协议之上，因此相当于转换协议[1]。

1 报文交换及其应用

虽然目前国际上领先的各大GDS和航空公司系统架构、技术发展路线不同，但在系统间HTH报文交换方面，都朝着基于业务类型分组和精细化控制的方向发展，以求拥有高性能、大容量和高并发能力的同时，更灵活地支持应用业务的发展[2]。由于优利公司系统在软、硬件方面的专有性，在现阶段，无法直接借鉴现有先进技术，只能在掌握当前主机系统底层技术实现的基础上，独立研发基于优利主机系统平台的高性能电报交互控制模块。

在当前民航旅客运输业中，全球各大计算机分销系统（GDS）和航空公司信息系统之间的电报数据交换普遍采用国际标准及行业通用的报文协议[3]，报文交换广泛应用于民航旅客信息系统的多个核心业务模块。随着中国民航业的持续高速增长，三大国际航空联盟、电子客票等国际合作业务的全面展开，中国民航旅客信息系统与国外航空公司信息系统、各大计算机分销系统之间开展了广泛而密切的合作。在报文交互方面，目前中国民航旅客信息系统与上百家国外航空公司、大型分销系统之间建立了双向直连通道，连接数多达210条，与外航系统间各类报文交换数量也呈逐年递增的趋势，目前仅航空业务模块峰值期间接收报文量已达到320份/s，瞬时峰值超过450份/s。

图1列出过去5年来中国民航旅客信息系统航空业务模块峰值期间接收报文量与民航旅客量[4]的增长情况对比。可见，随着旅客量的持续增长和业务合作的深入广泛开展，跨系统平台的报文访问量增长趋势大大高于旅客量的增长趋势。中国民航业务量和交易量的快速增长，系统间业务合作的种类、范围和复杂度的不断提高，都对民航旅客信息系统对报文的实时、并发及高效稳定的处理能力提出了更高的要求，在针对边界条件的高性能处理方面[5-6]，就更具挑战性。

中国民航全球分销系统和航空公司系统采用美国优利公司大型主机解决方案，在未来5年内，整个信息系统70%以上的数据、75%左右的业务逻辑实现以及90%的交易指令，仍然由主机系统承担。同时，高速网络环境中，网络业务的机制面临着业务弹性与处理性能两个方面的挑战[7]。因此，如何对现有主机系统技术架构进行升级改造，使其适应新兴业务模式的发展要求，并与现代信息技术和外围开放子系统有机融合，是当前面对的一大问题。而提升系统间报文交换的支持能力，是众多技术难点之一。

本文介绍了一种报文成组并发控制的技术解决方案，在现有主机系统报文处理架构的基础上，根据报文会话属性、分块属性、路由属性等特征，对报文进行应用层分组控制，合理利用有限的系统资源，在满足业务功能要求的前提下，有效提升了系统的访问容量和并发处理能力。应用新技术架构后，综合处理效率和服务容量都有显著提升；同时，通过对不同业务功能的访问隔离，实现了系统资源的灵活配置，提升了系统服务水平。

2 HTH报文处理架构

HTH报文处理过程分为系统层面过程和应用层面过程[8-9]：系统层面过程主要关注系统资源分配、报文并发处理调度、系统间状态同步等非业务应用方面的工作；应用层面过程主要关注报文能够被迅速正确地处理，满足各业务功能需要。服务响应端系统应用处理平台在收到对端系统的请求报文后，在系统层面上的处理过程，决定了一个系统对报文处理的能力和效率[10]。

一个高效稳定的系统对报文处理的能力必须具备以下几方面的要求：

1）对大容量和高并发报文的实时响应能力；

2）区分来自不同远端应用服务的请求并维护会话状态；

3）系统间应用层通信状态协调；

4）不同会话类型、应用类型之间的会话冲突管理。

以上各项，可归纳为报文处理在响应速度、并发容量、系统间状态一致性、应用稳定性等方面的要求。这些要求相互影响制约，很难做到同时满足。

为解决上述矛盾，满足系统报文处理的实际需求，首先需要对各类报文的通信、同步方式特点以及系统响应处理的要求进行分类统计，在此基础上设计并建设高效可靠的报文处理架构体系，提供多样而有针对性的报文处理功能，从而优化系统处理能力，保证报文处理的一致性、稳定性和可靠性要求，并实现系统资源的合理分配和动态调整。

2.1 HTH报文属性

HTH报文在系统处理层面可以根据传输属性进行分类[11]，传输属性按报文传输过程中，不同的关注点分为3类，每类包含以下多种状态：

1）会话属性：描述报文之间的应用层上下文关系，包含以下状态：①会话开始（first in series）；②会话保持（middle in series）；③会话结束（last in series）；④会话终止（PEQ/WHY-CODE）；⑤无会话报文（only in series）。

2）层叠属性：描述3方通信状态下，报文向第3方系统转发的要求，包含以下状态：①转发请求（PUSH）；②转发答复（POP）；③无转发要求（NOPE）；④基于第5层协议的转发（layer 5 cascading）。

3）分块属性：应用层报文尺寸超过系统通信容量时，分块传输的要求，包含以下状态：①首个分块（F）；②中间分块（D）；③最后分块（E）；④无分块（-）。

任何报文，都可描述为上述3类属性中某种状态的组合，图2以1种复杂组合为例，描述HTH报文状态组合的多样性。由于3类属性中的各个状态可以以任意组合的形式出现，所以当报文状态是标准会话、又需要层叠转发处理，同时还是大容量分块时，报文可能是36种①不同传输状态组合中的一种。

图2 HTH报文传输属性分类Fig.2 Classification of HTH messages by transmission attributes

报文属性和状态不同，对应的处理要求也不同。在某些情况下系统只需简单地将报文转给应用层继续处理，另一些报文的处理过程中则需要保存前一份报文的状态，更有一些报文，系统甚至需要保存之前收到的所有与之相关联报文的内容。要同时兼顾所有这些状态组合，相应的处理逻辑将会非常复杂和冗长，效率很低，而且，系统各种配置资源都不能充分利用，从而造成大量的空等待浪费[12]。对于并发访问量和传输状态组合复杂度都极高的民航旅客信息系统，上述处理逻辑势必会造成处理效率低下、系统配置资源浪费和应用一致性混乱等多方面的严重问题。

2.2 报文成组并发控制架构

如果能够根据报文传输属性的不同状态，对报文进行分类，并针对不同属性状态的特点，优化相应的处理逻辑，使每类报文都有专门的逻辑进行处理；同时，按报文3类属性的不同要求，进行分阶段处理，实现报文处理的流水线作业模式，就可以提升系统处理效率和配置资源的利用率，从而实现系统整体处理效率和并发容量的大幅提升。

图3描述了报文成组并发控制优化逻辑的基本架构，此架构介于网络通信接口与应用层报文处理逻辑之间，为应用层隐藏了网络通信以及系统层报文控制的细节。整个架构由传输类型识别调度模块、5种独立的报文分类处理模块、规则设置与监控模块以及后台辅助处理模块共8部分构成。

图3 HTH报文成组并发控制优化逻辑基本架构Fig.3 Structure of optimization logic of HTH message grouping concurrency control

其中，分块大报文拼装模块负责完成分块数据暂存、顺序控制、报文拼接、一致性检查等工作；层叠模式报文转发分为“无状态保护”的直接转发和与应用层逻辑关联的“有状态保护”转发2种模式，系统分别提供独立处理模块和专用的系统资源配置。会话属性将报文分为“标准无会话报文”（SONM②）与“标准会话报文”（SMTM③）两类，分别进行处理。超时会话清理器负责查找并清理服务超时或意外故障情况下的无效会话，并释放系统资源。

实际处理过程中，报文首先由连接类型识别调度模块（link type control）分析；依次检查报文分块属性（HEDI④）、层叠属性（CASCADING⑤）和会话属性（MSG series）的状态，调用或跳过相应的处理模块，根据需要分配和占用系统资源，直至完成系统层面全部处理。

HTH报文按照传输类型虽然可以细分多种，但是实践过程中大量出现的报文类型主要分为“标准无会话报文”和“标准会话报文”2类。下文将就标准无会话报文和标准会话报文两个处理模块在应用成组控制优化逻辑的实现原理进行详细介绍。

2.2.1 标准无会话报文（SONM）处理模块

标准无会话报文的特点是各报文之间没有上下文关系，接收系统不需要保存通信会话状态和应用处理状态，在当前系统报文处理架构下，不会为标准无会话报文分配独占的配置资源⑥，而是在资源池中临时分配一个配置单元供其使用。

目前中国民航旅客信息系统的航空业务模块收到的SONM报文量约占航空业务模块收到全部报文量的25%，而为处理这些报文，需要独占或共用报文处理配置资源约为系统全部报文处理配置的95%以上，大量的资源处于无效占用状态[2]。

并发容量指1s内系统能够处理的请求报文量，目前单份SONM报文的系统平均处理时间为75 ms⑦，在操作系统层面，允许同时执行70个进程，专门用于请求报文处理，计算出的理论并发容量在当前资源配置下的上限值约为950份/s⑧；而在不使用成组控制优化逻辑的情况下，报文处理资源配置得不到充分利用，对单个远端应用服务，实测SONM报文最大并发处理容量只有理论值的一半。

此外，在不使用成组控制优化逻辑的情况下，每个独立远端应用服务独占一组配置资源，为了保证系统在瞬间峰值压力下的处理能力，各组配置都留有相当多的冗余量，所以在绝大多数情况下，大量配置都处于空闲状态；而另一方面，系统无法分配足够的配置资源支持大容量标准会话报文（SMTM）的访问，系统资源配置的浪费极为严重。

成组控制优化逻辑从节省系统资源配置和提高并发处理容量两方面对SONM报文处理过程进行优化。系统原有逻辑在处理SONM报文时，分配了与SMTM报文处理相同的配置单元，由于SONM报文的上下文无关属性，分配的系统资源既不需要独占，又不需要记录通信状态。所以实际上，原有SONM报文处理过程，只是执行了分配、保持和回收系统资源的操作，而没有实际使用这些资源。

因此，系统收到SONM报文后，可以随机分配一个虚拟配置⑨进行处理。成组并发控制优化逻辑中的“无会话报文共享PID池”模块，定义了一组虚拟配置，SONM报文处理逻辑能够象访问真实资源一样访问各组虚拟配置单元，完成SONM报文处理。这些虚拟配置构成系统的“公用虚拟配置资源池”，处理来自不同系统的所有SONM报文。由于多个访问系统共享配置冗余度，而且实际上多个系统之间存在着访问量自然错峰的特点，使用成组控制优化逻辑后，以当前SONM报文平均访问量（35次/s10）计算，整个民航信息系统的航空业务模块只需要35个虚拟配置就可以满足要求，且理论配置冗余度仍然高达90%⑪以上。

由于系统不需要为SONM报文保存会话状态和应用状态，因此可以采用虚拟公用配置池模式处理SONM报文，不再静态占用物理配置资源。这种模式下，系统对SONM报文的并发处理容量也可以接近系统处理能力的理论上限值。

此外，出于应用多样性、系统安全和负载平衡等方面的考虑，需要对虚拟配置模式加以控制。在虚拟公用资源池的基础上，增加了根据报文应用类型或报文来源系统的不同，对SONM报文进行分离处理的功能，并引入文件锁⑫来控制各组的并发处理的上限值。这样，各组报文处理过程可根据实际需要使用预先定制的虚拟配置，每组报文占用的系统资源以及全部SONM报文处理的总系统开销都将处于控制之下。

2.2.2 标准会话报文（SMTM）处理模块

标准会话报文的特点是一组报文之间存在着上下文关系，系统需要为这些报文保存通信会话状态和应用处理状态，因此一组具有关联关系的SMTM报文，必须在同一个连接配置上进行处理。这对会话状态管理和系统间同步的要求更严格。SMTM报文占民航信息系统的航空业务模块接收报文中的很大部分，相应的系统配置资源和系统开销在所有报文中也占较高比例。

为了满足SMTM报文的大容量、高并发特性以及实时性要求，标准会话报文处理模块采用资源多级分组方式，为每个需要建立新会话的报文调配所需要的系统资源。

第1级资源分组是根据请求报文的源地址进行的自然分组。由于SMTM报文的上下文关联属性，系统需要为每个报文标识（TPR）⑬分配独占资源，基于报文来源分组后，可以防止来自不同系统并具有相同标识的报文引发的冲突问题，系统为每组分配一定数量的配置资源，由该组报文专用。

第2级资源分组对同一来源的报文进行访问负载平衡控制。首先，引入快速高效的USAS⑭常驻内存数据库记录报文会话状态；之后，在第1级自然分组的基础上，将系统资源配置为多达36个RANGE⑮序列。在高并发访问状态下，系统将同时收到多份属于同一自然分组的报文，系统为每份报文初始化一个处理进程。这些进程使用同步锁依次访问常驻系统内存公共数据区，后者保存系统上一次为同类进报分配的RANGE序列号，获得内存访问权的进程根据当前RANGE序列号选择下一个有剩余资源的RANGE序列，分配给当前报文，并更新内存中相应的RANGE序列号。通过这种方式，并发进报被平均分配到多个RANGE序列上，实现了负载均衡。

第3级资源分组由属于同一RANGE下的一组配置单元（PID⑯）组成。被分配到同一RANGE序列下的报文，其处理进程使用文件锁依次访问系统资源分配管理文件，获得一个非占用系统资源，更新会话状态，并在整个会话过程中独占资源。

图4是资源分组处理模式的示意图，一级分组为国外GDS SABRE报文独占；在二级分组，系统为来自SABRE的所有报文，分配了36个RANGE；在三级分组，每个RANGE包含55个配置单元（PID），每个配置单元1次可以处理1份SMTM报文。

图4 多级成组处理模式示意图（以一家国外GDS（SABRE）的配置为例）Fig.4 Multi-level message grouping processing model

系统通过3级分组方式为SMTM报文分配系统资源并建立会话，处理过程主要通过搜索和更新内存数据记录完成，仅涉及1次文件读写操作（保存会话状态），整个过程的系统开销非常低，并且会话建立后，属于同一会话的后续报文能够迅速和准确地定位到上次分配的系统资源。同时，通过3级分组模式，所有并发进报的负载被均衡分布到各配置单元上，使系统资源得到了充分利用，从而满足整个系统处理大容量、高并发报文的要求。

2.2.3 依应用类型分组模式

采用多级分组模式后，在同一自然分组内部，仍然可能出现局部并发压力过高和一致性冲突的问题。这是因为同一服务发起端系统通常要向服务响应端系统发送多种应用类型的SMTM报文，在系统总体配置资源量的限制下，这些属于不同应用类型的报文只能被分配到同一自然分组内。而二级分组忽略报文类型的差异，对所有接收到的报文平均分配资源。存在这种可能，即当某个应用的访问量出现瞬间高峰，或者因一致性问题导致大量配置资源被较长时间占用时，所有属于同一自然分组的应用都将受到影响。此外，也应该考虑到，多个应用类型的报文共用同一组PID资源，在应用系统层面也容易出现一致性冲突。例如，实际应用上存在这种情况：在一个会话中，具有相同标识的一组报文可能属于不同的应用，系统为这些报文分配同一个PID资源，由于这些报文在应用层的服务超时时间（time-out）不同，在达到较短超时时间值后，整个会话就被终止，造成设置为较长超时时间的应用，出现系统间同步问题。

为解决这些问题，在三级分组均衡负载的基础上，提出了应用分组概念。应用分组就是给二级分组的各RANGE赋予应用属性，在完成一级分组后，报文按应用类型被限制到指定的二级分组区域内（部分RANGE内），各应用使用的配置资源相互隔离。这样，在不同应用之间调配系统资源就成为可能，进一步，通过实时监控各应用访问压力，以及在不同时间周期上各应用访问量变化规律的统计数据，可以实现根据报文处理需要，在不同应用之间动态调整配置资源，在提升应用一致性的同时，优化了系统资源配置。

图5是应用分组处理模式的示意，36个RANGE根据业务应用特点和访问量的不同，分为逻辑上相互隔离的3组，分别用于Booking请求报文、TKT请求报文和其他请求报文的处理。

3 实验结果

为验证报文分组并发控制架构的实际应用效果，采用开放端模拟大量请求报文方式，进行对比测试。

系统原来分配了大量物理PID，用于SONM报文的处理，在当前的访问量下，资源冗余度只有20%；在引入了成组控制优化逻辑后，只需35个由全系统共享的虚拟PID替代原有真实处理PID，在相同报文访问量下，仍然能够保持90%以上的冗余度。另一方面，系统访问虚拟PID的效率要明显高于真实PID，SONM报文的处理时间会变短，因此，新方案所需系统配置资源大大降低，而报文的实际最大并发处理容量可以接近理论上限。

图6列出了使用成组控制逻辑前后系统配置资源和报文最大并发处理容量的比较，为满足现有SONM报文并发处理容量要求，新方案只需要35个虚拟PID资源，相当于原有配置的1/16。

对于SONM报文的处理，报文发生器模拟每秒500份只读查询请求报文。实测效果如图7所示，图7中横轴表示压力测试持续时间，单位为秒，纵轴表示等待处理的请求报文个数。在原有处理逻辑下，随着时间增长，系统出现大量请求报文排队等待现象（图7中A1线），表明当前测试报文访问压力已超出系统承受能力；而采用并发控制架构后，报文请求队列缓慢增长，系统仍然能够正常处理请求，可以平稳渡过访问高峰期（图7中A2线）。

对于SMTM报文的处理，报文发生器模拟每秒200份只读查询请求报文，同时，模拟每秒50份数据更新请求报文。实测效果如图8所示，图8中横轴表示压力测试持续时间，单位为秒，纵轴表示SMTM请求报文被拒绝的百分比。

在原有处理逻辑下（图7中A1线），由于只读请求报文量较多，占用了大量配置资源，导致大量数据更新请求因资源限制问题被拒（向请求方系统回复错误代码3M）；通常基于超时机制来判断进程是否失败[13]。而采用并发控制架构后，使用应用分组模式设置只读请求和数据更新请求的资源分配比例，系统可以正常处理大部分数据更新请求。从实测效果来看，报文分组并发控制架构使用较少的配置资源（原配置数量的1/16）就可以轻松满足系统SONM报文处理的需要；对于SMTM报文的处理，报文分组并发控制架构可以灵活设置系统资源的分配，确保关键业务应用顺利进行。

综合上述实测数据，在现有业务量和交易量条件下，实际应用报文成组并发控制逻辑后，节约的系统配置资源和CPU处理资源⑰，其直接经济效益约合人民币450万元/年，同时系统资源能够更多地分配给关键业务应用，从而实现了整体服务能力的提升。

4 结语

随着中国民航旅客运输量的快速增长，中国各大航空公司越来越多地参与到国际合作与竞争之中，新兴业务模式的出现以及IT技术的发展，都对旅客信息系统的数据交换能力提出了越来越高的要求。HTH报文成组并发控制方面的技术探讨和研究，在满足历史和环境限制的前提下，提出了大容量、高并发的实时交易系统报文处理在性能和信息一致性方面的解决方案，根据实测数据，HTH报文成组并发控制逻辑能够大幅提升系统报文并发处理能力，提高了系统对应用业务访问控制的灵活性，这一方案对新一代系统技术架构的设计具有一定的参考价值。

注释：

① 36为4种会话状态×3种路由状态×3种报文分块状态的组合。

② SONM：标准无会话报文，Standard only in series message。

③ SMNM：标准会话报文，Standard multiple in series message。

④ HEDI：指报文长度超过4 k字符的HTH报文。

⑤ CASCADING：层叠模式，三方通信状态下报文路由及会话控制功能。

⑥ 系统配置资源指服务器端报文处理所需的PID、同步锁、文件缓存等，各类系统资源之间存在固定配置比例关系，本文中简单地使用PID数量表示系统配置资源。

⑦ 业界的平均处理时间为250～300 ms。

⑧ 2010年中国民航旅客服务系统航空业务模块的瞬时峰值报文量为420 份/s。

⑨ 虚拟配置：为保证报文处理顺利进行而增加的部分程序逻辑，不占用真实系统配置资源。

⑩ 按照航空业务模块报文平均访问量140次/s来算，SONM报文占25%，即为35次/s。

⑪ 对每个虚拟PID，按75 ms处理1份报，每PID每秒可处理13.33份报，当前只收到1份报，所以冗余度约为92%。

⑫ 文件锁：多进程同步控制机制，同一时刻最多只能有1个进程占用文件。

⑬ TPR：transaction process reference，用于记录发起报文的终端信息。

⑭ USAS：unisys standard airline system，UNISYS公司的航空旅客服务大型联机事务处理系统。

⑮ RANGE：系统配置资源的分组概念，每个RANGE包含一定数量的系统配置。

⑯ PID：physical device identifier，系统配置资源的标识。

⑰ 根据系统提供商的计费标准进行估算，每单位CPU资源的年使用费用约合1.3万元人民币。

[1]IATA.IATA Systems Communications Reference:PART IV－Open Systems Migration Roadmap for Communications[G].Version 1.5.Montreal：IATA，1998.

[2]ZHAO YIFEI，ZHANG DE，YUE RENTIAN，et al.Analysis and Specification for Civil Aviation Information System[C]//icccs.2009 International Conference on Computer and Communications Security.Hong Kong：IEEE.2009:72－75.

[3]IATA.Reservations Interline Message Procedures Passenger（AIRIMP）[G].33rd ed.Montreal－Geneva:IATA，2009.

[4]中国航信运行中心.运行中心性能分析平台[EB/OL].（2011－03－22）.http：//172.17.23.163/1.asp?pagename=HVSTAT.

[5]DIRCEU CAVENDISH，KAZUMI KUMAZOE，MASATO TSURU，et al.An Adaptive TCP Slow Start for High Speed Networks[C]//Proceedings of First International Conference on Erolving Internet.Cannes：PFLDnet，2009（8）：15－20.

[6]SATHISH GOPALAKRISHNAN，MARCO CACCAMO，LUI SHA.Switch Scheduling and Network Design for Real－Time Systems[C]//12th IEEE Real－Time and Embedded Technology and Applications Symposium（RTAS′06），2006：289－300.

[7]张建宇，周 渊，邹 维.PaSeM：并行无冲突的网络流量会话管理[J].计算机学报，2010，33（7）：1195－1212.

[8]UNISYS CORPORATION.USAS Systems Control（USAS SYS）Operations Reference Manual[G].Blue Bell:Unisys Corporation，2008.

[9]UNISYS CORPORATION.USAS Systems Control（USAS SYS）Programming Reference Manual[G].Blue Bell:Unisys Corporation，2008.

[10]UNISYS CORPORATION.Communications Application Program Interface（COMAPI）User′s Guide[G].Blue Bell:Unisys Corporation，2010.

[11]UNISYS CORPORATION.USAS Message Switching（USAS MSG）Operations Reference Manual[G].Blue Bell:Unisys Corporation，2007.

[12]牟 乔.准确高效的应用层协议分析识别方法[J].计算机工程与科学，2010（8）：39－45.

[13]XIAO GUANG DING，ZHIMIN GU，LEI SHI，et al，A Failure Detection Model Based on Message Delay Prediction[C]//2009 8th International Conference on Grid and Cooperative Computing，2009：24－30.