作者介绍
张辉清，10多年IT老兵，系统分析师、项目管理师。曾中青易游CTO、同程交通创新技术负责人、古大集团首席架构师、携程架构师，领导过30～200人的技术团队，将研发能力提高1～2个档次。现关注架构设计与工程效率、技术变现、中小研发团队能力提升。
一、行业背景与垂直搜索
我们先了解一下机票的行业背景，下图是由中航信统计的数据，蓝色的曲线代表平均每公里的票价，红色曲线指的是客运量。
从2011年到2016年，无论是国内、港澳台还是国际，整体趋势都是机票价格便宜了，坐飞机的人也越来越多了。特别是国际机票，这五年里机票价格下降30%，客运量增长了140%。
乘客越来越多，购买机票的渠道有哪些呢？
现在主要有三个：网络平台、代售点和航司官网。像携程、去哪儿、飞猪、同程等，是主流的网络购票平台；像旅行社这类代售点，是旅行团的主要购票渠道；同时大部分航空公司的官网也可以购票，而且有相对较低的价格。
总体来说，网络平台是最大的销售渠道，占比76%。为什么网络平台占有这么大的份额呢，主要原因是机票垂直搜索引擎是主要的用户流量入口。
用户一般是先比价然后再去预订，一个好的机票搜索引擎查询的产品丰富、价格便宜，而且响应速度快，运价也准，这些特性在技术方面实现好并不容易。
二、主要问题与解决方案
机票查询要快、准、低。快是指查询快，能够提供一个良好的用户体验；准是指运价准，可以保证出票的成功率；低是指票价低，能够吸引更多的用户。
但是，如果票价要有优势，就要有大量产品，产品数据多了查询就慢，如果查询要快，就必须要缓存，但是数据缓存了，运价就可能不准。这三者是矛盾的，类似于CAP原则，具体示意图如下：
对于以上问题，怎么解决呢？通用的三个技术方案有：
用DB+Redis平衡响应速度、数据实时性和查询成本；
用削峰填谷的MQ来处理高并发；
将业务服务化、模块解耦。
这些只是通用的技术点，并没有什么难度，我们这里重点介绍与最终结果密切相关的四个模块：静态数据、缓存策略、实时查询、政策匹配。
静态数据：能静态处理的数据尽量静态化，存储到本地，可以是数据库或缓存，以方便快速地查询，如航班信息、运价数据和政策数据等；
缓存策略：从中航信拿到运价数据之后，进行热冷门数据分类，数据永不过期但持续更新，自主控制数据的更新频率；
实时查询：多渠道多供应实时获取远端数据，多数据源查询速度会变慢，远端服务不可控，解决方案是三段超时，即前端用户超时、中端运营超时、后端供应超时；
政策匹配：大量的产品数据和大量的业务规则，不可能都提供给用户，需要通过一定的算法进行匹配过滤、排序等。
三、静态数据与任务打底
机票查询的静态数据主要有：城市、机型、航司、运价数据等，这里重点介绍较为复杂的运价数据，运价数据的获取虽然间隔时间较长，但数据量大且更新频次不同。
运价数据是由中航信统一提供的，有两种途径：黑屏查询和IBE接口，将获取到的数据保存到数据库和缓存中，用户查询的时候直接从缓存中获取，同时也会按照一定的缓存策略来更新。
最初我们设计了两套方案来打底运价数据，两个方案各有优劣：
方案1是先预加载所有的运价数据，然后全部保存到数据库和缓存，然后在航班查询时通过缓存策略进行相应地更新；
方案2是把运价数据根据航线查询频率分为热门和冷门数据，然后每天凌晨对热门数据预加载，并在航班查询的时候对冷门数据进行更新。
可以看出，方案1能保证数据的完整性和实时性，但预加载用时太长；方案2能控制预加载用时，但热门数据的实时性会从早到晚逐渐降低。
两个方案中都需要实时更新，在考虑数据实时性的同时，还要考虑获取数据的费用，平衡好两者才是一个实用的方案。
综合对比之后，我们采用了方案1，具体实现如下图所示：
首先是通过Job对运价数据的初始化，然后以任务消息的方式发送给MQ，MQ里的消息会被后台服务自动消费，执行消息队列里的任务，把运价数据保存到数据库和缓存。
数据预加载之后，用户在前台查询时，如果缓存里面没有数据，或者查到的缓存数据是过期的，系统会自动发一条任务消息给MQ，或者人工配置指定的航线定时更新，Job也会自动发送任务消息给MQ，前台和后台的消息被服务消费以实现数据的更新。
用户的不断请求和后台指定的任务，保证数据的持续更新，时间越久数据的准确性越高，用户查询的命中率也会越来越高。
四、缓存策略与数据一致
上面说到运价数据同时存储在数据库和缓存，为什么有了缓存还要数据库呢？
存储到数据库是为了方便数据的多维查询和管理，包括对缓存的进一步干预。数据库查询的功能强大，但速度慢，缓存的性能好，但从缓存里获取的数据，会有不准确的问题。
怎么才能做到查询快而且数据准呢？
我们的解决方法是缓存永不失效、数据分类、自主控制更新频率，以实现运价数据的又快又准。
我们根据航线查询的频率，将可以分成热门数据、冷门数据和没有数据，航班多、查询多的是热门数据，航班少、查询少的是冷门数据，查询不到就是没有数据。
在预加载或更新运价数据时，将缓存设置为一个较长时间或永不过期，然后在前台访问时，不同数据类型采用不同的更新策略，具体如下：
热门航线查询，在缓存中获取数据，数据中有一个自己的缓存时间字段，然后根据这个时间来分别处理：
1小时之内更新的：新鲜度较高，可以直接用；
1-6小时之内更新的：预警n次，第n+1次命中时则异步更新运价；
6小时之外更新的：新鲜度太低，异步更新运价；
冷门航线查询，与热门航线一样，只是不预加载且缓存时间稍长：
12个小时之内更新的：新鲜度较高，可以直接用；
12-48个小时之内更新的：预警n次，第n+1次命中时则异步更新运价；
48个小时之外更新的：新鲜度太低，异步更新运价；
缓存没有数据时，直接获取最新运价，同时更新数据库和缓存。
以上无论是预警后更新还是直接更新，都是先把缓存中数据返回给用户，同时异步更新数据库和缓存。
虽然有存在数据查询不准确的概率，但被用户再次查询时就准确了。
查询到的数据即便不准确，在后继的航班预订时也会二次的验舱验价，运价数据和库存数据会再次更新。
用户不断地查询，数据不断地更新，查询命中率就会越来越高，并且用的人越多情况会越好，会逐步趋近于n个9。
五、实时查询与三段超时
能静态化的数据我们要尽量静态化，但远端数据的实时查询还是必不可少。
实时查询如何做到又快又好呢？特别是多数据源、多供应商的实时查询场景。
我们的国际机票查询就是这样，前台页面点击查询时实时调用供应商接口，早期我们仅调用一个供应接口，产品比较单一，数据不够丰富，后面我们引入了多供应商，产品变丰富了，也有了低价，但同时带来了很多新问题。
比如供应端接口需要20~30秒，但前端客户只能接受8秒以内，怎么办？提高供应数据门槛？但这不是核心竞争。还有查询速度变慢、外部数据源不可控、数据格式多样等问题。
对于以上问题，我们的解决办法是三段超时，所谓三段超时，即供应端、运营端和客户端。
前端满足客人、中间满足运营控制策略、后端满足供应商，三方都要满意，这样才能产品更丰富、价格更低、运营策略更灵活、用户响应更及时。
三段超时的时间可以根据具体场景进行配置，具体如下：
1）供应端超时
供应端是后端，是指提供数据源的一方，供应端存在的问题就是外部不可控。供应端处于数据来源的最底端，解决办法是尽量加大供应端的超时时间限制。
我们对请求供应接口的最大HTTP超时时间设置为45秒，这个值可以满足绝大部分情况。
2）运营端超时
运营端是中间端，把供应商的数据拿过来之后，做包装转换、去重、政策匹配等业务处理。
我们先统计每一个供应接口的请求时间，确认供应接口数据的质量和优先级，比如说：A供应数据的质量相比B和C供应数据的质量要高，那么A的请求级别可以设置得高一些。
我们优先考虑拿到A供应的数据，如果A的数据在8秒就返回，而B和C的超过这个时间，那么我们此时在前台就只把A的数据返回给客户。
对于B和C的数据，由于在HTTP请求时我们采用异步并设置了较大的供应端超时，所以它会在A返回之后，继续异步请求并将返回的数据保存到缓存中，以供用户下次或其他用户使用。
当我们拿到了多供应商的产品数据后，这时会有一定重复的数据，需要规范化处理，将不同数据格式转换成统一标准，然后去重并选取最优，最后根据运营策略进行政策匹配等。
3）客户端超时
客户端是前端，需要处理最终展示和不同终端用户的不同需求。客户端采用多线程异步读取，这样不会影响主线程的速度，同时并发请求，提升响应速度和用户体验。
这里指的主线程请求时间，可以理解为在前台终端设备需要等待的时间，比如APP要求8秒钟返回，那就设置8秒时间；如果PC端B2B白屏网页查询，客户可以等待时间为25秒，那么就是设置25秒。
客户端的超时时间要大于或等于所有的运营端超时时间，例如客户端超时是25秒，那么运营端线程A的超时可以最大为25秒，但如果线程A的绝大部分航线获取时间是18秒，那么线程B和C的超时最好不要超过18秒，这里的用户体验要综合考虑概率问题。
六、政策匹配与算法优化
弄来这么多产品，不可能都提供给客人，需要根据运营规则来匹配。机票政策就是机票产品的运营控制策略，如下图所示：
包括政策类型、客户类型、航程类型、乘客类型、航司、航班、舱位、城市、日期、返点 、定额、Office号等多种属性。
为什么有这么多属性呢？
因为机票产品的运营规则很复杂，而这种规则的复杂性，直接导致在航班查询的时候，机票政策的匹配也很复杂的。对于这种大数据、复杂业务规则的数据处理，需要有一套专门的政策匹配算法，具体如下：
Step 1 ：直接从数据库查政策，在前端查询的时候，根据查询的条件，如出发到达城市、日期等，从数据库中大范围的获取政策数据，并把这些数据放到内存中。
Step 2 ：在内存中对每个产品进行政策匹配即过滤，先将每一个属性转化为业务规则如限制城市、排除供应商、航司指定供应商等，一个属性一个类、采用统一的接口，然后增加到政策过滤器中。
产品与政策的匹配过程，就像水流过过滤网一样，把最优政策应用到产品上如调整价格。这个过程有些复杂，为此我们编写了一套自己的政策过滤器PolicyFilter框架。
Step 3 ：按照政策返点高低进行排序。
Step 4 ：将最优政策返回给前台。
以下是部分核心代码的演示：
七、小结
机票垂直搜索性能优化不仅仅适合于机票行业，也适合于其它垂直行业，在垂直搜索引擎方面有一定的通用性，只要它存在：远端数据获取、静态数据、缓存更新、规则匹配、多数据源等问题，都是类似解决方案。
垂直搜索主要有四把刷子：
第一把刷子是静态数据与任务打底。
第二把刷子是缓存与更新，保持数据的新鲜度，不仅要快，还要准。
第三把刷子是实时查询与三段超时，多供应商多数据源，供应商要20秒，客户只能接受3秒，怎么办？解决办法是三段超时。
第四刷子是政策匹配，好不容易弄来这么多产品，不可能都直接显示给客人，需要根据运营规则进行匹配。
以上，每一个具体的技术可能并不复杂，但把它们综合起来，解决具体的实际问题，为公司为行业带来价值，并不是件容易的事。
技术的核心价值在于技术的应用，技术价值要借助技术应用和产品才能发挥出来，这比单纯的技术学习要有意思得多，希望以上能应用到你具体的工作中。
本文出自《小团队构建大网站：中小研发团队架构实践》一书，若对该书感兴趣，可通过点击“阅读原文”，查看购买链接。
对大数据技术运用尚不熟练？
想玩转热点技术，同时把握先机？
新一年精彩纷呈的技术巡演全新启航！
助你找到最适用的进阶技能~
↓↓点击链接可了解更多详情及报名↓↓
2019 Gdevops全球敏捷运维峰会-北京站