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