关于面试:高频面试题秒杀场景设计

秒杀这个话题到当初来说曾经是一个陈词滥调的话题了，不过因为又邻近一年一度的双 11，而且发现前段时间无论是阿里还是腾讯一些大厂其实还是在频繁的问到这个场景题，所以还是筹备拿出来说说。

秒杀从规模上来说能够分为大秒和小秒。大秒指的是比方双 11 这种特定的节日，商品规模超大、价格超低、流量超大的这种类型流动，小秒个别指的是商家本人配置的一些时段类型的流动，由商家本人指定工夫上架。从模式来说还能够分为单时段秒杀和多时段秒杀。然而在这个场景里，咱们个别就是指的单时段大型秒杀。

秒杀设计要面对的压力和难度有几点：

1. 怎么保障超高的流量和并发下零碎的稳定性？如果峰值的 QPS 达到几十万，面对微小的流量的压力零碎怎么设计保障不被打崩？
2. 怎么保证数据最终一致性？比方库存不能超卖，超卖了那赔本的要么就是商家要么就是平台，用户反正不背这个锅，超卖了就往年 325 预订。

当然，波及到这种大型的流动，还须要思考到数据统计分析，总不能流动做完了，成果不晓得怎么样。

零碎架构

假如往年的双 11 预估峰值 QPS 将会有 50 万 (我轻易扯的)，而依据咱们平时的教训单机 8C8G 的机器能够达到 1000 左右的 QPS，那么从实践上来说咱们只有 500 台机器就能够抗住了，就有钱任性不行？这么设计的话只能出门右转不送了。

流量过滤

实质上，参加秒杀的用户很多，然而商品的数量是无限的，真正能抢到的用户并不多，那么第一步就是要过滤掉大部分有效的流量。

1. 流动开始前前端页面的 Button 置灰，避免流动未开始有效的点击产生流量
2. 前端增加验证码或者答题，避免霎时产生超高的流量，能够很好的起到错峰的成果，当初的验证码花样繁多，题库有的还要做个小学题，而且题库更新频繁，想暴力破解怕是很难。当然我晓得的还有一种人工打码的形式，不过这个也是须要工夫的，不像机器有限刷你的接口。
3. 流动校验，既然是流动，那么流动的参加用户，加入条件，用户白名单之类的要首先做一层校验拦挡，还有其余的比方用户终端、IP 地址、参加流动次数、黑名单用户的校验。比方流动次要针对 APP 端的用户校验，那么依据参数其余端的用户将被拦挡，针对 IP、mac 地址、设施 ID 和用户 ID 能够对用户参加流动的次数做校验，黑名单依据平时的流动教训拦挡掉一部分羊毛党等异样用户。
4. 非法申请拦挡，做了以上拦挡如果还有用户能绕过限度，那不得不说太牛 X 了。比方双 11 零点开始还做了答题限度，那么正常人怎么也须要 1 秒的工夫来答题吧，就算独身 30 年手速我想也不能超过 0.5 秒了，那么针对刚好 0 点或者在 0.5 秒以内的申请就能够齐全拦挡掉。
5. 限流，假如秒杀 10000 件商品，咱们有 10 台服务器，单机的 QPS 在 1000，那么实践上 1 秒就能够抢完，针对微服务就能够做限流配置，防止后续有效的流量打到数据库造成不必要的压力。针对限流还有另外一种栅栏形式限流，这是一种纯靠运气的限流形式，就是在零碎约定的申请开始的工夫内随机偏移一段时间，针对每个申请的偏移量不同，如果在偏移工夫之内就会被拦挡，反之通过。

性能优化

做完有效流量的过滤，那么可能你的有效申请曾经过滤掉了 90%，剩下的无效流量会大大的升高零碎的压力。之后就是须要针对零碎的性能做出优化了。

1. 页面动态化，参加秒杀流动的商品个别都是已知的，能够针对流动页面做动态化解决，缓存到 CDN。假如咱们一个页面 300K 大小，1 千万用户的流量是多少？这些申请要申请后端服务器、数据库，压力可想而知，缓存到 CDN 用户申请不通过服务器，大大减小了服务器的压力。
2. 流动预热，针对流动的流动库存能够独立进去，不和一般的商品库存共享服务，流动库存流动开始前提前加载到 redis，查问全副走缓存，最初扣减库存再视状况而定。
3. 独立部署，资源短缺的状况下能够思考针对秒杀流动独自部署一套环境，这套环境中能够剥离一些可能无用的逻辑，比方不必思考应用优惠券、红包、下单后赠送积分的一些场景，或者这些场景能够流动完结后异步的对立发放。这只是一个举例，实际上独自针对秒杀流动的话你必定有很多无用的业务代码是能够剥离的，这样能够进步不少性能。

通过这两步之后，最终咱们的流量应该是呈漏斗状。

超卖

秒杀除开高并发高流量下的服务稳定性之外，剩下的外围大略就是怎么保障库存不超卖了，也能够说要保障的是最终一致性。一般来说，针对下单和库存有两种形式:

1. 下单即扣库存，这是最惯例的大部分的做法。然而可能在流动中会碰到第二点说到的状况。
2. 领取实现扣库存，这种设计我碰到过就是酒店行业，便宜房放进去之后被黄牛下单抢占库存导致失常用户无奈下单，而后黄牛能够用稍高的价格再售卖给用户从中牟利，所以会有在一些流动的时候采取领取胜利后才占用库存的做法。 不过这种形式实现起来比较复杂，可能造成大量的有效订单，在秒杀的场景中不太实用 。

针对秒杀倡议抉择下单扣库存的形式，实现绝对简略而且是惯例做法。

计划

1. 首先查问 redis 缓存库存是否短缺
2. 先扣库存再落订单数据，能够避免订单生成了没有库存的超卖问题
3. 扣库存的时候先扣数据库库存，再扣减 redis 库存，保障在同一个事务里，无论两者哪一个产生了异样都会回滚。有一个问题是可能 redis 扣胜利了因为网络问题返回失败，事务回滚，导致数据库和缓存不统一，这样理论少卖了，能够放到下轮秒杀去。

这种做法能肯定水平上解决问题，然而也有可能会有其余问题。比方当大量申请落在同一条库存记录下来做 update 时，行锁导致大量的锁竞争会使得数据库的 tps 急剧下降，性能无奈满足要求。

另外一种做法就是排队，在服务层进行排队，针对同一个商品 ID 的也就是数据库是一条库存记录的做一个内存队列，串行化去扣减库存，能够肯定水平上缓解数据库的并发压力。

品质保障

为了保证系统的稳定性，避免你的零碎被秒杀，一些品质监控就不得不做。

1. 熔断限流降级，陈词滥调，依据压测状况进行限流，能够应用 sentinel 或者 hystrix。另外前端后端都该有降级开关。
2. 监控，该上的都上，QPS 监控、容器监控、CPU、缓存、IO 监控等等。
3. 演练，大型秒杀事先演练少不了，不能冒冒失失的就上了吧。
4. 核查、预案，预先库存订单 金额、数量核查，是否产生超卖了? 金额是否失常？都是必须的。预案能够在紧急情况下进行降级。

数据统计

流动做完了，数据该怎么统计？

1. 前端埋点
2. 数据大盘，通过后盾服务的打点配合监控零碎能够通过大盘直观的看到一些流动的监控和数据
3. 离线数据分析，预先流动的数据能够同步到离线数仓做进一步的剖析统计

总结

总的来说，面对巨量的流量咱们的形式就是首先通过各种条件先筛选掉有效流量，进行流量错峰，而后再对现有的零碎性能做出优化，比方页面动态化，库存商品预热，也能够通过独立部署的形式和其余的环境做隔离，最初还要解决高并发下缓存一致性、库存不能超卖的问题，避免大量的并发打爆你的数据库。

一个残缺的流动从前端到后端是一个残缺的链路，两头有事先的演练工作，预先的数据分析等都是必不可少的环节。

• END –