“高并发”一直是大家感兴趣的话题。2010年~2012年，我曾在Qunar供职，主要负责机票搜索相关的业务，当时我们的搜索系统较高每天承载了亿级用户的高并发访问。那段日子，很苦很累，Qunar的发展很快，我也见证了搜索系统的技术演变历程，本文就来给大家讲讲机票高并发的故事。
业务背景
Qunar成立于2005年，那时候大家还习惯打电话或者去代理商买机票。随着在线旅游快速发展，机票业务逐步来到线上。在“在线旅游”的大浪潮下，Qunar的核心业务主要是线上机票搜索和机票销售。根据2014年9月艾瑞监测数据，在旅行类网站月度独立访问量统计中，去哪儿网以4474万人名列前茅。截至2015年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规则是：出发城市+到达城市+出发日期，这和缓存系统存储最小单元：出发城市+到达城市+出发日期是一致的。