美团技术总监分享：高并发系统的设计及秒杀实践原理分析

一个大型网站应用一般都是从最初小规模网站甚至是单机应用发展而来的，为了让系统能够支持足够大的业务量，从前端到后端也采用了各种各样技术，前端静态资源压缩整合、使用CDN、分布式SOA架构、缓存、数据库加索引、读写分离等等。 这些技术是高并发系统所必须的，但是今天先不细说，而先谈谈在这些架构既定的情况下，一些高并发业务/接口实现时应该注意的原则，以及通过工作中一个6万QPS的秒杀活动，来介绍一下秒杀业务的特点以及如何优化。

高并发系统设计原则

高并发的接口/系统有一个共同的特性，那就是”快”。
在系统其它条件既定的情况下，系统处理请求越快，用户得到反馈的时间就越短，单位时间内服务器能够处理请求的数量就会越多。所以”快”几乎可以算是高并发系统的要满足的必要条件，要评估一个系统性能如何，某次优化是否提高系统的容量，”快”是一个很直观的衡量标准。

那么，如何才能做得快呢？有两个需要注意的原则 ：

1. 做得少，一方面是指在功能特性上有所为，有所不为，另一方面是指一次处理的信息量要少。
2. 做得巧，根据业务自身的特点，选择合理的业务实现方式，选择合理的缓存类型和缓存调用时机。

做得少

世界上最快的程序，是什么都不做的程序。
一个接口负责的功能越少，读取信息量越少，速度越快。

功能特性有选择

对于一个需要承受高并发的接口，在功能上，尽量不涉及一些难以缓存和预热的数据。 一个典型的例子，用户维度个性化的数据，用户和用户的信息不同，userId数量又很多，即使加上缓存，缓存命中率依然很低，压力还是会打到数据库，不光接口快不了，高并发的sql也会给数据库带来风险。

举一个例子，在点评电影早期的秒杀活动页上，展示了一个用户当前秒杀资格的信息，由于不同用户抢到秒杀资格的时间、优惠不同，每次都需要读数据库的来取，也就是每个用户进入主页都会产生一条sql。
还有一个例子，一般电商搞大促的时候，比如同时有多个优惠活动可以降低商品的价格，而一般只展示最低价的优惠，同时用户一个优惠只能参与一次，这样不同用户参与了不同活动之后可以享受的最低价就会随之改变，如果要在商品页面上展示这个动态价格，就免不了取到各个用户参加这些在线优惠的信息。

如果遇到这样的数据，要怎么解决呢？
一个办法是尝试转移数据的维度：刚才说的秒杀活动资格信息，如果以用户userId为key，会出现缓存命中率低，仍要sql读的情况，但是能够秒到的用户数量其实很少，所以如果以这次秒杀活动id为key，存储一个成功秒到用户的userid的list，就能够解决缓存命中率低的问题。

还有一个办法是可以把这些需要个性化数据的功能在业务流程上后移，流量漏斗，越往后流量越少，创建订单级的sql查询是可接受的。 刚才说的第二个例子，商品最优惠的价格，可以排除用户相关信息，只在商品列表/详情上展示只和优惠相关的最低价，而在提交订单的时候才真正去取用户参加活动情况，如果用户已经参加过给出提示并选择次优的优惠。商品的列表/详情页都在用户路径上相对靠前的位置，排除了用户个性化信息可以让商品列表/详情更容易缓存，响应速度更快，系统可承受的高并发量更高。

处理信息量要少

我们写业务代码的时候都有对应的业务对象，它们都存在一定的业务范围之内，比如类目、地区、日期等自身相关的维度。 一个系统中的业务对象，在多个维度的细分下，对应的量并不多，但如果一次全部都展示在一个页面/接口下，即使覆盖上了缓存，也会由于缓存占用空间过大或者缓存key数目过多、网络传输耗时、对象序列化反序列耗时等拖慢接口/页面响应速度。一般只要看一下这个页面/接口给出的业务对象的数量级，就能大致知道这个接口的性能了。

大家在做设计的时候，一般会估算