去哪儿网机票搜索系统的高并发架构设计.docxVIP

去哪儿网机票搜索系统的高并发架构设计 2021-12-10 业务背景 Qunar成立于2005年，那时候大家还习惯打电话或者去代理商买机票。随着在线旅游快速进展，机票业务逐渐来到线上。在“在线旅游”的大浪潮下，Qunar的核心业务次要是线上机票搜索和机票销售。依据2021年9月艾瑞监测数据，在旅行类网站月度独立访问量统计中，去哪儿网以4474万人名列前茅。截至2021年3月31日，去哪儿网可实时搜索约9000家旅游代理商网站，搜索范围掩盖全球范围内超过28万条国内及国际航线。 Qunar由机票起家，核心产品包括机票搜索比价系统、机票销售OTA系统等。后来一度成为国内最大旅游搜索引擎，所以最开头大家晓得Qunar都是从机票开头。 在Qunar，我次要工作担任机票搜索系统。当时，搜索业务达到了日均十亿量级PV，月均上亿UV的规模。而整个搜索主系统设计上是比较简单的，或许包含了七、八个子系统。那时线上服务器压力很大，时常消灭一些高并发的问题。有时候为了处理线上问题，通宵达旦连续一两周是常有的事。虽然如此，我们还是对整个搜索系统做到了高可用、可扩展。 为了大家了解机票搜索的具体业务，我们从用户角度看一下搜索的过程，如下图： 依据上面的图片，简约解释下： 首页：用户按动身城市、到达城市、动身日期开头搜索机票，进入列表页。 列表页：呈现第一次搜索结果，一般用户会多次搜索，直到找到适合他的航班，然后进入详情页。 产品详情页：用户填入个人信息，开头预备下单领取。 从上面的引见可以看出，过程1和2是个用户高频的入口。用户访问流量一大，必定有高并发的情况。所以在首页和列表页会做一些优化： 前端做静态文件的压缩，优化Http恳求连接数，以减小带宽，让页面更快加载出来。 前后端做了数据分别，让搜索服务解耦，在高并发情况下更机警做负载均衡。 后端数据（航班数据）99%以上来自缓存，加载快，给用户更快的体验。而我们的缓存是 ?异步刷新的机制，后面会提及到。 在过亿级UV的搜索业务，其搜索结果核心目标：一是保证时间够快，二是保证结果实时最新。 为了达到这个目标，搜索结果就要尽量走缓存，我们会事后把航班数据放到缓存，当航班数据变化时，增量更新缓存系统。 所以，Qunar机票技术部就有一个全年很关键的一个目标：搜索缓存命中率，当时已经做到了99.7%。再往后，每提高0.1%，优化难度成指数级增长了。哪怕是千分之一，也直接影响用户体验，影响每天上万张机票的销售额。 因而，搜索缓存命中率假如有微小浮动，运营、产品总监们可能两分钟内就会扑到我们的工位上，和钱挂上钩的系统要慎重再慎重。 这里还有几个值得关注的目标： 每台搜索实例的QPS（搜索有50~60台虚拟机实例，按最大并发量，每台恳求吞吐量1000）。 搜索结果的 Average-Time : ?一般从C端用户体验来说，Average-Time 不能超过3秒的。 了解完机票搜索或许的流程，下面就来看看Qunar搜索的架构。 搜索系统设计架构 Qunar搜索架构图 上面提到搜索的航班数据都是存储在缓存系统里面。最早使用Memcached，通过全都Hash建立集群，印象或许有20台左右实例。 存储的粒度就是动身地和到达地全部航班数据。随着当时Redis并发读写功能稳步提高，部分系统开头逐渐迁移到Redis，比如机票低价系统、推举系统。 搜索系统按架构图，次要定义成前台搜索、后台搜索两大模块，分别用2、3标示，下面我也会重点解释。 前台搜索 次要读取缓存，解析，合并航班数据前往给用户端。 前台搜索是基于Web服务，高峰期时候最大启动了50台左右的Tomcat实例。搜索的URL规章是：动身城市+到达城市+动身日期，这和缓存系统存储最小单元：动身城市+到达城市+动身日期是全都的。 Tomcat服务我们是通过Nginx来做负载均衡，用Lua脚本区分是国际航线还是国内航线，基于航线类型，Nginx会跳转不同搜索服务器：次要是国际搜索、国内搜索(基于业务、数据模型、商业模式，完全分开部署)。不光如此，Lua还用来灵敏开发一些基本服务：比如维护城市列表、机场列表等。 ?航班数据 上文我们一直提到航班数据，接下来简约引见下航班的概念和基本类型，让大家有个印象，明白的同学可以跳过： 单程航班：也叫中转航班，比如BJ(北京)飞NY(纽约)。 来回航班：比如BJ飞NY，然后又从NY前往BJ。 带中转：有单程中转、来回中转；来回中转可以一段中转，一段中转。也可以两段都有中转，如下图： 其实，还有更简单的情况： 假如哪天在BJ（北京）的你想来一次说走就走的旅行，想要去NY(纽约)。你选择了BJ直飞NY的单程航班。后来，你觉得去趟米国老不简约，想顺便去LA玩。那你可以先BJ飞到LA，玩几天，然后LA再飞NY。 不过，去了米国要回