秒杀流动是指网络商家为促销等目标组织会网上限时抢购流动，这种流动具备刹时并发量大、库存量少和业务逻辑简略等特点。设计一个秒杀零碎须要思考的因素很多，比方对现有业务的影响、网络带宽耗费以及超卖等因素。本文会探讨秒杀零碎的各个环节可能存在的问题以及解决方案。

秒杀零碎

傻瓜式秒杀零碎

秒杀零碎的外围难点是并发量，如果不思考并发问题，那么咱们能够用如下图所示的简略的系统结构来实现秒杀零碎，用户只有两个简略操作：刷新界面和秒杀按钮，服务端也只有两个服务接口：返回秒杀界面和解决秒杀逻辑。假如本文中秒杀商品有 100 个，参加秒杀的用户有 100w 个。

然而在高并发场景下，这个零碎会有很多问题，咱们全文会针对这些问题一一进行优化

1. 大量用户同时刷新界面，会对服务器的带宽造成十分大的压力；
2. 用户在秒杀前后能够多次重复点击按钮，造成很多不必要的申请；
3. 用户能够通过脚本进行抢购，并且抢购成功率十分高；
4. 服务端接受高并发申请，会呈现响应过慢或失败等状况；
5. 数据库接受高并发申请，会导致连接池耗尽和响应迟缓；
6. 如果数据库更新设计的不合理，可能会呈现超卖的状况；

秒杀界面 CDN

秒杀开始之前，用户都会申请秒杀界面，有的用户甚至会一直的刷新秒杀界面，100W 用户可能产生上千万次秒杀界面申请。秒杀界面往往蕴含很多动态资源，如果这些界面申请全副通过服务器获取，会造成大量的带宽耗费，甚至造成秒杀还没开始服务器就崩了的状况。

对于网页这种动态资源的并发拜访，业内早就有成熟的解决方案：内容散发网络 (CDN)。咱们能够在秒杀开始前，事后把网页的动态资源寄存在 CDN 节点，用户在刷新界面时间接从 CDN 获取动态资源，从而升高刷新秒杀界面对服务器造成的压力。增加了 CDN 服务之后，秒杀界面有大量用户同时拜访和刷新并不会给服务端带来多大压力。

秒杀按钮优化

咱们晓得，秒杀零碎往往会有一个秒杀按钮，如果不对按钮限度，可能存在以下问题：

• 用户在秒杀开始前点击按钮，造成很多无用申请；
• 用户在秒杀开始后屡次点击按钮，造成很多反复申请；

所以咱们能够对按钮做一些限度：秒杀开始前按钮不可用，用户点击一次秒杀按钮后，按钮也进入不可用状态。这种形式无奈限度通过脚本申请后端的状况，然而能够限度失常用户的屡次有效点击，大大降低申请量。

秒杀链接优化

一般状况下，用户在点击秒杀按钮的时候，前端会申请一个固定的 URL，这个 URL 能够在前端界面查到。对于一般不懂技术的用户来说，这没有什么问题，如果用户略微懂点 Http 协定，就能够在秒杀开始前拿到 URL，在秒杀开始前或开始的毫秒级工夫内申请秒杀链接，不仅会给服务端带来很大的压力，还会造成不偏心景象：商品都被开脚本的人抢走了。

为了防止这种景象，咱们能够将 URL 动态化，即便秒杀零碎的开发人员也无奈在通晓在秒杀开始时的 URL。具体实现办法是在获取秒杀 URL 的接口中，返回一个服务器端生成的随机数，并在下单 URL 中传递该参数实现下单。

秒杀验证码

尽管说我下面通过动静 URL 防止了用户在秒杀开始前申请秒杀链接，然而用户还是能够通过脚本在秒杀开始的那一刻去申请秒杀连贯，普通用户根本没有方法和脚本秒杀进行竞争。

咱们能够引入机器难以辨认的验证码，用户在申请秒杀链接之前，须要填写验证码辨认的后果，验证码谬误的申请间接回绝。应用验证码不仅能够减少脚本秒杀的难度，还能够升高申请的 QPS，因为申请不再是在秒杀那一刻进来，而会被扩散到填写验证码的时间段内。

过滤申请

通过下面的步骤，咱们能够缩小很多反复申请和脚本申请，能够保障秒杀流动中一个人大抵只会申请一次 (脚本还是能够申请屡次)。然而 100W 人参加秒杀，每人申请一次秒杀链接也有将近 100W 次申请，服务器还是扛不住。

仔细分析之后能够发现，秒杀的商品只有 100 个，最初胜利的也只有 100 个，那么咱们 100W 的申请是不是都有必要申请到秒杀服务器上呢？不言而喻，咱们没有必要把所有申请都打到秒杀服务器上，咱们只须要保障有大于 100 个申请打到秒杀服务器就能够保障秒杀的失常进行，所以咱们能够在用户端和服务端增加一层过滤层，过滤层只有保障有 100 个以上的申请能打到秒杀服务器端。

咱们能够应用 Nginx 服务器来构建过滤层，一个 Nginx 服务器也没法抗 100W 的申请，咱们假如每个 Nginx 服务器能够解决 10W 的申请，那么咱们就须要 10 台 Nginx。那么怎么用保障至多有 100 个申请能够申请到后端呢？咱们能够简略的让每个 Nginx 服务器只通过前 100 个申请，后续申请间接返回降级界面。通过 Nginx 过滤，咱们能够把 100W 的申请过滤为 1000 个申请，大大减少了服务器端的压力。

Redis 缓存

如果通过后面的过滤，申请量仍旧十分大，如果数据库无奈解决这些申请量，咱们就须要在数据库之上增加一层 Redis 缓存了。单个 Redis 能够解决几万的 QPS，如果预估申请的 QPS 大于几万，咱们还能够应用 Redis 集群模式来减少 Redis 的解决能力。

在 Redis 寄存和售卖商品数目大小雷同的数字，秒杀服务每次拜访数据库之前，都须要先去 Redis 中扣减库存，扣减胜利能力持续更新数据库。这样，最终到的数据库的申请数目和须要售卖商品的数目基本一致，数据库的压力能够大大减少。

Redis 原子性

咱们晓得 Redis 是不反对事务的，所以可能呈现扣减为正数的状况，这种状况下咱们能够应用 Lua 脚本来保障一次扣减操作的原子性，从而保障扣减后果的正确性。

异步更新数据库

通过 Redis 判断之后，去更新数据库的申请都是必要的申请，这些申请数据库必须要解决，然而如果数据库还是解决不过去这些申请怎么办呢？

这个时候就能够思考削峰填谷操作了，削峰填谷最好的实际就是 MQ 了。通过 Redis 库存扣减判断之后，咱们曾经确保这次申请须要生成订单，咱们就能够通过异步的模式告诉订单服务生成订单并扣减库存。

我是御狐神，欢送大家关注我的微信公众号:wzm2zsd

本文最先公布至微信公众号，版权所有，禁止转载！