在设计一个系统之前，我们需要确认我们的业务场景是什么样的。我会带大家假设一个场景。

场景

我们将在现场销售100片以下婴儿纸尿裤，然后根据之前秒杀活动的数据和经验，估计有10万人会抢到这100片纸尿裤。（南极人赚钱！）

一听就完蛋了，我们的服务器怎么能顶得住！说实话Mokup Frames(样机效果图生成软件)，直接打DB肯定会挂。不过别着急，有暖男敖丙，我们开始之前应该想想会出现什么问题？

高并发问题：

是的，高并发是我们甚至不必考虑的一点。这么多人瞬间进来。这什么时候不是高并发？

是的，秒杀的特点是时间极短，瞬间用户数大。

正常的店铺营销，是用极低的价格，加上短信和APP的精准推送，吸引特别多的用户参与到这个秒杀中，让业务难以发展。

大家都知道，如果营销到位，价格诱人，几十万的流量根本不是问题，感觉3-4W的QPS还是可以承受单机Redis的，但是不管有多高，没办法。好吧，那么这个数据对于一款热销产品来说，可能不仅仅是秒杀。

当大量的请求进来时，我们需要考虑的点很多，比如缓存雪崩、缓存击穿、缓存穿透等。我之前提到的几点都是可能的。如果出现问题，将很难挂起DB。失败的用户体验差，事件的热度没了，最终归咎于发展。

超卖：

任何秒杀的东西都怕被超卖。我这里只是以尿布为例。如果换成100台华为，商家可以通过卖100台的预算来盈利，也可以造势。结果，您编写了错误的程序并卖出了 200 个以上。，你不发货，用户投诉你，平台封你的店铺，你发货的时候血亏。你该怎么办？

（看敖丙的文章没问题，我不怕）

最终只能杀了一个开发者祭天平息。秒杀的价格已经很低了，基本上也不是很赚钱。如果是超卖的话会很吓人，所以超卖也是一个很关键的点。

恶意请求：

你的价格这么低，我抢了就卖，不赚钱？就算不卖，我也不亏。用户知道，你知道，其他别有用心的人（黑客、黄牛……）也必须知道。

这很简单，我知道你什么时候要抓住它，我会造几十台机器，做一些脚本，我还模拟了大约 100,000 人的请求。这是否意味着我基本上有80％的成功率？.

实际情况可能远不止于此，因为机器请求的速度往往比人手的速度要快得多。在贵州敖丙，我每年回家秒抢高铁票。不知道黄牛有没有功劳。，我要diss你，黄牛。买不到周杰伦演唱会的票，我也diss你。

提示：据科普，我从八卦中了解到，黄牛的抢票系统比国内很多小公司的系统要高很多。建筑设计是一流的。我使用顶级匹配的服务和顶级匹配的架构设计。还想看演唱会？还想回家吗？

但是没有黄牛我很难回家。我们云南、桂川和我有太多的孩子要回家过年555！

链接曝光：

前几个问题大家可能都很好理解。看到这里，可能有的朋友会比较疑惑。什么是链接曝光？

相信各位开发同学都熟悉这个画面。稍微懂一点的可以打开谷歌的开发者模式，然后看看你的网页代码。有些有 URL，但是当我写 VUE 时，它是一个事件。触发然后调用文件中的接口查看源代码，但是我可以点击查看你的请求地址，但是你好像可以在秒杀之前把按钮变灰。

不管是什么，都有危险。除了外面的所有东西，你已经屏蔽了它。你这东西卖得太便宜了，太诱人了。你能保证发展不会受到诱惑吗？开发者知道地址，被杀时提前请求。. . （开发：TM怎么又是我）

数据库：

每秒几万甚至几十万的QPS（ per ）直接打到数据库，基本上数据库一定要被打倒，而且你的服务不仅仅是秒杀，还涉及到其他业务，你没有降级，限流、保险丝等，其他的挂在一起。如果是小公司，整个网站可能会因为 404 崩溃。

反正不管怎么秒杀，别挂别的，对，挂了也杀不了程序员。

程序员：我好难！

问题都列出来了，那么如何设计，如何解决这些问题，就是接下来要考虑的，对症下药。服务单一职责：

设计一个能承受高并发的系统，我觉得还是一个单一的职责。

什么意思，大家都知道现在设计是微服务的设计思路，然后采用分布式部署的方式。

也就是说我们下单的时候有一个订单服务，一个用户登录管理之类的用户服务，那我们为什么不给秒杀开一个服务呢，我们把秒杀的代码业务逻辑一起。

为他单独建立一个数据库。当前的互联网架构部署都是子数据库。同样是订单服务对应订单数据库。我们还为他建立了他自己的秒杀数据库。

至于桌子，这取决于你如何设计它。索引应该设置在应该设置索引的地方。记得在构建后使用 SQL 执行计划。（不懂的也可以，我讲MySQL章节）

单一职责的好处是即使秒杀失败，秒杀库崩溃，服务挂掉，也不会影响其他服务。（强制高可用）

尖峰链接与盐：

上面我们提到，如果链接提前暴露，可能会有人直接访问url，提前杀掉。然后另一个朋友想说我应该检查时间。那我告诉你，知道链接地址比手动点击页面还是有很大优势的。

知道url，然后通过程序不断获取最新的北京时间，可以达到毫秒级。我将在 00 毫秒时请求它。我敢说，你手动点的成功率肯定高很多，而且我可以在一毫秒内发送 N 个请求，说不定你卖 100 个产品，我会全部拿走。

如何避免这种情况？

很简单，让 URL 动态化，连写代码的人都不知道。可以用MD5等加密算法加密一个随机字符串制作URL，然后通过前端代码获取URL，通过后台验证。

至于暖男，我准备了一个简单的url加密给大家试试。你为什么不喜欢它？

Redis 集群：

之前不是说单机上的Redis受不了吗？再找几个兄弟很容易。第二个杀手是多读少写。是不是马上就想起了我之前跟大家提过的，Redis集群，主从同步，读写分离，我们还搞了一些哨兵，开启持久化，直接无敌高可用！

Nginx：

想必大家对 Nginx 都不陌生。这个东西是高性能的web服务器，能处理几万并发不是梦，而我们只能处理几百个并发。很简单，负载均衡，每个服务多少次？数百人，然后做更多，在高峰期间租用更多的流量机器。

提示：据我所知，去年春节期间极度扫描，国内一家大型工厂租用了亚洲所有服务器。小公司也喜欢在双十一期间购买流量机器来顶住压力。

您认为您的集群可以做得比这更好吗？

还需要使用恶意请求拦截。一般来说，单个用户的请求数量过于夸张，不像人工请求必须在网关层进行拦截。否则，如果请求太多，他抢不到是一回事，服务器压力很大。它可能会占用网络带宽、使服务器崩溃、破坏缓存等。

资源静态：

尖峰通常是特定的产品和页面模板。现在，前后端一般是分开的，所以页面一般不经过后端，但是前端也需要自己的服务器，所以可以提前放入cdn服务器。把所有的东西都放进去，反正把所有能提高效率的步骤都做好，减少真正秒杀时对服务器的压力。

按钮控制：

有没有注意到，在秒杀之前，按钮一般都是灰色的，只有时间到了才能点击？

这是因为怕大家在最后几秒的时间里疯狂的去请求服务器，然后基本秒杀前服务器就挂了。

这时候就需要前端的配合，定时向你的后端服务器请求，获取最新的北京时间，然后给按钮一个当时的可用状态。

按钮可以点击后，一定要灰显几秒，否则启动后他会继续点击。你敢说你秒杀的时候不是这样吗？

限制：

限流这里我觉得应该分为前端限流和后端限流。

前端限流：这个很简单。一般秒杀不会让你一直点击。一般点击一次或两次，几秒后即可继续点击。这也是保护服务器的一种手段。

后端限流：秒杀必须涉及订单生成、支付等后续操作安卓秒抢注册机，但只有幸运的成功者才会进入那一步。一旦100个产品售罄，如果发出false，前端会直接秒杀结束，然后你的后端也会关闭后续无效请求的干预。

提示：真正的限流还会包括限流元件的加入，比如阿里的等，这里​​就不展开了，只说物理限流。

库存预热：

秒杀的本质是抢库存。每个秒杀用户来找你，你去数据库查库存，查库存，然后扣掉库存。抛开性能因素不谈，你不会觉得它对业务开发人员如此繁琐和不友好。而且数据库受不了。

发展：你tm终于想我一次了。

那该怎么办？

我们都知道数据库受不了，但是他哥的非关系型数据库Redis却受得了！

这并不容易。在我们开始秒杀之前，你需要通过定时任务或者运维同学提前将货物的库存加载到Redis中，这样整个过程都在Redis中完成，然后等待秒杀的引入，然后异步修改它。库存刚刚好。

但是Redis有一个问题。上面我们说我们使用主从，也就是我们会读取库存，然后判断，然后在有库存的时候减少库存。正常情况下是没有问题的，但是高并发的问题就很严重了。大的。

我不会在这里画图。本来想画画的。想了很久，觉得用语言表达可能更好。

产品多次！！！例如，仅剩 1 个库存。我们有高并发。4台服务器一起查询，发现还有1台。然后大家都以为自己抢到了，所以都扣掉库存，结果变成A-3梦幻卡通花纹笔刷，是的只有一台是真的抢到了，其他都超卖了. 该怎么办？

卢阿：

上一篇文章简单地提到了他，所以今天我就稍微多一点的篇幅说一下。

Lua脚本功能是Reids在2.6版本中最大的亮点。通过对 Lua 环境的内置支持，Redis 解决了长期无法高效处理 CAS（check-and-set）命令的问题。组合多个命令可以轻松实现以前难以或不可能有效实现的模式。

Lua脚本类似于Redis事务，具有一定的原子性，不会被其他命令打断，可以完成一些Redis事务性操作。这是关键。

知道了原理，我们就写一个脚本，把判断库存扣减库存的操作写在一个脚本里，发给Redis来做。当它达到0时，它之后的一切都是False，对吧？如果它失败了，你修改一个开关并直接阻止它。所有的请求，然后做剩下的。

限流&退化&熔断&隔离：

你为什么要这样做？不怕一万，以防万一，实在受不了了，就限流，受不了的就屏蔽一些，但不能说不，降级，降级或者挂了，Fuse，至少不要影响其他系统，隔离，你是独立的，但是你会调用其他系统，你要死了，不要拖累你的兄弟们。

削峰填谷：

一提到这个词，很多朋友就知道了。是的，MQ，如果你买的东西少，你直接请求100个请求来改变数据库。我觉得没问题，但是一秒杀一万，那十万呢？服务器挂了，程序员又要承担责任了。

提示：可能有朋友说我们的业务达不到这个规模安卓秒抢注册机，所以没必要。但是我想说，我们在写代码的时候，不应该写有逻辑漏洞的代码。至少在未来，公司规模会越来越大，其他人一看就不需要改代码。乍一看，代码的作者是敖丙？某物！

你可以把它放到消息队列中，然后花一点点去改变库存，但是单项修改就足够了。我这里说的是多个物品在某个时间点一起被杀死的场景，比如双十一。

总结

至此，我想我已经基本说了应该考虑的点和相应的解决方案。我不知道有没有我没有考虑过的，但即使我不考虑我的设计，我也应该能够支持它。活一个完整的秒杀过程。

最后画一个完整的流程图给大家收尾！

提示：这个链接比较简单。绘制所有细节太复杂了。我已经提到了上面所有的注意点。大家来看看吧。真正的秒杀比我的简单，还有更多的我复杂N倍。老电商老板干得很高级。如果有机会我可以和你讨论。这只是一个采访。我会给你一些想法，以便你理解更关键的点。

这一章脑细胞死了很多，也考虑了很多点，终于出来了，忍不住赞叹自己！

（这章真不是白卖的，每次看都看不惯。你要不要白卖我？你好不坏，但我很喜欢）