机票垂直搜索引擎的性能优化

我们先了解一下机票的行业背景，下图是由中航信统计的数据，蓝色的曲线代表平均每公里的票价，红色曲线指的是客运量。从2011年到2016年，无论是国内、港澳台还是国际，整体趋势都是机票价格便宜了，坐飞机的人也越来越多了。特别是国际机票，这五年里机票价格下降30%，客运量增长了140%。

乘客越来越多，购买机票的渠道有哪些呢？现在主要有三个：网络平台、代售点和航司官网。像携程、去哪儿、飞猪、同程等，是主流的网络购票平台；像旅行社这类代售点，是旅行团的主要购票渠道；同时大部分航空公司的官网也可以购票，而且有相对较低的价格。总体来说，网络平台是最大的销售渠道，占比76%。为什么网络平台占有这么大的份额呢，主要原因是机票垂直搜索引擎是主要的用户流量入口，用户一般是先比价然后再去预订，一个好的机票搜索引擎查询的产品丰富、价格便宜，而且响应速度快，运价也准，这些特性在技术方面实现好并不容易。

机票查询要快、准、低。快是指查询快，能够提供一个良好的用户体验；准是指运价准，可以保证出票的成功率；低是指票价低，能够吸引更多的用户。但是，如果票价要有优势，就要有大量产品，产品数据多了查询就慢，如果查询要快，就必须要缓存，但是数据缓存了，运价就可能不准。这三者是矛盾的，类似于CAP原则，具体示意图如下：

对于以上问题，怎么解决呢？通用的三个技术方案有：一、用DB+Redis平衡响应速度、数据实时性和查询成本；二、用削峰填谷的MQ来处理高并发；三、将业务服务化、模块解耦。这些只是通用的技术点，并没有什么难度，我们这里重点介绍与最终结果密切相关的四个模块：静态数据、缓存策略、实时查询、政策匹配。

机票查询的静态数据主要有：城市、机型、航司、运价数据等，这里重点介绍较为复杂的运价数据，运价数据的获取虽然间隔时间较长，但数据量大且更新频次不同。运价数据是由中航信统一提供的，有两种途径：黑屏查询和IBE接口，将获取到的数据保存到数据库和缓存中，用户查询的时候直接从缓存中获取，同时也会按照一定的缓存策略来更新。

综合对比之后，我们采用了方案1，具体实现如下图所示：首先是通过Job对运价数据的初始化，然后以任务消息的方式发送给MQ，MQ里的消息会被后台服务自动消费，执行消息队列里的任务，把运价数据保存到数据库和缓存。数据预加载之后，用户在前台查询时，如果缓存里面没有数据，或者查到的缓存数据是过期的，系统会自动发一条任务消息给MQ，或者人工配置指定的航线定时更新，Job也会自动发送任务消息给MQ，前台和后台的消息被服务消费以实现数据的更新。用户的不断请求和后台指定的任务，保证数据的持续更新，时间越久数据的准确性越高，用户查询的命中率也会越来越高。

上面说到运价数据同时存储在数据库和缓存，为什么有了缓存还要数据库呢？存储到数据库是为了方便数据的多维查询和管理，包括对缓存的进一步干预。数据库查询的功能强大，但速度慢，缓存的性能好，但从缓存里获取的数据，会有不准确的问题。怎么才能做到查询快而且数据准呢？我们的解决方法是缓存永不失效、数据分类、自主控制更新频率，以实现运价数据的又快又准。

我们根据航线查询的频率，将可以分成热门数据、冷门数据和没有数据，航班多、查询多的是热门数据，航班少、查询少的是冷门数据，查询不到就是没有数据。在预加载或更新运价数据时，将缓存设置为一个较长时间或永不过期，然后在前台访问时，不同数据类型采用不同的更新策略，具体如下：

以上无论是预警后更新还是直接更新，都是先把缓存中数据返回给用户，同时异步更新数据库和缓存。虽然有存在数据查询不准确的概率，但被用户再次查询时就准确了。查询到的数据即便不准确，在后继的航班预订时也会二次的验舱验价，运价数据和库存数据会再次更新。用户不断地查询，数据不断地更新，查询命中率就会越来越高，并且用的人越多情况会越好，会逐步趋近于n个9。

能静态化的数据我们要尽量静态化，但远端数据的实时查询还是必不可少。实时查询如何做到又快又好呢，特别是多数据源、多供应商的实时查询场景。我们的国际机票查询就是这样，前台页面点击查询时实时调用供应商接口，早期我们仅调用一个供应接口，产品比较单一，数据不够丰富，后面我们引入了多供应商，产品变丰富了，也有了低价，但同时带来了很多新问题，比如供应端接口需要20~30秒，但前端客户只能接受8秒以内，怎么办？提高供应数据门槛？但这不是核心竞争。还有查询速度变慢、外部数据源不可控、数据格式多样等问题。

对于以上问题，我们的解决办法是三段超时，所谓三段超时，即供应端、运营端和客户端。前端满足客人、中间满足运营控制策略、后端满足供应商，三方都要满意，这样才能产品更丰富、价格更低、运营策略更灵活、用户响应更及时。三段超时的时间可以根据具体场景进行配置，具体如下：

弄来这么多产品，不可能都提供给客人，需要根据运营规则来匹配。机票政策就是机票产品的运营控制策略，如上图所示，包括政策类型、客户类型、航程类型、乘客类型、航司、航班、舱位、城市、日期、返点 、定额、Office号等多种属性。为什么有这么多属性呢？因为机票产品的运营规则很复杂，而这种规则的复杂性，直接导致在航班查询的时候，机票政策的匹配也很复杂的。对于这种大数据、复杂业务规则的数据处理，需要有一套专门的政策匹配算法，具体如下：

第一步是直接从数据库查政策，在前端查询的时候，根据查询的条件，如出发到达城市、日期等，从数据库中大范围的获取政策数据，并把这些数据放到内存中。第二步在内存中对每个产品进行政策匹配即过滤，先将每一个属性转化为业务规则如限制城市、排除供应商、航司指定供应商等，一个属性一个类、采用统一的接口，然后增加到政策过滤器中。产品与政策的匹配过程，就像水流过过滤网一样，把最优政策应用到产品上如调整价格。这个过程有些复杂，为此我们编写了一套自己的政策过滤器PolicyFilter框架。第三步是按照政策返点高低进行排序。第四步是将最优政策返回给前台。以下是部分核心代码的演示：