上海网站制作网络推广方法,柳城 wordpress,免费网络密码,网站建设锚点链接机票垂直搜索引擎的性能优化 原文:机票垂直搜索引擎的性能优化一、行业背景与垂直搜索我们先了解一下机票的行业背景#xff0c;下图是由中航信统计的数据#xff0c;蓝色的曲线代表平均每公里的票价#xff0c;红色曲线指的是客运量。从2011年到2016年#xff0c;无论是国… 机票垂直搜索引擎的性能优化 原文:机票垂直搜索引擎的性能优化一、行业背景与垂直搜索 我们先了解一下机票的行业背景下图是由中航信统计的数据蓝色的曲线代表平均每公里的票价红色曲线指的是客运量。从2011年到2016年无论是国内、港澳台还是国际整体趋势都是机票价格便宜了坐飞机的人也越来越多了。特别是国际机票这五年里机票价格下降30%客运量增长了140%。 乘客越来越多购买机票的渠道有哪些呢现在主要有三个网络平台、代售点和航司官网。像携程、去哪儿、飞猪、同程等是主流的网络购票平台像旅行社这类代售点是旅行团的主要购票渠道同时大部分航空公司的官网也可以购票而且有相对较低的价格。总体来说网络平台是最大的销售渠道占比76%。为什么网络平台占有这么大的份额呢主要原因是机票垂直搜索引擎是主要的用户流量入口用户一般是先比价然后再去预订一个好的机票搜索引擎查询的产品丰富、价格便宜而且响应速度快运价也准这些特性在技术方面实现好并不容易。 二、主要问题与解决方案 机票查询要快、准、低。快是指查询快能够提供一个良好的用户体验准是指运价准可以保证出票的成功率低是指票价低能够吸引更多的用户。但是如果票价要有优势就要有大量产品产品数据多了查询就慢如果查询要快就必须要缓存但是数据缓存了运价就可能不准。这三者是矛盾的类似于CAP原则具体示意图如下 对于以上问题怎么解决呢通用的三个技术方案有一、用DBRedis平衡响应速度、数据实时性和查询成本二、用削峰填谷的MQ来处理高并发三、将业务服务化、模块解耦。这些只是通用的技术点并没有什么难度我们这里重点介绍与最终结果密切相关的四个模块静态数据、缓存策略、实时查询、政策匹配。 静态数据能静态处理的数据尽量静态化存储到本地可以是数据库或缓存以方便快速地查询如航班信息、运价数据和政策数据等缓存策略从中航信拿到运价数据之后进行热冷门数据分类数据永不过期但持续更新自主控制数据的更新频率实时查询多渠道多供应实时获取远端数据多数据源查询速度会变慢远端服务不可控解决方案是三段超时即前端用户超时、中端运营超时、后端供应超时政策匹配大量的产品数据和大量的业务规则不可能都提供给用户需要通过一定的算法进行匹配过滤、排序等。三、静态数据与任务打底 机票查询的静态数据主要有城市、机型、航司、运价数据等这里重点介绍较为复杂的运价数据运价数据的获取虽然间隔时间较长但数据量大且更新频次不同。运价数据是由中航信统一提供的有两种途径黑屏查询和IBE接口将获取到的数据保存到数据库和缓存中用户查询的时候直接从缓存中获取同时也会按照一定的缓存策略来更新。 最初我们设计了两套方案来打底运价数据两个方案各有优劣。方案1是先预加载所有的运价数据然后全部保存到数据库和缓存然后在航班查询时通过缓存策略进行相应地更新方案2是把运价数据根据航线查询频率分为热门和冷门数据然后每天凌晨对热门数据预加载并在航班查询的时候对冷门数据进行更新。可以看出方案1能保证数据的完整性和实时性但预加载用时太长方案2能控制预加载用时但热门数据的实时性会从早到晚逐渐降低。两个方案中都需要实时更新在考虑数据实时性的同时还要考虑获取数据的费用平衡好两者才是一个实用的方案。 综合对比之后我们采用了方案1具体实现如下图所示首先是通过Job对运价数据的初始化然后以任务消息的方式发送给MQMQ里的消息会被后台服务自动消费执行消息队列里的任务把运价数据保存到数据库和缓存。数据预加载之后用户在前台查询时如果缓存里面没有数据或者查到的缓存数据是过期的系统会自动发一条任务消息给MQ或者人工配置指定的航线定时更新Job也会自动发送任务消息给MQ前台和后台的消息被服务消费以实现数据的更新。用户的不断请求和后台指定的任务保证数据的持续更新时间越久数据的准确性越高用户查询的命中率也会越来越高。 四、缓存策略与数据一致 上面说到运价数据同时存储在数据库和缓存为什么有了缓存还要数据库呢存储到数据库是为了方便数据的多维查询和管理包括对缓存的进一步干预。数据库查询的功能强大但速度慢缓存的性能好但从缓存里获取的数据会有不准确的问题。怎么才能做到查询快而且数据准呢我们的解决方法是缓存永不失效、数据分类、自主控制更新频率以实现运价数据的又快又准。 我们根据航线查询的频率将可以分成热门数据、冷门数据和没有数据航班多、查询多的是热门数据航班少、查询少的是冷门数据查询不到就是没有数据。在预加载或更新运价数据时将缓存设置为一个较长时间或永不过期然后在前台访问时不同数据类型采用不同的更新策略具体如下 热门航线查询在缓存中获取数据数据中有一个自己的缓存时间字段然后根据这个时间来分别处理1小时之内更新的新鲜度较高可以直接用1-6小时之内更新的预警n次第n1次命中时则异步更新运价6小时之外更新的新鲜度太低异步更新运价冷门航线查询与热门航线一样只是不预加载且缓存时间稍长12个小时之内更新的新鲜度较高可以直接用12-48个小时之内更新的预警n次第n1次命中时则异步更新运价48个小时之外更新的新鲜度太低异步更新运价缓存没有数据时直接获取最新运价同时更新数据库和缓存。 以上无论是预警后更新还是直接更新都是先把缓存中数据返回给用户同时异步更新数据库和缓存。虽然有存在数据查询不准确的概率但被用户再次查询时就准确了。查询到的数据即便不准确在后继的航班预订时也会二次的验舱验价运价数据和库存数据会再次更新。用户不断地查询数据不断地更新查询命中率就会越来越高并且用的人越多情况会越好会逐步趋近于n个9。 五、实时查询与三段超时 能静态化的数据我们要尽量静态化但远端数据的实时查询还是必不可少。实时查询如何做到又快又好呢特别是多数据源、多供应商的实时查询场景。我们的国际机票查询就是这样前台页面点击查询时实时调用供应商接口早期我们仅调用一个供应接口产品比较单一数据不够丰富后面我们引入了多供应商产品变丰富了也有了低价但同时带来了很多新问题比如供应端接口需要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秒这里的用户体验要综合考虑概率问题。六、政策匹配与算法优化 弄来这么多产品不可能都提供给客人需要根据运营规则来匹配。机票政策就是机票产品的运营控制策略如上图所示包括政策类型、客户类型、航程类型、乘客类型、航司、航班、舱位、城市、日期、返点 、定额、Office号等多种属性。为什么有这么多属性呢因为机票产品的运营规则很复杂而这种规则的复杂性直接导致在航班查询的时候机票政策的匹配也很复杂的。对于这种大数据、复杂业务规则的数据处理需要有一套专门的政策匹配算法具体如下 第一步是直接从数据库查政策在前端查询的时候根据查询的条件如出发到达城市、日期等从数据库中大范围的获取政策数据并把这些数据放到内存中。第二步在内存中对每个产品进行政策匹配即过滤先将每一个属性转化为业务规则如限制城市、排除供应商、航司指定供应商等一个属性一个类、采用统一的接口然后增加到政策过滤器中。产品与政策的匹配过程就像水流过过滤网一样把最优政策应用到产品上如调整价格。这个过程有些复杂为此我们编写了一套自己的政策过滤器PolicyFilter框架。第三步是按照政策返点高低进行排序。第四步是将最优政策返回给前台。以下是部分核心代码的演示 七、小结 机票垂直搜索性能优化不仅仅适合于机票行业也适合于其它垂直行业在垂直搜索引擎方面有一定的通用性只要它存在远端数据获取、静态数据、缓存更新、规则匹配、多数据源等问题都是类似解决方案。垂直搜索主要有四把刷子。第一把刷子是静态数据与任务打底。第二把刷子是缓存与更新保持数据的新鲜度不仅要快还要准。第三把刷子是实时查询与三段超时多供应商多数据源供应商要20秒客户只能接受3秒怎么办解决办法是三段超时。第四刷子是政策匹配好不容易弄来这么多产品不可能都直接显示给客人需要根据运营规则进行匹配。以上每一个具体的技术可能并不复杂但把它们综合起来解决具体的实际问题为公司为行业带来价值并不是件容易的事。技术的核心价值在于技术的应用技术价值要借助技术应用和产品才能发挥出来这比单纯的技术学习要有意思得多希望以上能应用到你具体的工作中。 posted on 2019-02-13 15:00 NET未来之路 阅读(...) 评论(...) 编辑 收藏 转载于:https://www.cnblogs.com/lonelyxmas/p/10369891.html
