阿里P8面试官：聊聊双11百亿流量「高并发秒杀系统」的设计思路

近年来无论是电商还是直播带货等业务，都能看到各种秒杀活动，可以说，秒杀系统几乎是所有互联网公司的标配了。

但是需要明确的是，区别于电商系统这个笼统的架构，秒杀系统具有三个主要特点：

• 大量用户在同一时间进行抢购，造成瞬时访问量激增
• 用户请求数量往往远大于库存数量
• 业务流程简单，涉及到的操作基本就是下单、减库存

所以对应场景特点，秒杀系统就面临着以下问题：

问题1：如何应对瞬时大流量高并发？

拿双十一的电商秒杀来说，系统能否承载瞬时大流量高并发就是一大难点。

高并发问题的解决思路是分层过滤，分而治之。即在不同的层次尽可能地过滤掉无效请求，让“漏斗”最末端的才是有效请求。

具体方法：

1. 页面静态化
2. 削峰值填谷，通过消息队列异步地创建订单

由于篇幅有限，应对高并发的具体方法和代码实现，我会在《秒杀系统项目课》中详细讲解，感兴趣的同学可以前去免费试听一下~

问题2：有限库存，如何防止超卖？

因为秒杀的本质，就是对库存的抢夺。每个秒杀的用户来都去数据库查询库存校验库存，然后扣减库存，就可能导致数据库崩溃。

而MySQL 数据库单点能支撑 1000 QPS，但是 Redis 单点能支撑 10万 QPS。因此我们可以将库存信息加载到Redis中，将MySQL的访问压力转移到Redis上，直接通过 Redis 来判断并扣减库存。

实际上，微博、阿里巴巴、百度、美团、拼多多等都在使用Redis。Redis如今是互联网项目的标配，在面试中非常高频被问到。 使用Redis的原理是：

1. 缓存库存信息，大部分数据读取请求都被 Redis 挡住了，保护了MySQL
2. 检查 Redis 库存和扣减 Redis 库存是两步操作,通过Lua脚本将这两步操作，合并成一个整体，保证原子操作性
3. 哪怕 Redis 侧方行，可以创建订单了，到 MySQL 的时候也需要再检查一次。

问题3：如何保障系统稳定和高可用？

Q1：当秒杀的用户量超过预计，请求量超过服务器最大承载压力怎么办？

解决方案：流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，保护系统不会被压垮，从而保障应用的高可用性。

2.服务熔断

Q2：当有服务出现故障，不可用时如何应对？

在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。

问题4：如何限制用户购买商品件数？

在限购场景中，系统需要针对用户购买商品次数进行限制，一个用户只能购买N个商品，达到限制购买数量户不能继续购买，防止黄牛党。

实现方法：

①直接查询数据库订单表，查询用户是否已经有购买成功的记录

但这种操作可能会带来这些问题：

1.查询量太大，需要全量扫描订单表查询

2.查询订单表响应时间长

3.QPS过高，数据库压力太大

所以一般会使用 Redis 提供的计数功能，记录用户的购买次数

问题5：如何应对恶意请求和爬虫？

采用验证码机制：

升级版：采用答题机制，更不容易被机器识别出来（有时候连我也不好识别）

秒杀系统的设计思路，我也整理好了：

更多面试难点和秒杀系统设计关键技术，在《秒杀系统项目课》中都会讲到：项目环境搭建方式、秒杀页面和活动功能开发、分布式锁知识及代码实现、分布式ID解决方案、付款和减缓存的数据一致性处理、限流原理讲解等，现在特别开放首节课免费试听，对秒杀系统感兴趣的小伙伴不妨来体验一下。