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

1、行业背景与垂直搜索

咱们先了解一下机票的行业背景，下图是由中航信统计的数据，蓝色的曲线表明平均每千米的票价，红色曲线指的是客运量。从2011年到2016年，不管是国内、港澳台仍是国际，总体趋势都是机票价格便宜了，坐飞机的人也愈来愈多了。特别是国际机票，这五年里机票价格降低30%，客运量增加了140%。

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

2、主要问题与解决方案

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

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

1. 静态数据：能静态处理的数据尽可能静态化，存储到本地，能够是数据库或缓存，以方便快速地查询，如航班信息、运价数据和政策数据等；

1. 缓存策略：从中航信拿到运价数据以后，进行热冷门数据分类，数据永不过时但持续更新，自主控制数据的更新频率；

1. 实时查询：多渠道多供应实时获取远端数据，多数据源查询速度会变慢，远端服务不可控，解决方案是三段超时，即前端用户超时、中端运营超时、后端供应超时；

1. 政策匹配：大量的产品数据和大量的业务规则，不可能都提供给用户，须要经过必定的算法进行匹配过滤、排序等。

3、静态数据与任务打底

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

最初咱们设计了两套方案来打底运价数据，两个方案各有优劣。方案1是先预加载全部的运价数据，而后所有保存到数据库和缓存，而后在航班查询时经过缓存策略进行相应地更新；方案2是把运价数据根据航线查询频率分为热门和冷门数据，而后天天凌晨对热门数据预加载，并在航班查询的时候对冷门数据进行更新。能够看出，方案1能保证数据的完整性和实时性，但预加载用时太长；方案2能控制预加载用时，但热门数据的实时性会从早到晚逐渐下降。两个方案中都须要实时更新，在考虑数据实时性的同时，还要考虑获取数据的费用，平衡好二者才是一个实用的方案。

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

4、缓存策略与数据一致

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

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

• 热门航线查询，在缓存中获取数据，数据中有一个本身的缓存时间字段，而后根据这个时间来分别处理：

• 1小时以内更新的：新鲜度较高，能够直接用；

• 1-6小时以内更新的：预警n次，第n+1次命中时则异步更新运价；

• 6小时以外更新的：新鲜度过低，异步更新运价；

• 冷门航线查询，与热门航线同样，只是不预加载且缓存时间稍长：

• 12个小时以内更新的：新鲜度较高，能够直接用；

• 12-48个小时以内更新的：预警n次，第n+1次命中时则异步更新运价；

• 48个小时以外更新的：新鲜度过低，异步更新运价；

• 缓存没有数据时，直接获取最新运价，同时更新数据库和缓存。

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

5、实时查询与三段超时

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

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

• 供应端超时：供应端是后端，是指提供数据源的一方，供应端存在的问题就是外部不可控。供应端处于数据来源的最底端，解决办法是尽可能加大供应端的超时时间限制。咱们对请求供应接口的最大HTTP超时时间设置为45秒，这个值能够知足绝大部分状况。

• 运营端超时：运营端是中间端，把供应商的数据拿过来以后，作包装转换、去重、政策匹配等业务处理。咱们先统计每个供应接口的请求时间，确认供应接口数据的质量和优先级，好比说：A供应数据的质量相比B和C供应数据的质量要高，那么A的请求级别能够设置得高一些。咱们优先考虑拿到A供应的数据，若是A的数据在8秒就返回，而B和C的超过这个时间，那么咱们此时在前台就只把A的数据返回给客户。对于B和C的数据，因为在HTTP请求时咱们采用异步并设置了较大的供应端超时，因此它会在A返回以后，继续异步请求并将返回的数据保存到缓存中，以供用户下次或其余用户使用。当咱们拿到了多供应商的产品数据后，这时会有必定重复的数据，须要规范化处理，将不一样数据格式转换成统一标准，而后去重并选取最优，最后根据运营策略进行政策匹配等。

• 客户端超时：客户端是前端，须要处理最终展现和不一样终端用户的不一样需求。客户端采用多线程异步读取，这样不会影响主线程的速度，同时并发请求，提高响应速度和用户体验。这里指的主线程请求时间，能够理解为在前台终端设备须要等待的时间，好比APP要求8秒钟返回，那就设置8秒时间；若是PC端B2B白屏网页查询，客户能够等待时间为25秒，那么就是设置25秒。客户端的超时时间要大于或等于全部的运营端超时时间，例如客户端超时是25秒，那么运营端线程A的超时能够最大为25秒，但若是线程A的绝大部分航线获取时间是18秒，那么线程B和C的超时最好不要超过18秒，这里的用户体验要综合考虑几率问题。

6、政策匹配与算法优化

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

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

  

7、小结

机票垂直搜索性能优化不只仅适合于机票行业，也适合于其它垂直行业，在垂直搜索引擎方面有必定的通用性，只要它存在：远端数据获取、静态数据、缓存更新、规则匹配、多数据源等问题，都是相似解决方案。垂直搜索主要有四把刷子。第一把刷子是静态数据与任务打底。第二把刷子是缓存与更新，保持数据的新鲜度，不只要快，还要准。第三把刷子是实时查询与三段超时，多供应商多数据源，供应商要20秒，客户只能接受3秒，怎么办？解决办法是三段超时。第四刷子是政策匹配，好不容易弄来这么多产品，不可能都直接显示给客人，须要根据运营规则进行匹配。以上，每个具体的技术可能并不复杂，但把它们综合起来，解决具体的实际问题，为公司为行业带来价值，并非件容易的事。技术的核心价值在于技术的应用，技术价值要借助技术应用和产品才能发挥出来，这比单纯的技术学习要有意思得多，但愿以上能应用到你具体的工做中。