搜索引擎优化价格(一下机票的行业背景与垂直搜索技术方案（一）)

　　搜索引擎优化价格(一下机票的行业背景与垂直搜索技术方案（一）)

　　一、行业背景和垂直搜索

　　我们先来了解一下机票的行业背景。下图是航信计算的数据。蓝色曲线代表每公里平均票价，红色曲线代表客流量。2011年到2016年，无论是国内、港澳台还是国际，总体趋势是机票越来越便宜，坐飞机的人越来越多。尤其是国际机票，过去五年机票价格下降了30%，客流量增长了140%。

　　旅客越来越多，有什么渠道可以买机票？现在主要有三个：网络平台、销售代理和航空公司官网。携程、去哪儿、飞猪、同程等为主流网络购票平台；旅行社等代理网点是旅游团购票的主要渠道；同时，也可以在大多数航空公司的官方网站上购买机票。而且价格相对较低。总的来说，线上平台是最大的销售渠道，占比76%。为什么在线平台占据如此大的份额？主要原因是机票垂直搜索引擎是主要的用户流量入口。用户通常在预订前比较价格。一个好的机票搜索引擎，产品丰富，价格便宜，反应灵敏。速度快，运价准确。在技​​术上实现这些功能并不容易。

　　二、主要问题及解决方法

　　票务查询必须快速、准确、低价。快速是指查询速度快，可以提供良好的用户体验；准是指准确的运价，可以保证出票成功率；低是指票价低，可以吸引更多的用户。但是要票价有优势，产品数量一定要多，如果产品数据多，查询会很慢。如果查询快，一定要缓存，但是如果缓存了数据，运价可能不准确。这三者是矛盾的，类似于CAP原理。具体*敏*感*词*如下：

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

　　静态数据：可以静态处理的数据尽量是静态的，存储在本地，可以是数据库或缓存，方便快捷查询，如航班信息、货运数据、政策数据等；缓存策略：从 TravelSky 获取运费数据后，对冷热数据进行分类。数据永不过期但持续更新，数据更新频率独立控制；实时查询：多渠道多源实时访问远程数据，多数据源查询速度会变慢，远程服务不可用解决方案是三阶段超时，即前端用户超时、中端操作超时、后端供应超时；策略匹配：大量的产品数据和大量的业务规则无法提供给用户，并且需要通过一定的算法来进行。匹配过滤、排序等。

　　三、静态数据和任务库

　　机票查询的静态数据主要包括：城市、机型、航空公司、货运数据等，这里我们关注比较复杂的货运数据。虽然货运数据的获取时间较长，但数据量大，更新频率不一。. 运费数据由 TravelSky 提供。有两种方式：黑屏查询和IBE界面。获取的数据保存在数据库和缓存中。当用户查询时，直接从缓存中获取，同时按照一定的缓存策略进行更新。

　　最初，我们设计了两套方案来获取底部运费数据，每套方案各有优缺点。方案一是预先加载所有的货运数据，然后保存到数据库和缓存中，然后在航班查询时通过缓存策略进行相应的更新；方案二是将货运数据按照航线查询频率分为热门和冷门数据，然后每天早上预加载热门数据，查询航班时更新冷门数据。可以看出，方案1可以保证数据完整性和实时性，但预加载时间过长；方案二可以控制预加载时间，但是热点数据的实时性会从早到晚逐渐下降。这两种解决方案都需要实时更新。在考虑数据的实时性的同时，还必须考虑获取数据的成本。两者之间的良好平衡是一个实用的解决方案。

　　经过综合比较，我们采用了方案一，具体实现如下图所示： 首先通过Job初始化货运数据，然后以任务消息的形式发送到MQ。MQ 中的消息会被后台服务自动消费和执行。消息队列中的任务将货运数据保存到数据库和缓存中。数据预加载后，用户在前台查询时，如果缓存中没有数据，或者找到的缓存数据已过期，系统会自动向MQ发送任务消息，或者手动配置指定路由定时更新，Job也会自动向MQ发送任务消息，前台和后台消息被服务消费来更新数据。用户' s 不断的请求和后台指定的任务保证了数据的不断更新。时间越长，数据的准确度越高，用户查询的命中率也越高。

　　四、缓存策略与数据一致

　　如上所述，运费数据同时存储在数据库和缓存中。如果有缓存，为什么还需要数据库？存储在数据库中是为了方便数据的多维查询和管理，包括对缓存的进一步干预。数据库查询功能强大，但是速度慢，缓存性能好，但是从缓存中获取的数据会不准确。如何实现快速查询和准确数据？我们的解决方案是缓存永不失效，数据分类，独立控制更新频率，实现快速准确的货运数据。

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

　　无论是预警后更新还是直接更新，缓存中的数据首先返回给用户，数据库和缓存异步更新。虽然数据查询有不准确的概率，但是当用户再次查询的时候就会准确了。即使查询的数据不准确，在预订后续航班时也会进行第二次检查，并再次更新运费数据和库存数据。用户不断查询，数据不断更新，查询命中率会越来越高，使用的人越多，情况就会越好，逐渐接近n个9。

　　五、实时查询和三阶段超时

　　我们必须尽量让静态数据尽可能的静态化，但是远程数据的实时查询仍然是必不可少的。实时查询怎么做又快又好，尤其是多数据源、多供应商的实时查询场景。我们的国际机票查询是这样的。供应商接口在前台页面被点击时实时调用。早期，我们只调用了一个供应接口。产品比较单一，数据不够丰富。后来我们引进了多家供应商，产品也越来越丰富。价格低，但也带来了很多新的问题。比如供给侧接口需要20-30秒，而前端客户只能在8秒内接受。我该怎么办？提高供给数据门槛？但这不是核心竞争。

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

　　六、策略匹配与算法优化

　　有这么多产品，不可能提供给客户。它们需要根据操作规则进行匹配。机票政策是机票产品的运营控制策略，如上图所示，包括政策类型、客户类型、航班类型、旅客类型、航空公司、航班、舱位、城市、日期、返利、配额、办公号等属性. 为什么有这么多属性？因为机票产品的操作规则非常复杂，而这条规则的复杂直接导致查询航班时机票政策的匹配复杂。对于这类大数据和复杂业务规则的数据处理，需要特殊的策略匹配算法，如下：

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

　　七、总结

　　机票垂直搜索性能的优化不仅适用于机票行业，也适用于其他垂直行业。它在垂直搜索引擎中具有一定的通用性，只要存在：远程数据获取、静态数据、缓存更新、规则匹配、多数据源等问题都是类似的解决方案。垂直搜索主要有四个画笔。第一刷是静态数据和任务库。第二刷是缓存和更新，保持数据新鲜，不仅快，而且准确。第三刷是实时查询和三阶段超时，多供应商和多数据源。供应商需要 20 秒，客户需要 3 秒。我该怎么办？解决方案是三个超时。第四刷是政策匹配。这么多产品好不容易 无法直接展示给客户，需要按照操作规则进行匹配。以上，每一项具体的技术可能并不复杂，但将它们整合起来解决具体的实际问题，为公司和行业带来价值却并非易事。技术的核心价值在于技术的应用。技术的价值只有借助技术应用和产品才能发挥出来。这比纯技术学习有趣得多。我希望以上内容可以应用于您的具体工作。但将它们整合起来解决具体的实际问题，为公司和行业带来价值并不容易。技术的核心价值在于技术的应用。技术的价值只有借助技术应用和产品才能发挥出来。这比纯技术学习有趣得多。我希望以上内容可以应用于您的具体工作。但将它们整合起来解决具体的实际问题，为公司和行业带来价值并不容易。技术的核心价值在于技术的应用。技术的价值只有借助技术应用和产品才能发挥出来。这比纯技术学习有趣得多。我希望以上内容可以应用于您的具体工作。