一种航段净订座量的实时获取方法及装置

技术领域

本申请涉及数据处理技术领域，具体涉及一种航段净订座量的实时获取方法及装置。

背景技术

随着经济的发展，飞机成为主要的交通工具。正常机票销售流程为订座-支付-出票。订座为销售代理人通过主机预订占据一定数量的舱位，然后进行机票销售。但是很多销售代理人长期占座不出票，甚至有时候在航班起飞时才取消占座，直接影响到其它代理人对舱位的诉求，导致航班上座率低。目前通常采用将旅客订座记录(Passenger NameRecord，PNR)报文数据解析后按主题放入数据仓库，通过查询数据仓库的数据的方式获取销售代理人的净订座量。

在数据仓库中查询以获取销售代理人的净订座量的方式只能查询过去一天前的结果，存在无法实时获取净订座量结果的问题。

发明内容

有鉴于此，本申请提供一种航段净订座量的实时获取方法及装置，能够实时获取航段净订座量。

为解决上述问题，本申请提供的技术方案如下：

第一方面，本申请提供一种航段净订座量的实时获取方法，所述方法包括：

获取旅客订座记录PNR报文版本数据；

对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；

采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。

在一种可能实现的方式中，所述航段状态变化数据包括航段状态为确认状态的初始航段量和航段状态从确认状态变为非确认状态的变化航段量，所述采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量，包括：

根据所述初始航段量和所述航段旅客数量确定初始订座量；

根据所述变化航段量和所述航段旅客数量确定取消订座量；

根据所述初始订座量和所述取消订座量确定所述目标净订座量。

在一种可能实现的方式中，所述方法还包括：

获取当前PNR版本号和已处理PNR最大版本号；

若所述当前PNR版本号满足预设条件，则采用版本回溯的方法重建缺失PNR版本，所述预设条件为所述当前PNR版本号不为001且所述当前PNR版本号和所述已处理PNR最大版本号的差值大于1。

在一种可能实现的方式中，若所述当前PNR版本号大于或者等于所述已处理PNR最大版本号，所述方法还包括：

丢弃当前PNR报文版本数据。

在一种可能实现的方式中，所述对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量，包括：

将所述PNR报文版本数据解析成PNR对象流；

根据所述PNR对象流确定历史航段状态列表和历史航段旅客数量信息；

根据所述历史航段状态列表确定所述航段状态变化数据；

根据所述历史航段旅客数量信息确定所述航段旅客数量。

第二方面，本申请提供一种航段净订座量的实时获取装置，所述装置包括：

第一获取模块，用于获取旅客订座记录PNR报文版本数据；

分析模块，用于对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；

计算模块，用于采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。

在一种可能实现的方式中，所述航段状态变化数据包括航段状态为确认状态的初始航段量和航段状态从确认状态变为非确认状态的变化航段量，所述计算模块具体用于：

根据所述初始航段量和所述航段旅客数量确定初始订座量；

根据所述变化航段量和所述航段旅客数量确定取消订座量；

根据所述初始订座量和所述取消订座量确定所述目标净订座量。

在一种可能实现的方式中，所述装置还包括：

第二获取模块，用于获取当前PNR版本号和已处理PNR最大版本号；

版本重建模块，用于若所述当前PNR版本号满足预设条件，则采用版本回溯的方法重建缺失PNR版本，所述预设条件为所述当前PNR版本号不为001且所述当前PNR版本号和所述已处理PNR最大版本号的差值大于1。

在一种可能实现的方式中，若所述当前PNR版本号大于或者等于所述已处理PNR最大版本号，所述装置还包括：

丢弃模块，用于丢弃当前PNR报文版本数据。

在一种可能实现的方式中，所述分析模块具体用于：

将所述PNR报文版本数据解析成PNR对象流；

根据所述PNR对象流确定历史航段状态列表和历史航段旅客数量信息；

根据所述历史航段状态列表确定所述航段状态变化数据；

根据所述历史航段旅客数量信息确定所述航段旅客数量。

第三方面，本申请提供一种航段净订座量的实时获取设备，包括：处理器、存储器、系统总线；

所述处理器以及所述存储器通过所述系统总线相连；

所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述第一方面所述的航段净订座量的实时获取方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，当所述指令在设备上运行时，使得所述设备执行上述第一方面所述的航段净订座量的实时获取方法。

由此可见，本申请具有如下有益效果：

本申请提供一种航段净订座量的实时获取方法及装置，首先获取旅客订座记录PNR报文版本数据；其次对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；最后采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。如此，Flink计算框架能够支持有状态实时数据流方面的数据计算，通过对PNR数据流的实时计算，能够计算销售代理人销售量的变化情况，更加快捷的获取到航班预定情况的实时变化情况，满足实时获取航段净订座量的需求。

附图说明

图1为本申请实施例提供的一种航段净订座量的实时获取方法的流程示意图；

图2为本申请实施例提供的计算航班净订座量的实施框架图；

图3为本申请实施例提供的一种中航信净订座技术架构示意框图；

图4为本申请实施例提供的PNR报文版本数据解析示意图；

图5为本申请实施例中版本回溯重建缺失版本的流程示意图；

图6为本申请实施例提供的汇总计算的流程示意图；

图7为本申请实施例提供的一种航段净订座量的实时获取装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

随着航空业的发展，净订座量成为反映航班预定情况的一个核心指标，能够较为客观的反映航班的预定情况。正常机票销售流程为先订座再支付，最后出票。订座就是代理人通过主机预订PNR占据一定数量的舱位，然后进行机票销售，在实际情况中，出现很多代理长期占座不出票，甚至有时候在航班起飞时才取消占座，直接影响到其它代理人对舱位的诉求，严重情况下会影响到航班上座率从而影响到航空公司的经济利益。为了规范代理人操作行为以及提高销售业绩，需要实时掌握各代理人在各主机航、外航的净订座情况及变化情况，结合航信与代理人的合同契约，通过提醒、罚金、激励等多重手段来约束代理人操作行为，从而完成既定目标。

目前业界主要采用的是非实时计算方法，其过程是将PNR数据解析后按主题放入数据仓库，然后通过从数据仓库中查询的方式获取净订座量。但是这种非实时的计算方法只能查询过去一天前的结果，无法支持需要实时结果的场景。

基于此，本申请实施例提供一种航段净订座量的实时获取方法及装置，首先获取旅客订座记录PNR报文版本数据；其次对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；最后采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。如此，Flink计算框架能够支持有状态实时数据流方面的数据计算，通过对PNR数据流的实时计算，能够计算销售代理人销售量的变化情况，更加快捷的获取到航班预定情况的实时变化情况，满足实时获取航段净订座量的需求。

为了便于理解本申请实施例提供的技术方案，下面结合附图对本申请实施例提供的一种航段净订座量的实时获取方法及装置进行说明。

本申请实施例所计算的航段净订座量数据能够反映当前航段的实际预订情况。参见图1，图1为本申请实施例提供的一种航段净订座量的实时获取方法的流程示意图，该方法可以应用于机票销售数据大屏(Ticket Sales Date View，TSDV)，本申请实施例对此并不进行限定。该方法具体包括S101-S103。

S101：获取旅客订座记录PNR报文版本数据。

在民航主机订座系统中，一个完整的PNR记录了旅客订座的完整信息，包括航班信息、旅客信息、订座状态信息、运价信息。PNR报文版本数据可以从存储服务器中获取，也可以通过其他方式获取，本申请实施例中并不限定PNR报文版本数据的获取方式。

S102：对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量。

每个PNR均对应一个版本，通过对PNR报文版本数据的变化过程进行分析，可以得到航段状态变化数据和航段旅客数量，进一步根据航段状态变化数据和航段旅客数量计算最终的净订座量。

PNR报文以xml的形式存在，主要包括版本更新列表、航段信息、旅客信息、历史数据区、责任office以及计算框架。

其中，版本更新列表UpdateList用于记录每个PNR版本变化的时间、操作代理人等PNR基础信息。

每个PNR可以包括多人、多航段的预定信息，航段信息SegmentList包括航段起飞时间、抵达机场时间等基础信息，还可以包括该航段是在PNR的哪个版本创建的(CreationNum)、航段当前的操作状态码及订座人数。航段操作状态码用于反映航段的当前状态，例如：HK(预定)、HL(候补)、UC(不接受候补)、TK(航班时刻已更改)、DK(预留)、RR(确认)、HX(误机)。比如：RR2，其中RR表示航段操作状态码，2表示订座人数(ActionCode)。历史版本的航段操作状态码，比如：NN(001)HN(001)KK(003)RR(005)，表示在PNR的版本001、003、005时对航段进行了NN、HN、KK、RR操作，此处不包括订座人数HisActions。

旅客信息包括旅客的姓名、身份证等基础信息，对于分析订座量而言，这里唯一有意义的是CreationNum，表示该旅客是在哪个PNR版本添加的，结合航段信息HisActions中的版本号，可以还原出PNR在某个版本时的订座人数。

历史数据区History用于记录PNR的历史变更情况，在分析净订座量时，只需要关注历史变更区中的NameList、SegmentList即可。历史数据区中的NameList、SegmentList和非历史数据区中的对应节点，在结构上并没有差异。只是CreationNum的内容会不一样，比如：CreationNum＝"001/005，这里表示该航段在PNR的版本001创建，在005时被删除。

责任office为代理人的身份标游识。

计算框架在本申请实施例中采用的Flink实时计算框架。

同一PNR的不同版本在PNR数据流中并不能保证顺序性和完整性，即可能老版本在新版本的前面达到，可能丢失某些版本，也可能存在一个版本的PNR数据重复发送，因此需要采用版本回溯的方法重建缺失的版本，具体的，借助PNR报文的历史变更部分去重建PNR版本的顺序性和完整性。本申请实施例提供基于版本回溯实现缺失版本重建的内容，具体请参见下文。

在一种可能实现的方式中，所述方法还包括：获取当前PNR版本号和已处理PNR最大版本号；若所述当前PNR版本号满足预设条件，则采用版本回溯的方法重建缺失PNR版本，所述预设条件为所述当前PNR版本号不为001且所述当前PNR版本号和所述已处理PNR最大版本号的差值大于1。

在一种可能实现的方式中，若所述当前PNR版本号大于或者等于所述已处理PNR最大版本号，所述方法还包括：丢弃当前PNR报文版本数据。

从PNR报文版本数据中解析出PNR版本号，全局Map记录已处理PNR对应的最大版本号。如果当前PNR版本号不是001，并且全局记录的最大版本号和当前版本号之间差大于1，则说明有版本缺失，需要通过“版本回溯”重建缺失的版本。如果当前PNR版本号小于等于最大版本号，则直接丢弃当前PNR报文版本数据。

在一种可能实现的方式中，所述对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量，包括：将所述PNR报文版本数据解析成PNR对象流；根据所述PNR对象流确定历史航段状态列表和历史航段旅客数量信息；根据所述历史航段状态列表确定所述航段状态变化数据；根据所述历史航段旅客数量信息确定所述航段旅客数量。

一条PNR报文版本数据能够分解成多条航段数据，形成PNR数据流。净订座量对应的纬度为航段，对PNR报文版本数据进行分解能够有利于后续将航段数据流根据计算窗口，聚合计算净订座量。

S103：采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。

实时计算能够实时掌握销售代理人的净订座量，该处理要求为秒级，随着大数据技术的发展，出现了Spark Streaming、Flink等实时计算框架为海量数据的实时处理提供了技术框架。实时计算包括有三大特征：无限数据、无界数据处理、低延迟。本申请实施例中采用了PNR版本回溯的方法，需要在计算过程中保存中间状态，Flink在支持有状态实时数据流方面支持得更好，所以本申请实施例采用Flink框架作为底层计算框架。

在一种可能实现的方式中，所述航段状态变化数据包括航段状态为确认状态的初始航段量和航段状态从确认状态变为非确认状态的变化航段量，所述采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量，包括：根据所述初始航段量和所述航段旅客数量确定初始订座量；根据所述变化航段量和所述航段旅客数量确定取消订座量；根据所述初始订座量和所述取消订座量确定所述目标净订座量。

航段状态变化数据通过航段库存(Inventory，INV)状态码表现，该航段INV状态码是对航段操作状态码的一个分类，分为K、L、N、X、S五种，分别对应不同的订座和取消订座逻辑，该判定规则详见下述表1，表1为航段INV状态码、航段操作状态码、航段确认状态的判定规则。

表1

初始订座量的＝航段旅客数量×航段INV状态为确认状态的初始航段量；

取消订座量＝航段旅客数量×航段INV状态从确认状态变为非确认状态的变化航段量；

目标净订座量＝初始订座量-取消订座量。

基于上述S101至S103的相关内容可知，获取旅客订座记录PNR报文版本数据；对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。如此，Flink计算框架能够支持有状态实时数据流方面的数据计算，围绕PNR报文版本数据特性，通过对PNR数据流的实时计算，能够计算销售代理人销售量的变化情况，更加快捷的获取到航班预定情况的实时变化情况，满足实时获取航段净订座量的需求。

下面对本申请实施例提供的基于版本回溯实现缺失版本重建进行说明。

参见图2，图2为本申请实施例提供的计算航班净订座量的实施框架图。该实施框架包括四部分，分别为报文解析、版本回溯与重建、分类计算、汇总计算。

参见图3，图3为本申请实施例提供的一种中航信净订座技术架构示意框图。中航信主机将PNR报文版本数据推入MQ消息通道，数据计算应用将数据接入KAFKA，然后通过Flink实时获取数据进行后续解析、加工、净订座量计算，计算结果存储数据库，该应用基于K8S平台运行。基于该技术架构完成净订座量计算、存储及应用。

基于版本回溯实现缺失版本重建之前，可以从主机获取格式为xml的PNR报文版本数据，通过KAFKA消息通道传送。KAFKA作为消息通道一方面能够起到实时数据缓冲的作用，另一方面供助KAFKA产消费机制方面后续计算设计对接。

参见图4，图4为本申请实施例提供的PNR报文版本数据解析示意图。通过流式处理将PNR报文版本数据解析为格式为JAVA的PNR数据流，从PNR数据流中提取关键数据流：PNR基础信息、PNR版本变更信息集合、航段信息集合、旅客信息集合以及代理人信息等关键信息。其中，PNR版本变更信息集合、航段信息集合以及旅客信息集合为版本回重建的前置条件。

解析所有的版本信息，从初始版本001到当前版本的信息解析为PNR版本变更信息集合。解析当前航段与历史航段，每一个航段解析出历史版本号与对应航段操作状态码，记录为航段集合和航段操作状态码集合。解析旅客姓名与历史姓名姓名列表信息，将其处理为键值对，其涉及到每一个版本对应的旅客人数。

以PNR版本号、航空公司、航班号、航班后缀为类别进行分组计算，分组过期时间为该航班的起飞时间，如果超过过期时间，则分许失效。通过Flink缓存机制将每次计算的计算版本存储在Flink缓存中，在下一次计算时，与缓存中的上一次存储的最后一次计算版本进行比对，将上一次到本次未计算的版本全部纳入计算。具体实现为：将当前处理PNR版本号记录或更新入内存进行缓存，用于下次版本比对计算。遍历UpdateList中版本号大于缓存中版本号的所有版本集合数据，得到从上次(不包含上次)到当前版本应纳入版本重建的UpdateList。聚合SegmentList+historySegmentList集合，添加过滤条件，过滤出版本更新列表中未被处理过的列表集合，保留航段版本号小于等于当前update版本号的segmnet集合。

参见图5，图5为本申请实施例中版本回溯重建缺失版本的流程示意图。

通过前述步骤得到符合条件的版本更新列表和航段列表,对版本更新列表进行遍历，以及将航段列表中的每一个航段进行计算转化为航段流，航段流中涉及各版本的重建处理，能够还原出对应版本历史信息，不仅能够计算出当前航段信息，还能够计算出该航段上一个版本的版本号、航段状态、旅客人数、责任Office、确定订座量、取消订座量、分离订座量。

将航段列表与航段历史列表组装为新的航段数据集合，其中，该航段历史列表为PNR前期某种版本下删除掉的航段。遍历该新的航段数据集合，对每一航段对象补全PNR基础属性信息，例如：PNR号、创建版本号、版本创建时间、航班信息、若存在分离PNR，还应补充分离版本号。通过回溯历史信息计算出符合条件的每个update版本下符合条件的航段对应的旅客数量信息，从中求取当前版本当前航段的所有旅客数量，旅客数量小于等于当前update版本号的所有版本旅客数量累加值，例如当前版本号为005，则将姓名集合中001至005的旅客数量进行累加。

求取当前版本当前航段的状态变化信息，获取当前航段的上次状态码，通过历史航段状态列表重建推理计算进而得到状态码变化信息。具体的：histactions中获取上一次ActionCode，但并不是对应的版本均存在ActionCode，向前推，从已有的histactions中获取比当前航段版本小应用版本的ActionCode。

通过上述操作，将会产生每一个版本下每一个航段的对应的旅客数量和航段状态，上一版本对应的旅客数量小于当前本版本号对应的旅客人数累加值。当版本新列表经过上述过程遍历完后，得到符合条件下各版本各航段对应旅客数量、航段状态信息等，并且对从未计算过的版本或者是存在中间版本丢失的情况也可以还原出对应的版本信息，以此通过版本回溯的方法执行版本重建得到净订座计算的核心数据，即通过回溯重建可以解决原始版本或者某段中间版本数据丢失问题，通过信息回溯还原出各版本历史及当前数据信息，得到这些与净订座计算相关联的基础信息后，就可以根据计算模型求净订座量。

上述处理其核心逻辑是将符合版本要求下的数据通过版本回溯重建生成航段流，为后续聚合计算提供前置数据流，上述算法整体归纳为PNR版本回溯算法。

基于上述版本回溯重建得到的PNR数据流进行如下模型分类计算净订座量，具体的明细数据详见表2。

将获得的数据进行汇总计算，参见图6，图6为本申请实施例提供的汇总计算的流程示意图。以管道流方式实时接收以航段为最小单位的实时明细数据，通过FLINK窗口机制，采用滚动窗口聚合计算，同时还可以解决实时数据乱序问题，其中，本申请实施例中并不限定窗口时间大小，可根据实际需求自定义。对于已经起飞的航班，如果PNR取消，不纳入计算，最后按航司或者按Office纬度汇总结果入库。

在处理的过程中，可能存在PNR特殊报文，下面对PNR特殊报文进行说明。

1、航段TK状态调整：调整PNR，主要是处理CreationNum不对的问题，历史状态中的TK版本与航段中TK版本不一致，以历史ActionCode中的为准。

2、PNR分离：得到该PNR分离时的版本号作为该PNR首次创建版本，对于分离的PNR，老的PNR不会再次推送，只会推送新的PNR，并且老的PNR信息进入新的PNR的History中。以下为一种示例。

3、非代理人操作行为：报文中含SYN、ASC标识非代理人操作，不纳入净订座量计算。

(1)对于非代理人操作的步骤，同步回来的航段不进入收费体系，这种报文通过DIP文件中的SYN、ASC判断过滤，不纳入计划。如下PNR，24步为代理人操作，25步为非代理人操作。

(2)对应黑屏主机报文带S标识：

A、产生的原因，KEHHXZ起飞前多天频繁航班变动，即黑屏带‘S’标记。

B、航班变动(黑屏带‘S’标记)所产生的订座量、取消量，不计算在外航的量里。

4、产品实施环境要求：详见下述表3。

表3

本申请实施例中设计了回溯算法解决数据遗漏问题，通过版本重建可以追踪到每一个版本变化信息，充分考虑到了数据迟到、数据乱序、数据重复处理的问题。在计算的过程中，分组计算模型涵盖全面，数据计算准确性高。并且考虑数据流处理机制，可以在任何涉及到PNR的实时场景中使用，比如监控代理人占座是否违规、监控订座后实时为旅客推送租车服务、各代理人实时市场占有率、各航司实时销售量变化信息等场景。

前述本申请实施例提供基于上述的一种航段净订座量的实时获取方法。接下来说明本申请实施例中还提供的一种航段净订座量的实时获取装置，该装置执行前述图1所示的方法，接下来对航段净订座量的实时获取装置的功能进行说明，所述航段净订座量的实时获取装置的结构示意图如图7所示，包括第一获取模块701，分析模块702以及计算模块703。

其中，

第一获取模块701，用于获取旅客订座记录PNR报文版本数据；

分析模块702，用于对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；

计算模块703，用于采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。

在一种可能实现的方式中，所述航段状态变化数据包括航段状态为确认状态的初始航段量和航段状态从确认状态变为非确认状态的变化航段量，所述计算模块703具体用于：

根据所述初始航段量和所述航段旅客数量确定初始订座量；

根据所述变化航段量和所述航段旅客数量确定取消订座量；

根据所述初始订座量和所述取消订座量确定所述目标净订座量。

在一种可能实现的方式中，所述装置还包括：

第二获取模块，用于获取当前PNR版本号和已处理PNR最大版本号；

版本重建模块，用于若所述当前PNR版本号满足预设条件，则采用版本回溯的方法重建缺失PNR版本，所述预设条件为所述当前PNR版本号不为001且所述当前PNR版本号和所述已处理PNR最大版本号的差值大于1。

在一种可能实现的方式中，若所述当前PNR版本号大于或者等于所述已处理PNR最大版本号，所述装置还包括：

丢弃模块，用于丢弃当前PNR报文版本数据。

在一种可能实现的方式中，所述分析模块702具体用于：

将所述PNR报文版本数据解析成PNR对象流；

根据所述PNR对象流确定历史航段状态列表和历史航段旅客数量信息；

根据所述历史航段状态列表确定所述航段状态变化数据；

根据所述历史航段旅客数量信息确定所述航段旅客数量。

本申请实施例提供一种航段净订座量的实时获取装置，该装置包括第一获取模块、分析模块及计算模块。其中第一获取模块，用于获取旅客订座记录PNR报文版本数据；分析模块用于对所述PNR报文版本数据进行分析，得到航段状态变化数据和航段旅客数量；计算模块用于采用Flink计算框架对所述航段状态变化数据和所述航段旅客数量进行计算，得到目标净订座量。如此，Flink计算框架能够支持有状态实时数据流方面的数据计算，围绕PNR报文版本数据特性，通过对PNR数据流的实时计算，能够计算销售代理人销售量的变化情况，更加快捷的获取到航班预定情况的实时变化情况，满足实时获取航段净订座量的需求。

基于上述方法实施例提供的一种航段净订座量的实时获取方法，本申请实施例提供提供一种航段净订座量的实时获取设备，包括：处理器、存储器、系统总线；

所述处理器以及所述存储器通过所述系统总线相连；

所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述任一项实施例所述的航段净订座量的实时获取方法。

基于上述方法实施例提供的一种航段净订座量的实时获取方法，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，当所述指令在设备上运行时，使得所述设备执行上述任一项实施例所述的航段净订座量的实时获取方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。