近年来无论是电商还是直播带货等业务，都能看到各种秒杀活动，可以说， 秒杀系统 几乎是所有 互联网公司的标配 了。
但是需要明确的是， 区别于电商系统这个笼统的架构 ，秒杀系统具有三个主要特点：
所以对应场景特点，秒杀系统就面临着以下问题：
问题1：如何应对瞬时大流量高并发？
拿双十一的电商秒杀来说，系统能否承载瞬时大流量高并发就是一大难点。
高并发问题的解决思路是 分层过滤，分而治之。 即在不同的层次尽可能地过滤掉无效请求，让“漏斗”最末端的才是有效请求。
具体方法：
由于篇幅有限， 应对高并发的具体方法和代码实现 ，我会在《秒杀系统项目课》中详细讲解，感兴趣的同学可以前去免费试听一下~
问题2：有限库存，如何防止超卖？
因为秒杀的本质，就是对库存的抢夺。每个秒杀的用户来都去数据库查询库存校验库存，然后扣减库存，就可能导致数据库崩溃。
而MysqL 数据库单点能支撑 1000 QPS，但是 Redis 单点能支撑 10万 QPS。因此我们可以将库存信息加载到Redis中，将MysqL的访问压力转移到Redis上，直接通过 Redis 来判断并扣减库存。
实际上，微博、阿里巴巴、百度、美团、拼多多等都在使用Redis。 Redis如今是互联网项目的标配，在面试中非常高频被问到。 使用Redis的原理是：
- 缓存库存信息，大部分数据读取请求都被 Redis 挡住了，保护了MysqL
- 检查 Redis 库存和扣减 Redis 库存是两步操作,通过Lua脚本将这两步操作，合并成一个整体，保证原子操作性
- 哪怕 Redis 侧方行，可以创建订单了，到 MysqL 的时候也需要再检查一次。
问题3：如何保障系统稳定和高可用？
Q1：当秒杀的用户量超过预计，请求量超过服务器最大承载压力怎么办？
解决方案： 流量控制 （flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，保护系统不会被压垮，从而保障应用的高可用性。
2.服务熔断
Q2：当有服务出现故障，不可用时如何应对？
在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
问题4：如何限制用户购买商品件数？
在限购场景中，系统需要针对用户购买商品次数进行限制，一个用户只能购买N个商品，达到限制购买数量户不能继续购买，防止黄牛党。
实现方法：
但这种操作可能会带来这些问题：
2.查询订单表响应时间长
3.QPS过高，数据库压力太大
所以一般会使用 Redis 提供的计数功能，记录用户的购买次数
问题5：如何应对恶意请求和爬虫？
采用验证码机制：
升级版：采用答题机制，更不容易被机器识别出来（有时候连我也不好识别）
秒杀系统的设计思路，我也整理好了：
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
