一种差旅平台的主动缓存方法、差旅查询方法和相关产品与流程

本申请涉及网络和计算机技术领域，尤其涉及一种差旅平台的主动缓存方法、差旅查询方法和相关产品。

背景技术：

随着旅游业和网络的发展，出现了在线旅行社(onlinetravelagency，ota)和商旅管理公司(travelmanagementcompanies，tmc)等旅行信息服务商，旅游信息服务商可以为用户提供差旅查询和订票服务。

使用应用于差旅运输及旅游业的大型计算机信息服务系统(比如，全球分销系统(globaldistributionsystem，gds))可以及时从运输公司、旅馆、租车公司、旅游公司等获取大量的差旅信息，所述计算机信息服务系统在本申请中统称为供应商，供应商可以为顾客提供快捷、便利、可靠的差旅信息和服务。差旅对应的出行方式可以包括如下一种或者多种：乘坐飞机、乘坐高铁、乘坐汽车或者乘坐轮船等。在本申请的后续描述中，以乘坐飞机的出行方式为例进行描述，其他出行方式与乘坐飞机的出行方式类似，不再一一举例和描述。

在进行机票查询时，用户可以通过旅行信息服务商的平台搜索航线信息。当众多用户同时查询时，高查询量会给供应商带来巨大的压力，也会造成响应延迟，影响用户体验。比如，一个国际航线的查询请求中包含100条航班信息，而这100条航班都需要通过实时访问的方式获取信息，最终信息获取的时间取决于耗时最长的请求，从用户的角度，查询到页面展示的时间需要20秒以上。

为了降低供应商的压力，目前平台通常采用主动缓存查询和被动的实时查询相结合的方式进行机票查询。

主动缓存是预先预测用户最有可能查询的差旅线，按照预先配置的刷新策略向供应商发送查询请求，并将获取的相关信息存储在缓存中。被动的实时查询是根据查询条件向供应商发起实时获取请求的查询方式。

在进行查询时，若用户的查询与缓存中的信息匹配，则为主动缓存命中。主动缓存命中时，平均查询页面显示时长在1至4秒以内；若未命中，则发送实时查询请求至供应商，获取差旅信息，平均查询页面显示时长在20s以上。

目前主动缓存主要是由对所有用户的查询信息进行处理确定，经实践发现现有技术中的主动缓存命中率较低。

技术实现要素：

本申请实施例提供了一种差旅平台的主动缓存方法、差旅查询方法和相关产品，有利于提升主动缓存命中率。

第一方面，本申请实施例提供了一种差旅平台的主动缓存方法，包括：在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息；根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线，所述差旅线包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线；根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，并根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中，这样有利于提升缓存中的数据与用户查询操作的匹配性以及因公查询时主动缓存的命中率，进而提升用户体验。

基于第一方面，在本申请一些可能的实施方式中，所述方法还包括：根据因私预测策略预测第一信息；所述第一信息包括：因私搜索的热门差旅线和所述热门差旅线的刷新频率；根据所述第一信息获取所述热门差旅线对应的数据并保存到所述缓存中。

在一些可能的实施方式中，可以在每天指定时刻执行因私预测策略，指定时刻比如可以是每天的零点执行因私预测策略。

在一些可能的实施方式中，所述第一信息还可以包括：从所述供应商刷新次数的上限。从供应商刷新次数的上限是指从供应商获取查询数据时的次数的上限。举例来说，在第一信息中可以包括：从供应商a刷新次数的上限为2万次每天，则每天从供应商a获取查询数据的次数的上限为2万次。

本申请实施例提供的技术方案，对因私预测策略进行了描述。按照预测得到的第一信息，从供应商获取热门差旅线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

基于第一方面，在本申请一些可能的实施方式中，所述根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线，包括：从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

本申请实施例提供的技术方案，对因公查询时预测主动缓存差旅线的方法进行了描述，根据从因公数据库中获取的用户的历史差旅信息预测与用户未启程的差旅信息匹配的因公主动缓存差旅线。根据历史差旅信息可以得到用户的偏好，这样预测的因公主动缓存差旅线与用户可能的搜索操作更加匹配，因此有利于提高主动缓存的命中率。

基于第一方面，在本申请一些可能的实施方式中，所述根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线，还包括：在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

本申请实施例提供的技术方案，在因公数据库中没有用户的历史差旅信息时，根据因公数据库中其他用户的历史差旅信息确定其他用户的偏好信息，根据其他用户的偏好信息预测因公主动缓存差旅线，采用该实施方式有利于提高因公主动缓存的命中率。

基于第一方面，在本申请一些可能的实施方式中，所述根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中，包括：在所述因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，对因公主动缓存差旅线的刷新频率进行了限定，通过实时从供应商获取因公主动缓存差旅线对应的数据，使得缓存中因公主动缓存差旅线对应的数据可以及时更新，有利于降低验仓失败率。

基于第一方面，在本申请一些可能的实施方式中，在预测所述热门差旅线的刷新频率方面，所述因私预测策略具体包括：根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率。

在一些可能的实施方式中，根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率，可以包括：根据所述热门差旅线的固定时间段内历史变化次数预测当天所述热门航线固定时间段内的变化次数，根据预测得到的当天固定时间段内所述热门航线的变化次数，确定固定时间段内当天所述热门航线的热门值，根据所述热门航线的热门值确定当天固定时间段内热门航线的刷新频率。可以理解的是，热门值越靠前刷新频率越高。

本申请实施例提供的技术方案，对因私主动刷新频率进行了限定，根据所述热门差旅线的历史变化次数确定当天所述热门差旅线的刷新频率，这样可以优化刷新频率，使得刷新频率的设置与热门差旅线的变化更匹配，有利于降低验仓失败率。

基于第一方面，在本申请一些可能的实施方式中，在预测所述供应商刷新次数的上限方面，所述因私预测策略具体包括：根据所述供应商的历史旅客订座记录(passengernamerecord，pnr)数，预测所述供应商的pnr数，结合所述供应商的查订比和预测得到的所述供应商的pnr数，确定所述供应商刷新次数的上限。

本申请实施例提供的技术方案，根据供应商的历史pnr数及查订比确定供应商刷新次数的上限，有利于降低查询成本。

第二方面，本申请实施例提供了一种差旅查询方法，包括：在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息；根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线；所述差旅线包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线；根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，并根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中，这样有利于提升缓存中的数据与用户查询操作的匹配性以及因公查询时主动缓存的命中率，进而提升用户体验。

基于第二方面，在本申请一些可能的实施方式中，差旅查询还可以包括：根据因私预测策略预测第一信息；所述第一信息包括：因私搜索的热门差旅线和所述热门差旅线的刷新频率；根据所述第一信息获取所述热门差旅线对应的数据并保存到所述缓存中。

在一些可能的实施方式中，可以在每天指定时刻执行因私预测策略，指定时刻比如可以是每天的零点执行因私预测策略。

在一些可能的实施方式中，所述第一信息还可以包括：从所述供应商刷新次数的上限。

本申请实施例提供的技术方案，对因私预测策略进行了描述。按照预测得到的第一信息，从供应商获取热门差旅线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

基于第二方面，在本申请一些可能的实施方式中，在所述根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中之后，所述方法还包括：在所述用户触发因公查询界面中的因公查询操作时，在所述缓存中查找是否有与所述因公查询操作匹配的数据；若是，则显示所述与所述因公查询操作匹配的数据；若否，则根据查询条件向供应商发起第一实时查询请求，获取并显示与所述第一实时查询请求匹配的因公被动缓存差旅线对应的数据，以及根据因公被动刷新策略从所述供应商获取所述因公被动缓存差旅线对应的数据并保存到所述缓存中。

本申请实施例提供的技术方案，在根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中之后，在用户触发因公查询操作时，若缓存中查找到与因公查询操作匹配的数据，则显示与因公查询操作匹配的数据；若缓存中没有查找到与因公查询操作匹配的数据，则根据查询条件向供应商发起获取请求，获取并显示与获取请求匹配的因公被动缓存差旅线对应的数据，以及根据因公被动刷新策略从供应商获取因公被动缓存差旅线对应的数据并保存到所述缓存中。这样，有利于在因公查询时，在缓存与查询操作匹配时，及时查询到需要的信息；同时，在缓存与查询操作不匹配时，可以保证用户查询到需要的信息。

基于第二方面，在本申请一些可能的实施方式中，在查询入口为因私查询入口时，所述方法还包括：在所述用户触发因私查询界面中的因私查询操作时，在所述缓存中查找是否有与所述因私查询操作匹配的数据；若是，则显示所述与所述因私查询操作匹配的数据；若否，则根据查询条件向供应商发起第二实时查询请求，获取并显示与所述第二实时查询请求匹配的因私被动缓存差旅线对应的数据，以及根据因私被动刷新策略从所述供应商获取所述因私被动缓存差旅线对应的数据并保存到所述缓存中。

本申请实施例提供的技术方案，对查询入口为因私查询入口时的情况进行了描述，在用户触发因私查询界面中的因私查询操作时，在缓存中查找是否有与因私查询操作匹配的数据；若是，则显示与因私查询操作匹配的数据；若否，则根据查询条件向供应商发起第二实时查询请求，获取并显示与第二实时查询请求匹配的因私被动缓存差旅线对应的数据，以及根据因私被动刷新策略从供应商获取因私被动缓存差旅线对应的数据并保存到缓存中。这样有利于在因私查询时，在主动缓存与查询操作匹配时，可以及时查询到需要的信息；同时，在主动缓存与查询操作不匹配时，可以保证用户查询到需要的信息。

基于第二方面，在本申请一些可能的实施方式中，所述根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线，包括：从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

本申请实施例提供的技术方案，对因公查询时预测主动缓存差旅线的方法进行了描述，根据从因公数据库中获取的用户的历史差旅信息预测与用户未启程的差旅信息匹配的因公主动缓存差旅线。根据历史差旅信息可以得到用户的偏好，这样预测的因公主动缓存差旅线与用户可能的搜索操作更加匹配，因此有利于提高主动缓存的命中率。

基于第二方面，在本申请一些可能的实施方式中，所述根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线，还包括：在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

本申请实施例提供的技术方案，在因公数据库中没有用户的历史差旅信息时，根据因公数据库中其他用户的历史差旅信息确定其他用户的偏好信息，根据其他用户的偏好信息预测因公主动缓存差旅线，采用该实施方式有利于提高因公主动缓存的命中率。

基于第二方面，在本申请一些可能的实施方式中，所述根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中，包括：在所述因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，对因公主动缓存差旅线的刷新频率进行了限定，通过实时从供应商获取因公主动缓存差旅线对应的数据，使得缓存中因公主动缓存差旅线对应的数据可以及时更新，有利于降低验仓失败率。

基于第二方面，在本申请一些可能的实施方式中，在预测所述热门差旅线的刷新频率方面，所述因私预测策略具体包括：根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率。

在一些可能的实施方式中，根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率，可以包括：根据所述热门差旅线的固定时间段内历史变化次数预测当天所述热门差旅线固定时间段内的变化次数，根据预测得到的当天固定时间段内所述热门差旅线的变化次数，确定固定时间段内当天所述热门差旅线的热门值，根据所述热门差旅线的热门值确定当天固定时间段内热门差旅线的刷新频率。可以理解的是，热门值越靠前刷新频率越高。

本申请实施例提供的技术方案，对因私主动刷新频率进行了限定，根据所述热门差旅线的历史变化次数确定当天所述热门差旅线的刷新频率，这样可以优化刷新频率，使得刷新频率的设置与热门差旅线的变化更匹配，有利于降低验仓失败率。

基于第二方面，在本申请一些可能的实施方式中，在预测所述供应商刷新次数的上限方面，所述因私预测策略具体包括：根据所述供应商的历史旅客订座记录pnr数，预测所述供应商的pnr数，结合所述供应商的查订比和预测得到的所述供应商的pnr数，确定所述供应商刷新次数的上限。

本申请实施例提供的技术方案，根据供应商的历史pnr数及查订比确定供应商刷新次数的上限，有利于降低查询成本。

第三方面，本申请实施例提供了一种主动缓存装置，包括：第一获取单元，用于在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息；第一预测单元，用于根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线，所述差旅线包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线；第一处理单元，用于根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，并根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中，这样有利于提升缓存中的数据与用户查询操作的匹配性以及因公查询时主动缓存的命中率，进而提升用户体验。

基于第三方面，在本申请一些可能的实施方式中，还包括：第二预测单元，用于根据因私预测策略预测第一信息；所述第一信息包括：因私搜索的热门差旅线和所述热门差旅线的刷新频率；第二处理单元，用于根据所述第一信息获取所述热门差旅线对应的数据并保存到所述缓存中。

在一些可能的实施方式中，第二预测单元可以在每天指定时刻执行因私预测策略，指定时刻比如可以是每天的零点执行因私预测策略。

在一些可能的实施方式中，所述第一信息还可以包括：从所述供应商刷新次数的上限。

本申请实施例提供的技术方案，对因私预测策略进行了描述。按照预测得到的第一信息，从供应商获取热门差旅线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

基于第三方面，在本申请一些可能的实施方式中，所述第一预测单元具体用于，从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

本申请实施例提供的技术方案，对因公查询时预测主动缓存差旅线的方法进行了描述，根据从因公数据库中获取的用户的历史差旅信息预测与用户未启程的差旅信息匹配的因公主动缓存差旅线。根据历史差旅信息可以得到用户的偏好，这样预测的因公主动缓存差旅线与用户可能的搜索操作更加匹配，因此有利于提高主动缓存的命中率。

基于第三方面，在本申请一些可能的实施方式中，所述第一预测单元具体还用于，在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

本申请实施例提供的技术方案，在因公数据库中没有用户的历史差旅信息时，根据因公数据库中其他用户的历史差旅信息确定其他用户的偏好信息，根据其他用户的偏好信息预测因公主动缓存差旅线，采用该实施方式有利于提高因公主动缓存的命中率。

基于第三方面，在本申请一些可能的实施方式中，所述第一处理单元具体用于，在所述因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，对因公主动缓存差旅线的刷新频率进行了限定，通过实时从供应商获取因公主动缓存差旅线对应的数据，使得缓存中因公主动缓存差旅线对应的数据可以及时更新，有利于降低验仓失败率。

基于第三方面，在本申请一些可能的实施方式中，在预测所述热门差旅线的刷新频率方面，所述第二预测单元具体用于，根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率。

在一些可能的实施方式中，在根据所述热门差旅线的历史变化次数确定所述热门差旅线的刷新频率方面，所述第二预测单元具体可以用于根据所述热门差旅线的固定时间段内历史变化次数预测所述热门差旅线固定时间段内的变化次数，根据预测得到的固定时间段内所述热门差旅线的变化次数，确定固定时间段内所述热门差旅线的热门值，根据所述热门差旅线的热门值确定固定时间段内热门差旅线的刷新频率。可以理解的是，热门值越靠前刷新频率越高。

本申请实施例提供的技术方案，对因私主动刷新频率进行了限定，根据所述热门差旅线的历史变化次数确定热门差旅线的刷新频率，这样可以优化刷新频率，使得刷新频率的设置与热门差旅线的变化更匹配，有利于降低验仓失败率。

基于第三方面，在本申请一些可能的实施方式中，在预测所述供应商刷新次数的上限方面，所述第二预测单元具体用于，根据所述供应商的历史pnr数，预测所述供应商的pnr数，结合所述供应商的查订比和预测得到的所述供应商的pnr数，确定所述供应商刷新次数的上限。

本申请实施例提供的技术方案，根据供应商的历史pnr数及查订比确定供应商刷新次数的上限，有利于降低查询成本。

第四方面，本申请实施例提供了一种机票查询装置，包括：第一获取单元，用于在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息；第一预测单元，用于根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线；所述差旅线包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线；第一处理单元，用于根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，并根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，这样有利于提升缓存中的数据与用户操作的匹配性和因公查询时主动缓存的命中率，进而提升用户体验。

基于第四方面，在本申请一些可能的实施方式中，还包括：第二预测单元，用于根据因私预测策略预测第一信息，所述第一信息包括：因私搜索的热门差旅线和所述热门差旅线的刷新频率；第二处理单元，用于根据所述第一信息获取所述热门差旅线对应的数据并保存到所述缓存中。

本申请实施例提供的技术方案，对因私预测策略进行了描述。按照预测得到的第一信息，从供应商获取热门差旅线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

基于第四方面，在本申请一些可能的实施方式中，可以在每天指定时刻执行因私预测策略，指定时刻比如可以是每天的零点执行因私预测策略。

在一些可能的实施方式中，所述第一信息还可以包括：从所述供应商刷新次数的上限。

本申请实施例提供的技术方案，对因私预测策略进行了描述。按照预测得到的第一信息，从供应商获取热门差旅线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

基于第四方面，在本申请一些可能的实施方式中，还包括：第一显示单元，用于所述第一处理单元根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中之后，在所述用户触发因公查询界面中的因公查询操作、并且在所述缓存中查找到与所述因公查询操作匹配的数据时，显示所述与所述因公查询操作匹配的数据；以及，在所述缓存中没有查找到与所述因公查询操作匹配的数据、并且在根据查询条件向供应商发起第一实时查询请求之后，显示与所述第一实时请求匹配的因公被动缓存差旅线对应的数据。

本申请实施例提供的技术方案，在根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中之后，在用户触发因公查询操作时，若缓存中查找到与因公查询操作匹配的数据，则显示与因公查询操作匹配的数据；若缓存中没有查找到与因公查询操作匹配的数据，则根据查询条件向供应商发起获取请求，获取并显示与获取请求匹配的因公被动缓存差旅线对应的数据，以及根据因公被动刷新策略从供应商获取因公被动缓存差旅线对应的数据并保存到所述缓存中。这样，有利于在因公查询时，在缓存与查询操作匹配时，及时查询到需要的信息；同时，在缓存与查询操作不匹配时，可以保证用户查询到需要的信息。

基于第四方面，在本申请一些可能的实施方式中，还包括：第二显示单元，用于在查询入口为因私查询入口并且所述用户触发因私查询界面中的因私查询操作时，显示所述缓存中与所述因私查询操作匹配的数据；以及在缓存中若没有与因私查询操作匹配的数据、并且在根据查询条件向供应商发起第二实时查询请求之后，显示与所述第二实时查询请求匹配的因私被动缓存差旅线对应的数据。

本申请实施例提供的技术方案，对查询入口为因私查询入口时的情况进行了描述，在用户触发因私查询界面中的因私查询操作时，在缓存中查找是否有与因私查询操作匹配的数据；若是，则显示与因私查询操作匹配的数据；若否，则根据查询条件向供应商发起第二实时查询请求，获取并显示与第二实时查询请求匹配的因私被动缓存差旅线对应的数据，以及根据因私被动刷新策略从供应商获取因私被动缓存差旅线对应的数据并保存到缓存中。这样有利于在因私查询时，及时显示需要的信息。

基于第四方面，在本申请一些可能的实施方式中，在根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线方面，所述第一预测单元具体用于：从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

基于第四方面，在本申请一些可能的实施方式中，在根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线方面，所述第一预测单元具体还用于：在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

基于第四方面，在本申请一些可能的实施方式中，在根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中方面，第一处理单元具体用于，在所述因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

基于第四方面，在本申请一些可能的实施方式中，在预测所述热门差旅线的刷新频率方面，第二预测单元具体用于：根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率。

基于第四方面，在本申请一些可能的实施方式中，在预测所述供应商刷新次数的上限方面，所述因私预测策略具体包括：根据所述供应商的历史旅客订座记录pnr数，预测所述供应商的pnr数，结合所述供应商的查订比和预测得到的所述供应商的pnr数，确定所述供应商刷新次数的上限。

本申请实施例提供的技术方案，根据供应商的历史pnr数及查订比确定供应商刷新次数的上限，有利于降低查询成本。

第五方面，本申请实施例提供了一种差旅平台，包括：通信接口、处理器、存储器和总线，其中，所述通信接口，用于接收来自客户端的差旅查询操作以及与出差申请平台进行通讯；所述存储器，用于存储可执行程序代码；所述处理器，用于通过读取所述存储器中存储的所述可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行第一方面的任意一种方法的部分或全部步骤或者用于执行第二方面的任意一种方法的部分或全部步骤。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，并根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中，这样有利于提升缓存中的数据与用户查询操作的匹配性以及因公查询时主动缓存的命中率，进而提升用户体验。

第六方面，本申请实施例提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被硬件执行第一方面的任意一种方法的部分或全部步骤或者第二方面的任意一种方法的部分或全部步骤。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，并根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中，这样有利于提升缓存中的数据与用户查询操作的匹配性以及因公查询时主动缓存的命中率，进而提升用户体验。

附图说明

下面将对本申请实施例涉及的一些附图进行说明。

图1是本申请实施例提供的进行差旅查询时的系统架构示意图。

图2a是本申请一个实施例提供的差旅平台的主动缓存方法的流程示意图。

图2b是本申请另一实施例提供的差旅平台的主动缓存方法的流程示意图。

图3a是本申请一个实施例提供的差旅查询方法的交互流程示意图。

图3b是采用图3a所示差旅查询方法前后主动缓存命中率示意图。

图3c是采用图3a所示差旅查询方法前后平均查询耗时示意图。

图3d是采用图3a所示差旅查询方法前后主动缓存命中率示意图。

图4a是本申请一个实施例提供的主动缓存装置的结构示意图。

图4b是本申请另一实施例提供的主动缓存装置的结构示意图。

图5a是本申请一个实施例提供的差旅查询装置的结构示意图。

图5b是本申请另一实施例提供的差旅查询装置的结构示意图。

图6是本申请一个实施例提供的差旅平台的结构示意图。

具体实施方式

下面结合本申请实施例中的附图对本申请实施例进行描述。

首先，请参见图1，图1是本申请实施例提供的一种差旅系统的结构示意图，差旅系统可以包括：通过网络互连的差旅平台101、供应商102和出差申请平台103。用户100通过差旅平台101可以进行查询和订票等操作。

其中，差旅平台101可以是提供给特定用户(比如提供给企业)的专业差旅管理服务平台。供应商102可以是全球分销系统gds，比如gds可以是应用于民用航空运输、高铁运输、汽车客运、轮船运输等一种或者多种出行方式及整个旅游业的大型计算机信息服务系统。通过gds，遍及全球的旅游销售机构可以及时从交通运输公司、旅馆、租车公司、旅游公司获取大量的与旅游相关的信息，从而为顾客提供快捷、便利、可靠的服务。出差申请平台103是应用在企业中的出差申请和审批平台，在出差申请平台103中保存有用户的历史差旅信息、出差申请、已审批通过未启程的差旅信息等。当然差旅平台的模块架构并不限于上述举例。

本申请实施例的技术方案可以基于图1举例所示架构的差旅系统或其形变架构来具体实施。

参见图2a，图2a是本申请实施例提供的一种差旅平台的主动缓存方法的流程示意图，这种方法可包括但不限于如下步骤。

201、在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息。

其中，用户操作的可以是前台(前台可以是客户端、页面、h5等用户使用界面等)，前台可以部署在移动终端或台式电脑或其他终端设备之上。前台操作界面的查询入口可以包括因公查询入口和因私查询入口。当用户因公出差时，可以通过因公查询入口进行查询。当用户因私出行时，可以通过因私查询入口进行查询。需要说明的是，差旅信息对应的出行方式可以是：乘坐飞机、乘坐高铁、乘坐汽车、或者乘坐轮船中的一种或者多种，在后续举例描述中以乘坐飞机的出行方式为例进行举例，其他出行方式对应流程参照乘坐飞机的出行方式对应流程，不再一一举例描述。

当用户操作的查询入口为因公查询入口时，差旅平台可以从出差申请平台获取用户未启程的差旅信息，未启程的差旅信息例如可记录有：用户标识、航程类型、差旅号、出发城市、到达城市、出发时间、返回时间、供应商、差旅号等信息。举例来说，一个未启程的差旅信息包括：用户a、航程是单程、差旅号比如为tr001、出发城市是北京、到达城市是雅加达、出发日期是2019年12月18日，返回时间是2020年3月30日、供应商是在差旅平台中编号为2的供应商，比如可以是中国航信互联网订座引擎(internetbookingengine，ibe)等。

在一些可能的是实施方式中，差旅系统在每天指定时刻执行因私预测策略，预测得到如下信息：当天因私搜索的热门航线、所述热门航线的日期对、当天所述供应商最大的刷新次数、以及当天所述热门航线的刷新频率；按照预测得到的所述热门航线、所述热门航线的日期对、当天所述供应商最大的刷新次数、以及当天所述热门航线的刷新频率从所述供应商获取所述热门航线对应的数据并保存到所述缓存中。这样有利于提高查询时主动缓存的命中率。

202、根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

其中，差旅线可以包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线。

在一些可能的实施方式中，因公主动缓存策略可以包括：从因公数据库中获取用户的历史差旅信息，根据用户的历史差旅信息预测与用户未启程的差旅信息匹配的因公主动缓存差旅线。对于单程情况，统计历史差旅信息中各个航线查询日期和出发日期的间隔，对于占比达到设定阈值的作为各航线预测日期对。以步骤201中的示例来说，根据用户历史差旅信息，若用户乘坐航班日期80％是出差当天的航班、20％是出差后一天预订、并且90％是从北京直飞雅加达，10％是从北京先到香港然后再从香港到雅加达。根据历史差旅信息可以将2019年12月18日北京到雅加达的航线作为因公主动待缓存信息。

对于单程情况，统计各个航线查询日期和出发日期的间隔，对于占比达到给定阈值的作为各航线预测日期对。对于往返情况，除了统计各个航线查询日期和出发日期的间隔外，还可以统计返回日期与出发日期的间隔，根据两个日期间隔，占比达到预先给定阈值的作为预测日期对。

在一些可能的实施方式中，因公主动缓存策略可以包括：在所述因公数据库中没有用户的历史差旅信息时，根据因公数据库中保存的其他用户的历史差旅信息，确定其他用户的偏好信息；根据其他用户的偏好信息预测与用户未启程的差旅信息匹配的因公主动缓存差旅线。

根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线预测得到的因公主动缓存差旅线之后，通常以因公主动缓存表的形式保存，如表1所示，因公主动缓存表通常包括如下字段：差旅申请号、航程类型、出发城市、到达城市、出发时间、返回时间、刷新顺序和供应商类型。

表1因公主动缓存表

表1中的n1、n2为每个出差申请号预测的刷新日期对个数。根据用户历史出差情况不同，每个出差申请号对应的待缓存信息个数不同。

在一个具体的实施例中，因公主动缓存表中包括n1+n2条记录，第一条记录记录的信息为：差旅申请号为tr112、航程类型为单程、出发城市为nkg、到达城市为kul、出发时间为20191001、返回时间置空、刷新顺序为1、供应商类型包括供应商1和供应商4。第2条信息到第n1-1条记录为该差旅信息号对应的其他待缓存信息；第n1条记录的信息为：差旅信息号tr112、航程类型为往返、出发城市为nkg、到达城市为kul、出发时间为20191001、返回时间为20191007、刷新顺序为n1，供应商类型为供应商1和供应商4。另一条记录记录的信息为：差旅申请号为tr113、航程类型为往返、出发城市为nkg、到达城市为pex、出发时间为20191001、返回时间为20191007、刷新顺序为1、供应商类型包括供应商3；剩余n2-1条解释如tr112。

在一些可能的实施方式中，在因公数据库中没有所述用户的历史差旅信息时，根据因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

203、根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

在一些可能的实施方式中，在因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，并根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，这样有利于提升因公主动缓存中的数据与用户操作的匹配性和因公查询时主动缓存的命中率，进而提升用户体验。

参见图2b，图2b是本申请实施例提供的一种差旅平台的主动缓存方法的流程示意图，在该实施例中，主动缓存方法可包括但不限于如下步骤。

201、在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息。

在一些可能的实施方式中，在步骤201之前还可以包括判断查询入口是因公查询入口还是因私查询入口。

202、根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

203、根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

其中步骤201至步骤203参见前面对图2a各步骤的描述，这里不再赘述。

204、在查询入口是因私查询入口时，根据因私预测策略预测第一信息。

第一信息包括：因私搜索的热门差旅线、所述热门差旅线的刷新频率、还可以包括热门航线的日期对、以及从所应商刷新次数的上限。

在用户通过因私查询入口进行查询时，统计用户因私机票查询数据，可以包括：出发城市、到达城市、出发时间、返回时间、搜索时间、成年人数、儿童数、婴儿数。按照航线城市对(出发城市+到达城市)对过去一段时间的查询量进行频次统计，对频次百分比超过给定阈值(比如50％)的归类为热门航线。该阈值可根据刷新量与pnr的比值进行调整。

根据因私主动缓存策略预测热门航线，可以利用统计方法按照单程和往返预测用户最有可能查询的日期对(出发时间+到达时间)。对于单程情况，统计各个航线查询日期和出发日期的间隔，对于占比达到给定阈值的作为各航线预测日期对。对于往返情况，除了统计各个航线查询日期和出发日期的间隔外，还需统计返回日期与出发日期的间隔，根据两个日期间隔，占比达到预先给定阈值的作为预测日期对。

在一个实施例中，热门航线如表2所示。

表2热门航线

表2中的nkg、kul、pek均为城市代号。在上例中，供应商1的刷新量为1*刷新策略为1的刷新次数+1*刷新策略为2的总刷新次数。根据预测的航线刷新频次向供应商发送查询请求并存入缓存库中。

205、按照预测得到的第一信息获取所述热门航线对应的数据并保存到所述缓存中。

在预测供应商最大的刷新次数方面，因私预测策略具体包括：根据所述供应商的历史pnr数，预测所述供应商的pnr数，结合所述供应商的查订比和预测得到的当天所述供应商的pnr数，确定当天所述供应商刷新次数的上限。

在一个实施例中，热门航线的刷新频率如表3所示。

表3航线刷新策略表

由表3可知，szx-bkk这个航线采用编号为1的刷新策略进行刷新。其中0:00-2:59时间段中每隔1.5小时(h)刷新一次，这个时间段共刷2次，缓存有效时间为1.5h。3:00-8:59时间段中每隔3h刷新一次，这个时间段共刷2次，缓存有效时间为3h。9:00-11:59时间段中每隔1h刷新一次，这个时间段共刷3次，缓存有效时间为1h。12:00-13:59时间段中每隔2h刷新一次，这个时间段共刷1次，缓存有效时间为2h。2:00-18:59时间段中每隔0.5h刷新一次，这个时间段共刷10次，缓存有效时间为0.5h。19:00-23:59时间段中每隔1h刷新一次，这个时间段共刷5次，缓存有效时间为1h。

在该实施例中，当用户登录前台，判断用户是否有机票的差旅申请，若有则返回最近的差旅信息。根据用户差旅申请查询缓存库中是否有预测的缓存数据，有则发起实时主动的查询请求。否则根据用户输入的查询条件发起实时查询请求。

在一些可能的实施方式中，可以根据热门航线的历史变化次数确定从供应商获取热门航线的刷新频率，根据刷新频率从供应商获取热门航线对应的数据并保存到缓存中。热门航线的变化可以包括：剩余座位数量的变化、价格的变化或者航班列表的变化等。举例来说，根据历史数据，若某两个相邻采样时刻获得的航线信息没有变化或者发生变化概率比较小时，可以将采样间隔延长，比如原来是1h采样一次，可以调整为1.5h采样一次。根据历史数据，若某两个相邻采样时刻获得的航线信息每次都有变化或者发生变化概率比较大时，可以将采样间隔缩短，比如原来1h采样一次，可以调整为0.5h采样一次。

在一些可能的实施方式中，可以统计订单数据中各个供应商的pnr数，对该数据做相应处理后，采用机器学习时序回归算法建立预测模型，预测某一天的pnr数，根据各供应商的收费标准和查订比确定每天最大的刷新量。获取基于业务规则配置的航线对应供应商，根据各供应商每天最大的刷新量调整确定航线最终供应商及待刷新数据。对供应商每天的历史pnr数据，做如下处理，包括但不限于异常值处理、缺失值处理、序列平稳性检验、白噪声检验。将上述数据划分为训练集和测试集，在训练集上进行模型的训练，采用的机器学习时序回归算法包括差分整合移动平均自回归模型(autoregressiveintegratedmovingaveragemodel，arima)、霍尔特-温特(holtwinters)、时间序列分解方法(seasonalandtrenddecompositionusingloess，stl)算法。选择在训练集测试集上均方根误差(rootmeansquareerror，rmse)值最小的算法，来预测某一天的pnr数。举例来说，若某供应商a查订比为200:1(查询量:pnr数)，预测出某一天pnr数为200，则最大的查询量为200*200*thresholda，其中thresholda为该供应商的最大刷新比例，该值可灵活调整。需要说明的是，除了主动缓存，在实际操作中还需要考虑通过被动缓存方式从供应商获取数据的情况、查询预算、以及供应商的收费标准等，所以在实际操作时通常将供应商的最大刷新比例乘以一个系数(比如0.6等)。根据pnr确定最大的查询量也可以应用于在线旅行社从供应商获取数据等场景

本申请实施例提供的技术方案，除了对查询入口为因公查询入口的情况进行描述以外，还对每天指定时刻执行的因私预测策略进行了描述。按照预测得到的当天因私搜索的热门航线、当天所述热门航线的日期对、当天所述热门航线的刷新频率、以及当天所述供应商最大的刷新次数，从供应商获取热门航线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

参见图3a，图3a是本申请实施例提供的一种差旅查询方法的交互流程示意图，在该实施例中，差旅查询方法，包括如下步骤。

301、在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息。

302、根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

在一些可能的实施方式中，从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

在一些可能的实施方式中，在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；

根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

303、根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

在一些可能的实施方式中，可以在主动缓存航线的数据发生变化时，实时从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

304、在所述用户触发因公查询界面中的因公查询操作时，在所述缓存中查找是否有与所述因公查询操作匹配的数据。

若是，则执行步骤3041。若否，则执行步骤3042。

举例来说，若缓存保存有未来7天(11.21-11.27)单程从深圳到曼谷的所有航班信息，当用户查询11.22号深圳到曼谷单程机票，那么在缓存中查找到有与因公查询操作匹配的数据。当用户搜索11.28号深圳到曼谷单程机票，在缓存中则没有与因公查询操作匹配的数据。

3041、显示所述与所述因公查询操作匹配的数据。

3042、根据查询条件向供应商发起第一实时查询请求，获取并显示与所述第一实时查询请求匹配的因公被动缓存差旅线对应的数据，以及根据因公被动刷新策略从所述供应商获取所述因公被动缓存差旅线对应的数据并保存到所述缓存中。

305、执行因私预测策略，预测得到的信息包括：因私搜索的热门航线、所述热门航线的日期对、所述热门航线的刷新频率、以及从所述供应商刷新次数的上限。

在一些可能的实施方式中，可以每天零点执行因私预测策略。可以理解的是，也可以在用户设置的其他时间点执行因私预测策略。

306、按照预测得到的因私搜索的热门航线、所述热门航线的日期对、所述热门航线的刷新频率、以及从所述供应商刷新次数的上限，获取所述热门航线对应的数据并保存到所述缓存中。

在一些可能的实施方式中，在预测所述热门航线的刷新频率方面，所述因私预测策略具体包括：根据所述热门航线的历史变化次数确定所述热门航线的刷新频率。

在一些可能的实施方式中，在预测所述供应商最大的刷新次数方面，所述因私预测策略具体包括：根据所述供应商的历史查定比，预测所述供应商的查定比，结合所述供应商的收费标准和预测得到的当天所述供应商的查定比，确定当天所述供应商刷新次数的上限。

307、在所述用户触发因私查询界面中的因私查询操作时，在所述缓存中查找是否有与所述因私查询操作匹配的数据。

若是，则执行步骤3071。若否，则执行步骤3072。

3071、显示所述与所述因私查询操作匹配的数据。

3072、根据查询条件向供应商发起第二实时查询请求，获取并显示与所述第二实时查询请求匹配的因私被动缓存差旅线对应的数据，以及根据因私被动刷新策略从所述供应商获取所述因私被动缓存差旅线对应的数据并保存到所述缓存中。

通过试验，测试前后的性能对比如图3b至图3d所示。如图3b所示，在2019年8月8日使用本实施例提供的方法后，主动缓存命中率由x提升到了x+16.9％。如图3c所示，平均查询时长降低了2秒左右，而且如图3d所示，验仓失败率保持平稳。

参见图4a，图4a是本申请实施例提供的一种主动缓存装置的结构示意图，主动缓存装置400，包括：第一获取单元401、第一预测单元402和第一处理单元403。其中，第一获取单元401，用于在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息。第一预测单元402，用于根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。第一处理单元403，用于根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。各模块的具体实施参考图2a所示方法实施例中的描述，这里不再赘述。

本申请实施例提供的技术方案，在查询入口为因公查询入口时，获取用户未启程的差旅信息，根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，并根据因公主动刷新策略从供应商获取因公主动缓存差旅线对应的数据并保存到缓存中，这样有利于提升缓存中的数据与用户查询操作的匹配性以及因公查询时主动缓存的命中率，进而提升用户体验。

参见图4b，图4b是本申请实施例提供的一种主动缓存装置的结构示意图,主动缓存装置400'，包括：第一获取单元401、第一预测单元402、第一处理单元403、第二预测单元404和第二处理单元405。其中，第一获取单元401，用于在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息。第一预测单元402，用于根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。第一处理单元403，用于根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。第二预测单元404，用于根据因私预测策略预测第一信息，所述第一信息包括：因私搜索的热门差旅线和所述热门差旅线的刷新频率。第二处理单元405，用于根据所述第一信息获取所述热门差旅线对应的数据并保存到所述缓存中。各模块的具体实施参考图2b所示方法实施例中的描述，这里不再赘述。在本申请一些可能的实施方式中，可以在每天指定时刻执行因私预测策略，指定时刻比如可以是每天的零点执行因私预测策略。

在一些可能的实施方式中，所述第一信息还可以包括：从所述供应商刷新次数的上限。

本申请实施例提供的技术方案，对因私预测策略进行了描述。按照预测得到的第一信息，从供应商获取热门差旅线对应的数据并保存到缓存中，有利于提高查询时主动缓存的命中率。

在一些可能的实施方式中，第一预测单元402具体用于，从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

在一些可能的实施方式中，所述第一预测单元402具体还用于，在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

在一些可能的实施方式中，所述第一处理单元403具体用于，在所述因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

在一些可能的实施方式中，在预测所述热门差旅线的刷新频率方面，第二预测单元具体用于：根据所述热门差旅线的历史变化次数调整所述热门差旅线的刷新频率。

本申请实施例提供的技术方案，对因私主动刷新频率进行了限定，根据所述热门航线的历史变化次数确定当天所述热门航线的刷新频率，这样可以优化刷新频率，使得刷新频率的设置与热门航线的变化更匹配，有利于降低验仓失败率。

在一些可能的实施方式中，在预测所述供应商刷新次数的上限方面，所述因私预测策略具体包括：根据所述供应商的历史旅客订座记录pnr数，预测所述供应商的pnr数，结合所述供应商的查订比和预测得到的所述供应商的pnr数，确定所述供应商刷新次数的上限。

本申请实施例提供的技术方案，根据供应商的历史pnr数及查订比确定供应商刷新次数的上限，有利于降低查询成本。

参见图5a，图5a是本申请实施例提供的一种差旅查询装置，包括：第一获取单元501、第一预测单元502和第一处理单元503。其中，第一获取单元501，用于在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息；第一预测单元502，用于根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线；所述差旅线包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线。第一处理单元503，用于根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

本申请实施例提供的技术方案，在查询入口为因公查询入口时获取用户未启程的差旅信息，并根据因公主动缓存策略预测与用户未启程的差旅信息匹配的因公主动缓存差旅线，这样有利于提升因公主动缓存中的数据与用户操作的匹配性和因公查询时主动缓存的命中率，进而提升用户体验。

参见图5b，图5b是本申请实施例提供的一种差旅查询装置的结构示意图，如图5b所示机票查询装置500'，包括：第一获取单元501、第一预测单元502、第一处理单元503、第一显示单元504、第二预测单元505、第二处理单元506、第三处理单元507、第二显示单元508和第四处理单元508。其中，第一获取单元501，用于在查询入口为因公查询入口时，差旅平台从出差申请平台获取用户未启程的差旅信息；第一预测单元502，用于根据因公主动缓存策略预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线；所述差旅线包括如下一种或者多种：乘坐飞机的航班线、乘坐高铁的列车线、乘坐汽车的班车线或者乘坐轮船的轮船线；第一处理单元503，用于根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。第一显示单元504，用于第一处理单元503根据因公主动刷新策略从供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中之后，在所述用户触发因公查询界面中的因公查询操作、并且在所述缓存中查找到与所述因公查询操作匹配的数据时，显示所述与所述因公查询操作匹配的数据；以及，在所述缓存中没有查找到与所述因公查询操作匹配的数据、并且在根据查询条件向供应商发起第一实时查询请求之后，显示与所述第一实时请求匹配的因公被动缓存差旅线对应的数据。

第二预测单元505，用于根据因私预测策略预测第一信息，所述第一信息包括：因私搜索的热门差旅线和所述热门差旅线的刷新频率。第二处理单元506，用于根据所述第一信息获取所述热门差旅线对应的数据并保存到所述缓存中。

第三处理单元507，用于在所述第一处理单元根据因公主动刷新策略从供应商获取所述主动缓存航线对应的数据并保存到因公主动缓存中之后，在所述用户触发因公查询界面中的因公查询操作、并且在所述缓存中没有查找与所述因公查询操作匹配的数据时，则根据查询条件向供应商发起第一实时查询请求，获取与所述第一实时请求匹配的因公被动缓存差旅线对应的数据，以及根据因公被动刷新策略从所述供应商获取所述因公被动缓存差旅线对应的数据并保存到所述缓存中。第四处理单元509，用于在查询入口为因私查询入口，并且在用户触发因私查询界面中的因私查询操作时，在缓存中查找是否有与因私查询操作匹配的数据；若是，则第二显示单元508显示与因私查询操作匹配的数据；若否，则根据查询条件向供应商发起第二实时查询请求，获取并通过第二显示单元508显示与第二实时查询请求匹配的因私被动缓存差旅线对应的数据，以及根据因私被动刷新策略从所述供应商获取所述因私被动缓存差旅线对应的数据并保存到所述缓存中。

在一些可能的实施方式中，第一预测单元502具体用于，从因公数据库中获取所述用户的历史差旅信息；根据所述用户的历史差旅信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

在一些可能的实施方式中，第一预测单元502还用于，在所述因公数据库中没有所述用户的历史差旅信息时，根据所述因公数据库中保存的其他用户的历史差旅信息，确定所述其他用户的偏好信息；根据所述其他用户的偏好信息预测与所述用户未启程的差旅信息匹配的因公主动缓存差旅线。

在一些可能的实施方式中，第一处理单元503具体用于，在所述因公主动缓存差旅线的数据发生变化时，实时从所述供应商获取所述因公主动缓存差旅线对应的数据并保存到缓存中。

在一些可能的实施方式中，在预测当天所述热门航线的刷新频率方面，第二预测单元505具体用于，根据热门航线的历史变化次数确定当天热门航线的刷新频率。第二预测单元505根据热门航线的历史变化次数确定当天热门航线的刷新频率，可以包括：根据所述热门航线的固定时间段内历史变化次数预测当天所述热门航线固定时间段内的变化次数，根据预测得到的当天固定时间段内所述热门航线的变化次数，确定固定时间段内当天所述热门航线的热门值，根据所述热门航线的热门值确定当天固定时间段内热门航线的刷新频率。可以理解的是，热门值越靠前刷新频率越高。

在一些可能的实施方式中，在预测当天所述供应商最大的刷新次数方面，第二预测单元505具体用于，根据所述供应商的历史pnr数，预测当天所述供应商的pnr数，结合所述供应商的查订比和预测得到的当天所述供应商的pnr数，确定当天所述供应商刷新次数的上限。

各模块的具体实施参考前面方法实施例中的描述，这里不再赘述。

参见图6，图6是本申请实施例提供的一种差旅平台，差旅平台600包括：通信接口601、处理器602、存储器603和总线604，其中，通信接口601，用于接收来自客户端的机票查询操作以及与差旅平台进行通讯。存储器603，用于存储可执行程序代码。处理器602，用于通过读取所述存储器中存储的所述可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行前面任一方法实施例中所述的方法。

本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被硬件执行以实现前面任一方法实施例所述的方法。

在上述实施例中，可全部或部分地通过软件、硬件、固件、或其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如光盘)、或者半导体介质(例如固态硬盘)等。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在上述实施例中对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，也可以通过其它的方式实现。例如以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可结合或者可以集成到另一个系统，或一些特征可以忽略或不执行。另一点，所显示或讨论的相互之间的间接耦合或者直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者，也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例的方案的目的。

另外，在本申请各实施例中的各功能单元可集成在一个处理单元中，也可以是各单元单独物理存在，也可两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，或者也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质例如可包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或光盘等各种可存储程序代码的介质。