垂直搜索引擎技术 可借鉴性极高的通用方案：垂直搜索引擎性能优化

作者简介

张慧清，10多年的IT老手，系统分析师和项目管理部门。曾任中青益友CTO、桐城交通创新科技负责人、古达集团总建筑师、携程建筑师，带领30-200人的技术团队，研发能力提升1-2个档次。现在我们注重建筑设计和工程的效率、技术的实现和中小型R&D团队能力的提高。

一、行业背景和垂直搜索

首先让我们了解一下机票的行业背景。下图是中国航空公司的统计数据。蓝色曲线代表每公里平均票价，红色曲线指客流量。

如何解决以上问题？有三种通用技术解决方案:

用DB+Redis平衡响应速度、数据实时性和查询成本；用削峰填谷的MQ来处理高并发；将业务服务化、模块解耦。

这些只是常见的技术点，没有什么难度。这里我们重点关注与最终结果密切相关的四个模块:静态数据、缓存策略、实时查询和策略匹配。

静态数据：能静态处理的数据尽量静态化，存储到本地，可以是数据库或缓存，以方便快速地查询，如航班信息、运价数据和政策数据等；缓存策略：从中航信拿到运价数据之后，进行热冷门数据分类，数据永不过期但持续更新，自主控制数据的更新频率；实时查询：多渠道多供应实时获取远端数据，多数据源查询速度会变慢，远端服务不可控，解决方案是三段超时，即前端用户超时、中端运营超时、后端供应超时；政策匹配：大量的产品数据和大量的业务规则，不可能都提供给用户，需要通过一定的算法进行匹配过滤、排序等。

第三，静态数据和任务触底

机票查询的静态数据主要包括:城市、机型、航空公司、运价数据等。本文主要研究更复杂的运价数据。虽然获取运价数据的时间间隔较长，但数据量大，更新频率不同。

运价数据由中国航空公司统一提供。有两种方式:黑屏查询和IBE界面。数据将保存在数据库和缓存中。用户查询时，会直接从缓存中获取，并按照一定的缓存策略进行更新。

首先，我们设计了两种基于运价数据的方案，每种方案各有优缺点:

方案1是先预加载所有的运价数据，然后全部保存到数据库和缓存，然后在航班查询时通过缓存策略进行相应地更新；方案2是把运价数据根据航线查询频率分为热门和冷门数据，然后每天凌晨对热门数据预加载，并在航班查询的时候对冷门数据进行更新。

可以看出，方案1可以保证数据的完整性和实时性，但是预加载时间太长；方案二可以控制预加载时间，但是热数据的实时性会从早到晚逐渐降低。

两种方案都需要实时更新。考虑数据的实时性，还要考虑获取数据的成本。平衡这两个方案是一个切实可行的方案。

经过综合比较，我们采用了方案1，如下图所示:

首先通过Job初始化运费率数据，然后以任务消息的形式发送给MQ。MQ中的消息将被后台服务自动消费，消息队列中的任务将被执行，以将运费数据保存到数据库和缓存中。

数据预加载后，当用户在前台查询时，如果缓存中没有数据或者找到的缓存数据过期，系统会自动向MQ发送任务消息，或者手动配置指定的路由定期更新，作业会自动向MQ发送任务消息，前台和后台的消息会被服务消耗以更新数据。

用户不断的请求和后台分配的任务保证了数据的不断更新。时间越长，数据的准确性越高，用户查询的命中率也越高。

第四，缓存策略与数据一致

如上所述，运费率数据同时存储在数据库和缓存中。有了缓存为什么还需要数据库？

存储在数据库中的目的是方便数据的多维查询和管理，包括对缓存的进一步干预。数据库查询功能强大，但是速度慢，缓存性能好，但是从缓存中获取的数据会不准确。

如何才能实现快速查询和准确数据？

我们的解决方案是永不过期缓存，数据分类，独立控制更新频率，实现快速准确的运价数据。

根据路由查询的频率，我们可以分为热门数据、冷门数据和无数据。航班多查询多的热点数据，航班少查询少的冷门数据，不查询的数据。

当预加载或更新运价数据时，缓存设置为长时间或永不过期，然后不同的数据类型在前台访问时采用不同的更新策略，如下所示:

热门航线查询，在缓存中获取数据，数据中有一个自己的缓存时间字段，然后根据这个时间来分别处理：1小时之内更新的：新鲜度较高，可以直接用；1-6小时之内更新的：预警n次，第n+1次命中时则异步更新运价；6小时之外更新的：新鲜度太低，异步更新运价；冷门航线查询，与热门航线一样，只是不预加载且缓存时间稍长：12个小时之内更新的：新鲜度较高，可以直接用；12-48个小时之内更新的：预警n次，第n+1次命中时则异步更新运价；48个小时之外更新的：新鲜度太低，异步更新运价；缓存没有数据时，直接获取最新运价，同时更新数据库和缓存。

以上更新，无论是警告后还是直接，都是先将缓存中的数据返回给用户，同时异步更新数据库和缓存。

虽然存在数据查询不准确的概率，但是被用户再次查询的时候会很准确。

即使查询到的数据不准确，在后续的航班预订中也会进行查舱查价，再次更新运价数据和库存数据。

用户不断查询，数据不断更新，查询命中率会越来越高，用户越多情况越好，会逐渐接近N 9s。

动词 （verb的缩写）实时查询和三次超时

我们应该尽最大努力使静态数据保持静态，但远程数据的实时查询仍然是必要的。

实时查询如何做到又快又好？尤其是多数据源、多供应商的实时查询场景。

我们的国际机票查询是这样的。首页点击查询时，实时调用供应商界面。早期我们只叫一个供应接口，产品比较简单，数据不够丰富。后来我们引进了多家供应商，让产品更丰富更便宜，但同时也带来了很多新的问题。

比如供方接口需要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上等待25秒进行B2B白屏网页查询，则设置为25秒。

客户端超时应大于或等于所有操作员超时。例如，如果客户端超时是25秒，那么操作线程A的最大超时可以是25秒。但是如果线程A的大部分路由获取时间是18秒，那么线程B和C的超时应该不会超过18秒。这里的用户体验要综合考虑概率。

不及物动词策略匹配和算法优化

这么多产品，不可能提供给客户，需要按照操作规则来搭配。机票政策是机票产品的运营控制策略，如下图所示:

包括保单类型、客户类型、航次类型、旅客类型、航空公司、航班、舱位、城市、日期、返利、额度、办公室号等属性。

为什么属性这么多？

因为机票产品的操作规则非常复杂，而这种规则的复杂性直接导致了航班查询时机票政策的复杂匹配。对于这种大数据、复杂业务规则的数据处理，需要一套特殊的策略匹配算法，如下:

步骤1:直接从数据库中查找策略。前端查询时，根据查询条件，如出发和到达城市、日期等。，从数据库中获取大范围的策略数据，并将数据放入内存中。

第二步:匹配内存中每个产品的策略，即过滤。首先将每个属性转换成业务规则，比如限制城市，排除供应商，航空公司指定供应商。一个属性一个类，采用统一的接口，然后添加到策略过滤器。

产品与政策的匹配过程，就像水流过过滤器，将最优政策应用到产品上，比如调整价格。这个过程有些复杂，所以我们编写了自己的策略过滤器框架。

第三步:按照政策返利水平排序。

第四步:将最优策略返回前台。

以下是一些核心代码的演示:

七.总结

机票垂直搜索性能优化不仅适用于机票行业，也适用于其他垂直行业。在垂直搜索引擎中具有一定的通用性。只要存在远程数据采集、静态数据、缓存更新、规则匹配、多数据源等问题，都是类似的解决方案。

垂直搜索主要有四个画笔:

第一把刷子是静态数据与任务打底。第二把刷子是缓存与更新，保持数据的新鲜度，不仅要快，还要准。第三把刷子是实时查询与三段超时，多供应商多数据源，供应商要20秒，客户只能接受3秒，怎么办？解决办法是三段超时。第四刷子是政策匹配，好不容易弄来这么多产品，不可能都直接显示给客人，需要根据运营规则进行匹配。

以上，每一个具体的技术可能并不复杂，但是要把它们整合起来解决具体的实际问题，给公司和行业带来价值，并不容易。

技术的核心价值在于技术的应用，而技术的应用只有通过技术应用和产品的手段才能充分发挥出来，这比单纯的技术学习有趣得多。希望以上可以应用到你的具体工作中。

本文来源于《小团队建设大网站:中小型R&D团队架构实践》一书。如果你对这本书感兴趣，可以点击“阅读原文”查看购买链接。https://item.jd.com/12477683.html