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

1、1去哪儿网机票搜索系统的高并发架构设计2Qunar 成立于 2005 年，那时候大家还习惯打电话或者去代理商买机票。随着在线旅游快速发展，机票业务逐步来到线上。在“在线旅游”的大浪潮下，Qunar 的核心业务主要是线上机票搜索和机票销售。根据 2014 年 9 月艾瑞监测数据，在旅行类网站月度独立访问量统计中，去哪儿网以 4474 万人名列前茅。截至 2015 年 3 月 31 日，去哪儿网可实时搜索约 9000 家旅游代理商网站，搜索范围覆盖全球范围内超过 28 万条国内及国际航线。Qunar 由机票起家，核心产品包括机票搜索比价系统、机票销售 OTA 系统等。后来一度成为国内最大旅游搜索引

2、擎，所以最开始大家知道 Qunar 都是从机票开始。在 Qunar，我主要工作负责机票搜索系统。当时，搜索业务达到了日均十亿量级 PV，月均上亿 UV 的规模。而整个搜索主系统设计上是比较复杂的，大概包含了七、八个子系统。那时线上服务器压力很大，时常出现一些高并发的问题。有时候为了解决线上问题，通宵达旦连续一两周是常有的事。尽管如此，我们还是对整个搜索系统做到了高可用、可扩展。为了大家了解机票搜索的具体业务，我们从用户角度看一下搜索的过程，如下图：3根据上面的图片，简单解释下： 首页：用户按出发城市、到达城市、出发日期开始搜索机票，进入列表页。 列表页：展示第一次搜索结果，一般用户会多次搜索，

3、直到找到适合他的航班，然后进入详情页。 产品详情页：用户填入个人信息，开始准备下单支付。从上面的介绍可以看出，过程 1 和 2 是个用户高频的入口。用户访问流量一大，必然有高并发的情况。所以在首页和列表页会做一些优化： 前端做静态文件的压缩，优化 Http 请求连接数，以减小带宽，让页面更快加载出来。 前后端做了数据分离，让搜索服务解耦，在高并发情况下更灵活做负载均衡。 后端数据（航班数据）99%以上来自缓存，加载快，给用户更快的体验。而我们的缓存是 异步刷新的机制，后面会提及到。4在过亿级 UV 的搜索业务，其搜索结果核心指标：一是保证时间够快，二是保证结果实时最新。为了达到这个指标，搜索结

4、果就要尽量走缓存，我们会预先把航班数据放到缓存，当航班数据变化时，增量更新缓存系统。 所以，Qunar 机票技术部就有一个全年很关键的一个指标：搜索缓存命中率，当时已经做到了99.7%。再往后，每提高 0.1%，优化难度成指数级增长了。哪怕是千分之一，也直接影响用户体验，影响每天上万张机票的销售额。因此，搜索缓存命中率如果有微小浮动，运营、产品总监们可能两分钟内就会扑到我们的工位上，和钱挂上钩的系统要慎重再慎重。这里还有几个值得关注的指标： 每台搜索实例的 QPS（搜索有 5060 台虚拟机实例，按最大并发量，每台请求吞吐量 1000）。 搜索结果的 Average-Time : 一般从 C

5、端用户体验来说， Average-Time 不能超过 3 秒的。了解完机票搜索大概的流程，下面就来看看 Qunar 搜索的架构。搜索系统设计架构 5Qunar 搜索架构图上面提到搜索的航班数据都是存储在缓存系统里面。最早使用 Memcached，通过一致 Hash 建立集群，印象大概有 20 台左右实例。 存储的粒度就是出发地和到达地全部航班数据。随着当时 Redis 并发读写性能稳步提高，部分系统开始逐步迁移到 Redis，比如机票低价系统、推荐系统。搜索系统按架构图，主要定义成前台搜索、后台搜索两大模块，分别用 2、3 标示，下面我也会重点解释。前台搜索 主要读取缓存，解析，合并航班数据返

6、回给用户端。前台搜索是基于 Web 服务，高峰期时候最大启动了 50 台左右的 Tomcat 实例。搜索的 URL 规则是：出发城市+ 到达城市 +出发日期，这和缓存系统存储最小单元：出发城市+ 到达城市+出发日期是一致的。6Tomcat 服务我们是通过 Nginx 来做负载均衡，用 Lua 脚本区分是国际航线还是国内航线，基于航线类型，Nginx 会跳转不同搜索服务器：主要是国际搜索、国内搜索( 基于业务、数据模型、商业模式，完全分开部署)。不光如此，Lua 还用来敏捷开发一些基本服务：比如维护城市列表、机场列表等。航班数据 上文我们一直提到航班数据，接下来简单介绍下航班的概念和基本类型，让

7、大家有个印象，明白的同学可以跳过： 单程航班：也叫直达航班，比如 BJ(北京) 飞 NY(纽约)。 往返航班：比如 BJ 飞 NY，然后又从 NY 返回 BJ。 带中转：有单程中转、往返中转；往返中转可以一段直达，一段中转。也可以两段都有中转，如下图：其实，还有更复杂的情况：7如果哪天在 BJ（北京）的你想来一次说走就走的旅行，想要去 NY(纽约)。你选择了 BJ 直飞 NY 的单程航班。后来，你觉得去趟米国老不容易，想顺便去 LA 玩。那你可以先 BJ 飞到 LA，玩几天，然后 LA 再飞 NY。不过，去了米国要回来吧，你也许：1. NY 直接飞回 BJ。2. 突然玩性大发，中途顺便去日本，

8、从 NY 飞东京，再从东京飞 BJ。3. 还没玩够？还要从 NY 飞夏威夷玩，然后夏威夷飞东京，再东京飞首尔，最后首尔返回北京。 有点复杂吧，这是去程中转、回程多次中转的航班路线。对应国际航班还算非常正常的场景，比如从中国去肯尼亚、阿根廷，因为没有直达航班，就会遇到多次中转。所以，飞国外有时候是蛮有意思、蛮麻烦的一件事。通过上面例子，大家了解到了机票中航线的复杂程度。但是，我们的缓存其实是有限的，它只保存了两个地方的航班信息。这样简单的设计也是有必然出发点：考虑用最简单的两点一线，才能最大限度上组合复杂的线路。所以在前台搜索，我们还有大量工作要做，总而言之就是：按照最终出发地、目的地，根据一定

9、规则搜索出用户想要的航班路线。这些规则可能是：飞行时间最短、机票价格最便宜（一般中转就会便宜）、航班中转最少、最宜飞行时间。你看，机票里面的航线是不是变成了数据结构里面的有向图，而搜索就等于在这个有向图中，按照一定的权重求出最优路线的过程！8高并发下多线程应用 我们后端技术栈基于 Java。为了搜索变得更快，我们大量把 Java 多线程特性用到了并行运算上。这样，充分利用 CPU 资源，让计算航线变得更快。 比如下面这样中转航线，就会以多线程方式并行先处理每一段航班。类似这样场景很多：Java 的多线程对于高并发系统有下面的优势： Java Executor 框架提供了完善线程池管理机制：譬如

10、 newCachedThreadPool、 SingleThreadExecutor 等线程池。 FutureTask 类灵活实现多线程的并行、串行计算。 在高并发场景下，提供了保证线程安全的对象、方法。比如经典的 ConcurrentHashMap，它比起 HashMap，有更小粒度的锁，并发读写性能更好。线程安全的 StringBuilder 取代String、 StringBuffer 等等（Java 在多线程这块实现是非常优秀和成熟的）。高并发下数据传输 9因为每次搜索机票，返回的航班数据是很多的： 包含各种航线组合：单程、单程一次中转、单程多次中转，往返更不用说了。 航线上又区分上百

11、种航空公司的组合。比如北京到纽约，有美国航空，国航，大韩， 东京等等各个国家的各大航空公司，琳琅满目。那么，最早航班数据用标准的 XML、JSON 存储，不过随着搜索量不断飙升， CPU 和带宽压力很大了。后来采取自己定义一种 txt 格式来传输数据：一方面数据压缩到原来 30%40%，极大的节约了带宽。同时 CPU 的运算量大大减低，服务器数量也随之减小。在大用户量、高并发的情况下，是特别能看出开源系统的特点：比如机票的数据解析用到了很多第三方库，当时我们也用了 Fastjson。在正常情况下，Fastjson 确实解析很快，一旦并发量上来，就会越来越吃内存，甚至 JVM 很快出现内存溢出。

12、原因呢，很简单，Fastjson 设计初衷是：先把整个数据装载到内存，然后解析，所以执行很快，但很费内存。当然，这不能说 Fastjson 不优秀，现在看 GitHub 上有 8000 多 star。只是它不适应刚才的业务场景。这里顺便说到联想到一个事：互联网公司因为快速发展，需要新技术来支撑业务。 那么，应用新的技术应该注意些什么呢？我的体会是： 好的技术要大胆尝试，谨慎使用。 优秀开源项目，注意是优秀。使用前一定弄清他的使用场景，多做做压力测试。 高并发的用户系统要做 A/B 测试，然后逐步导流，最后上线后还要有个观察期。后台搜索 后台搜索系统的核心任务是从外部的 GDS 系统抓取航班数据

13、，然后异步写入缓存。10首先说一个概念 GDS(Global Distribution System)即“全球分销系统”，是应用于民用航空运输及整个旅游业的大型计算机信息服务系统。通过 GDS，遍及全球的旅游销售机构可以及时地从航空公司、旅馆、租车公司、旅游公司获取大量的与旅游相关的信息。机票的源数据都来自于各种 GDS 系统，但每个 GDS 却千差万别：1. 服务器遍布全球各地：国内 GDS 主要有中航信的 IBE 系统、黑屏数据（去机场、火车站看到售票员输入的电脑终端系统），国际 GDS 遍布于东南亚、北美、欧洲等等。2. 通讯协议不一样，HTTP （API 、Webservice）、So

14、cket 等等。3. 服务不稳定，尤其国外的 GDS，受网路链路影响，访问很慢（十几分钟长连接很常见），服务白天经常性挂掉。4. 更麻烦的是：GDS 一般付费按次查询，在大搜索量下，实时付费用它，估计哪家公司都得破产。而且就算有钱 , 各种历史悠久的 GDS 是无法承载任何的高并发查询。更苦的是，因为是创业公司，我们大都只能用免费的 GDS，它们都是极其不稳定的。所谓便宜没好货，最搞笑的一次是：曾经在米国的 GDS 挂了一、两天，技术们想联系服务商沟通服务器问题。因为是免费，就没有所谓的服务商一说，最后产品总监（算兼职商务吧）给了一个国外的网址，打开是这家服务商的工单页面，全英文，没有留任何邮箱。提交工单后，不知道什么时候回复。可以想想当时我的心情.虽然有那么多困难，我们还是找到一些技术方案，具体如下。引入 NIO 框架 考虑 GDS 访问慢，不稳定，导致很多长连接。我们大量使用 NIO 技术：