CN109873873A - 一种航班数据发布系统、航班变更方法及消息处理方法 - Google Patents

Abstract

本发明公开了一种航班数据发布系统，包括航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统，其中：航班运行管理子系统负责航班数据的管理，包括消息路由模块和Webservice模块，消息路由模块将航班数据传送至消息服务子系统；消息服务子系统包括若干消息主题，分类顺序储存航班数据，每一个消息主题将储存的航班数据发布至各下游系统.本发明为航班数据发布提供主、被动高时效、数据一致性、稳定、可靠的数据服务，让下游系统接收端高效、简单、可回溯消息。

Description

一种航班数据发布系统、航班变更方法及消息处理方法

技术领域

本发明涉及航空同步数据技术领域，更具体地，涉及一种航班数据发布系统、航班变更方法及消息处理方法。

背景技术

航班数据发布服务在现有民航领域应用极广，几乎存在每家航空公司内部运行系统中。航空公司业务特点为：制作生产计划——为未来航季(冬春/夏秋)制作长期航班计划，执行航班计划；计划执行过程中，会发生各种不同的航班数据变更，业务上需要关注航班动态变更以实现高效资源调度、避免航班延误、保障航班运行安全、减少各种风险、降低运行成本。各种业务场景需要各种软件系统支持。所以各业务系统和核心航班管理系统存在航班数据交互。

现有的航班管理系统与其他各业务系统数据交互存在各种各样的不足。现有的架构方案有：数据库与数据库直连(系统耦合高，性能差，影响上游核心航班管理系统)，数据定时抓取(实时性不够，不必要空轮询性能开销，耦合高)，CDC数据变更日志分发(自定义差、业务相关性差)，MQ消息推送(航班计划与动态混合影响航班动态实时性，分开多队列下游系统消费复杂且数据不一致性问题大，消费消息后不可朔源)。

发明内容

本发明提供一种航班数据发布系统、航班变更方法及消息处理方法。

本发明的首要目的是提供高性能、高可靠、高可用的航班数据发布系统，解决目前存在的航班数据问题，数据一致性、有序性、可靠性，解决航空企业目前针对航班数据在各种业务系统中差异问题同时满足企业针对航班数据发布服务通用化，简单化。

本发明的进一步目的是提供一种航班变更处理方法。

本发明的第三个目的是提供一种下游系统消息处理方法。

为解决上述技术问题，本发明的技术方案如下：

一种航班数据发布系统，为各下游系统提供航班数据，包括航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统，其中：

航班运行管理子系统负责航班数据的管理，包括消息路由模块和Webservice模块，消息路由模块将航班数据传送至消息服务子系统；

服务网关子系统接收下游系统的服务请求，并从服务注册中心子系统获取认证授权服务地址对请求进行认证与授权，然后从服务注册中心子系统中查找服务基于负载均衡分发到请求对应的实际webservice，最后接收响应数据转发给请求的下游系统。

消息服务子系统包括若干消息主题，每一个消息主题根据航班属性划分为若干个消息分区，分类顺序储存航班数据，每一个消息主题将储存的航班数据发布至各下游系统；

所述航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统均采用多节点集群。

消息服务子系统中消息主题的消息分区采用航班相关属性分类存储，提高了系统并发性能以及系统响应的实时性，设计独特的数据结构，基于航班信息特殊业务场景，实现航班数据发布服务通用性，屏蔽航班数据接收端实现的复杂性，解决了数据定时抓取实时性不足的缺陷。上述航班数据分发分两种方式：主动和被动，主动为webservice，由下游系统发起，并根据航班计划和航班动态划分两个接口；被动方式基于可回溯MQ(Kafka)技术，并行推送航班计划和航班动态，下游系统接收消息并处理，解决了MQ消息推送消息不可回溯的缺陷；下游系统包括机组系统、乘务系统和其它系统。

优选地，航班属性为机型或航班号或航班日期或航班计划起飞时间或起飞机场或到达机场。

优选地，若干消息主题中其中一个消息主题为第一消息主题，所述第一消息主题存储其它消息主题中每日首班航班消息的存储位置及对应航班日期，方便定位消息并回溯，其它消息主题依次存储不同时间段对应的航班数据以及对应的航班变更数据，因下游系统只接受不同时间段的航班数据而配置消息主题，每个消息主题即便超过时间范围之前的航班变更也将推送以保证数据的一致性。

优选地，若干消息分区中的每一个消息分区配置独立存储器，提高数据读写性能，解决了数据库与数据库直连中性能差的缺陷。

优选地，航班信息以航班日期或航班计划起飞时间顺序追加存入消息主题，对应的航班变更数据按变更先后顺序存入消息主题，因航班计划数据量过大，航班信息采用分批次间隔追加存入消息主题，航班变更数据实时或近实时追加存入消息主题，提高正在运行的航班变更数据推送实时性，近实时是指通过自动数据处理或网络传输在事件发生和使用之间引入的时间延迟，近实时的延迟通常为几秒到几分钟。

优选地，Webservice模块提供航班计划查询接口、航班变更查询接口、消息分区位置查询接口和消息分区位置查询接口，其中：

航班计划查询接口根据下游系统的指定返回航班数据记录列表；

航班变更查询接口根据下游系统的指定返回航班变更记录列表。

消息分区位置查询接口根据下游系统的指定返回航班日期、位置信息列表。

提供了丰富的自定义的数据变更项，克服了CDC数据变更日志分发中自定义差、业务相关性差的缺陷。

实现时根据航班日期、变更数据项查询变更数据，以航班ID、变更时间戳相同的变更数据项组成航班变更记录。

根据上述的航班数据发布系统的航班变更方法，包括以下步骤：

S01：航班运行管理子系统收到新增、修改航班数据的请求，持久化航班变更记录，同时航班运行管理子系统在后台线程的控制下定时检查未发布的航班变更记录并发布；

S02：查询该航班未发布的航班变更记录，为了防止集群多节点同时处理，也为了防止系统意外宕机造成数据未发布；

S03：由消息路由将航班变更记录通过消息分区数定义配合消息路由算法存储至指定的消息分区；

S04：更新航班变更记录，并发布至下游系统中。

优选地，消息路由算法将航班计划起飞时间按12个月份或每月31天或24小时或60分钟时间单位组合方式路由至消息分区，提高并发能力。

优选地，一种根据上述航班数据发布系统的下游系统消息处理方法，包括以下步骤：

S11：下游系统是否需要指定航班日期对应的位置信息，若需要，则通过消息分区位置查询接口或者通过第一消息主题获取指定航班日期消息分区位置并从指定消息分区位置获取信息；若不需要，从上次下游系统终止的消息分区位置获取消息或从原始消息分区位置获取消息；

S12：以多线程方式将下游系统需要的消息反馈给下游系统；

S13：下游系统检测航班信息是否已经存在，若不存在，新增航班信息并回复消息服务子系统完成确认；若存在且航班变更时间大于下游系统存储的变更时间，修改航班信息并回复消息服务子系统完成确认，若存在且航班变更时间不大于下游系统存储的变更时间，放弃修改；记录下游系统终止消费消息位置并返回步骤S12。

处理过程中提供数据重复的容错性，保证数据正确与一致性。

与现有技术相比，本发明技术方案的有益效果是：

本发明通过构建一个分布式航班数据发布系统，为航班数据发布提供主、被动高时效、数据一致性、稳定、可靠的数据服务，让下游系统接收端高效、简单、可回溯消息，并根据下游系统需要选择webservice或者MQ消息方式，统一初始化航班以及航班变更数据发布。同时可以通用化覆盖航空领域航班数据发布需求。

附图说明

图1为一种航班数据发布系统架构图。

图2为实施例中消息主题示意图。

图3为实施例中航班变更方法的流程图。

图4为实施例中下游系统信息处理方法的流程图

具体实施方式

附图仅用于示例性说明，不能理解为对本专利的限制；

为了更好说明本实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；

对于本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

下面结合附图和实施例对本发明的技术方案做进一步的说明。

实施例1

一种航班数据发布系统，为各下游系统提供航班数据，如图1，包括航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统，其中：

航班运行管理子系统负责航班数据的管理，包括消息路由模块和Webservice模块，消息路由模块将航班数据传送至消息服务子系统；

服务网关子系统接收下游系统的服务请求，并从服务注册中心子系统获取认证授权服务地址对请求并从认证授权子系统中获得认证与授权，然后从服务注册中心子系统中查找服务请求所对应的webservice地址，最后响应数据给请求的下游系统；

消息服务子系统包括若干消息主题，每一个消息主题根据航班属性划分为若干个消息分区，分类顺序储存航班数据，每一个消息主题将储存的航班数据发布至各下游系统；

所述航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统均采用多节点集群。

所述航班属性为机型或航班号或航班日期或航班计划起飞时间或起飞机场或到达机场。

所述若干消息主题中的第一消息主题存储其它消息主题对应航班日期对应的航班数据存储位置，其它消息主题依次存储不同时间段对应的航班数据以及对应的航班变更数据。如图2所示，其中D表示当天，D-2表示当天前两天，D+2表示当天后两天，D+∞表示系统最大航班日期，采用D-n到D+m，n、m为非负整数，发布消息。

若干消息分区中的每一个消息分区配置独立存储器。

航班信息以航班日期或航班计划起飞时间顺序追加存入消息主题，对应的航班变更数据按变更先后顺序存入消息主题，航班信息采用分批次间隔追加存入消息主题，航班变更数据实时或近实时追加存入消息主题，如表3所示。

Webservice模块提供航班计划查询接口、航班变更查询接口、消息分区位置查询接口和消息分区位置查询接口，其中：

航班计划查询接口根据下游系统的指定返回航班数据记录列表；

具体的参数包括开始航班日期、结束航班日期，且在航班日期时间段不允许超过固定天数，如果超过固定天数，返回警告。

航班变更查询接口根据下游系统的指定返回航班变更记录列表；

具体的参数包括开始航班日期、结束航班日期、上次最后变更时间戳，且在航班日期时间段大于固定天数时，变更记录超过固定天数，返回警告。

消息分区位置查询接口根据下游系统的指定返回航班日期、位置信息列表。

具体的参数包括开始航班日期、结束航班日期，且在航班日期时间段不允许超过固定天数，如果超过固定天数，返回警告。

航班变更查询接口根据下游系统的指定返回航班变更记录列表；

表1

数据项名称	类型	说明
			主键ID	字符串或者数值	系统内变更记录唯一编码
航班主键	字符串或者数值	航班唯一编码
			航班日期	日期类型/时间	航班计划起飞日期或者航班计划起飞时间
变更项	字符串	航班属性(比如机型、机号、起降机场等)
			变更前值	字符串	原始值(原始无值则为空)
变更后值	字符串	更改后的值
			变更时间戳	时间	精确到毫秒甚至微秒、皮秒等更高精度
发布状态	整数数值	以二进制一位的0或者1表示发布到对应消息主题上

表2

表3

航班变更(航班计划1、2、……n变更)
	航班计划n
……
	……
航班变更(航班计划1、2变更)
	航班计划2
航班变更(航班计划1变更)
	航班计划1

具体的参数包括开始航班日期、结束航班日期、上次最后变更时间戳，且在航班日期时间段大于固定天数时，变更记录超过固定天数，返回警告。

其中航班变更关键数据项，如表1所示，用于Webservice服务数据发布，也用于MQ信息推送，表2为航班变更关键数据项的一个实例。

实施例2

本实施例基于实施例1提供的航班数据发布系统提出一种航班变更方法，如图3，包括以下步骤：

S01：航班运行管理子系统收到新增、修改航班数据的请求，持久化航班变更记录，同时航班运行管理子系统在后台线程的控制下定时检查未发布的航班变更记录并发布；

S02：查询该航班未发布的航班变更记录，为了防止集群多节点同时处理，也为了防止系统意外宕机造成数据未发布；

S03：由消息路由将航班变更记录通过消息分区数以及消息路由算法存储至指定的消息分区；

S04：更新航班变更记录，并发布至下游系统中。

消息路由算法将航班计划起飞时间按12个月份或每月31天或24小时或60分钟时间单位组合方式路由至消息分区，提高并发能力。

实施例3

本实施例基于实施例1提供的航班数据发布系统提出一种下游系统消息处理方法，如图4，包括以下步骤：

S11：下游系统是否需要指定航班日期对应的位置信息，若需要，则通过消息分区位置查询接口或者通过第一消息主题获取指定航班日期消息分区位置并从指定消息分区位置获取信息；若不需要，从上次下游系统终止消息分区位置获取消息或从原始消息分区位置获取消息；

S12：以多线程方式将下游系统需要的消息反馈给下游系统；

S13：检测航班信息是否存在于下游系统中，若不存在，新增航班信息并回复消息服务子系统确认消费信息；若存在且航班变更时间大于下游系统存储的变更时间，修改航班信息并回复消息服务子系统确认消费信息，若存在且航班变更时间不大于下游系统存储的变更时间，放弃修改；记录下游系统终止消费消息位置并返回步骤S12。

相同或相似的标号对应相同或相似的部件；

附图中描述位置关系的用语仅用于示例性说明，不能理解为对本专利的限制；

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。

Claims (10)

1.一种航班数据发布系统，为各下游系统提供航班数据，其特征在于，包括航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统，其中：

航班运行管理子系统负责航班数据的管理，包括消息路由模块和Webservice模块，消息路由模块将航班数据传送至消息服务子系统；

服务网关子系统接收下游系统的服务请求，并从服务注册中心子系统获取认证授权服务地址对请求进行认证与授权，然后从服务注册中心子系统中查找服务请求所对应的webservice地址，转发请求到实际webservice，webservice返回的数据经服务网关返回给请求的下游系统；

消息服务子系统包括若干消息主题，每一个消息主题根据航班属性划分为若干个消息分区，分类顺序储存航班数据，每一个消息主题将储存的航班数据发布至各下游系统；

所述航班运行管理子系统、消息服务子系统、认证授权子系统、服务注册中心子系统和服务网关子系统均采用多节点集群。

2.根据权利要求1所述的航班数据发布系统，其特征在于，所述航班属性为机型或航班号或航班日期或航班计划起飞时间或起飞机场或到达机场。

3.根据权利要求2所述的航班数据发布系统，其特征在于，所述若干消息主题中其中一个消息主题为第一消息主题存储，所述第一消息主题存储其它消息主题中每日首班航班消息的存储位置及对应航班日期；其它消息主题依次存储不同时间段对应的航班数据以及对应的航班变更数据。

4.根据权利要求3所述的航班数据发布系统，其特征在于，所述若干消息分区中的每一个消息分区配置独立存储器。

5.根据权利要求3或4所述航班数据发布系统，其特征在于，航班信息以航班日期或航班计划起飞时间顺序追加存入消息主题，对应的航班变更数据按变更先后顺序存入消息主题，航班信息采用分批次间隔追加存入消息主题，航班变更数据实时或近实时追加存入消息主题，所述的近实时指通过自动数据处理或网络传输在事件发生和使用之间引入的时间延迟。

6.根据权利要求5所述的航班数据发布系统，其特征在于，Webservice模块提供航班计划查询接口、航班变更查询接口和消息分区位置查询接口，其中：

航班计划查询接口根据下游系统的指定返回航班数据记录列表；

航班变更查询接口根据下游系统的指定返回航班变更记录列表。

7.根据权利要求6所述的航班数据发布系统，其特征在于，Webservice模块还提供消息分区位置查询接口，所述消息分区位置查询接口根据下游系统的指定返回航班日期、位置信息列表，下游系统也可以采用MQ，消费位置消息队列获取航班航班日期、位置信息列表。

8.根据权利要求7所述的航班数据发布系统的航班变更方法，其特征在于，包括以下步骤：

S01：航班运行管理子系统收到新增、修改航班数据的请求，持久化航班变更记录，通知发布变更数据，同时航班运行管理子系统在后台线程的控制下定时检查未发布的航班变更记录并发布，保证发布失败重新发布；

S02：接收通知并查询该航班未发布的航班变更记录，如航班从未发布则发布整条航班信息；

S03：由消息路由将航班变更记录通过定义的消息分区与消息路由算法存储至指定的消息分区；

S04：更新航班变更记录或者更新航班发布状态，并发布至下游系统中。

9.根据权利要求8所述的航班数据发布系统的航班变更方法，其特征在于，所述的消息路由算法将航班计划起飞时间按12个月份或每月31天或24小时或60分钟时间单位组合方式路由至消息分区。

10.根据权利要求7所述的航班数据发布系统的下游系统消息处理方法，其特征在于，包括以下步骤：

S11：下游系统是否需要指定航班日期对应的位置信息，若需要，则通过消息分区位置查询接口或者通过第一消息主题获取指定航班日期消息分区位置并从指定消息分区位置获取信息；若不需要，从上次下游系统终止消息分区位置获取消息或从原始消息分区位置获取消息；

S12：以多线程方式将下游系统需要的消息反馈给下游系统；

S13：下游系统检测航班信息是否已经存在，若不存在，新增航班信息并回复消息服务子系统确认消费信息；若存在且航班变更时间大于下游系统存储的变更时间，修改航班信息并回复消息服务子系统确认消费信息，若存在且航班变更时间不大于下游系统存储的变更时间，放弃修改；记录下游系统消息消费位置并返回步骤S12。