今年的新冠肺炎浪潮，对很多企业的后台系统来说都是一次不小的考验。有个朋友曾经是一家主营医疗药品的云商城。这次服务也被碾压了好几次，口罩、消毒液等物品几乎每次上架，都秒卖光。今天，我们就来简单的讨论一下秒杀系统是怎么做的。首先，我们应该了解面罩尖峰系统的工作原理。首先我们在前端页面看到口罩的商品详情页，然后这个时候可能会有一个计时器，显示秒杀时间还没有到，然后开始倒计时。到了闪购时间，很多人开始点击购买，这些点击会变成无数次请求，经过复杂的网络环境，到达系统后台，通常会先去访问服务器，而接入服务器会在验证地址后，知道秒杀的请求，并转发给对应的CGI。CGI层会做一些简单的检查，比如是否是登录用户，秒杀数是否填写正确，然后将请求转发给库存系统进行库存扣留，库存系统会写将数据存入数据库，然后告诉用户秒杀成功。对于一般业务，我们通常采用直桶架构设计，即前端100人发起抢口罩，100人请求到后台，100人请求到数据库。但是对于如此庞大的业务量，海量的查询往往会导致数据库崩溃，所以我们一般采用漏斗式的架构设计。什么是漏斗式架构设计？有100万人同时请求口罩，只能向逻辑层请求10万人。逻辑层会过滤掉一些人，服务层会过滤掉一些人。最后只有1000条请求到达数据库，都是幸运儿，终于拿到了口罩。那么如何实现这样的功能呢？通常我们会在客户端加上保护，首先是防止用户多次点击，如果用户拼命点击购买按钮，那么后台的压力是非常巨大的，所以我们通常在用户点击多次的时候，只一个请求实际上被发送到后台。接下来，我们可以让客户端按照一定比例直接返回失败，或者提醒用户他们在队列中。一种低级方法是在客户数据库或页面中生成一个随机数。比如这次的口罩库存量只有预订量的千分之一。那么我们可以生成一个小于1000的数，如果生成的数小于5，则向后台发起请求，否则直接失败。更高级的做法是在cnd等边缘节点部署一些简单的随机数服务，让有一定概率的请求可以到达真正的服务后台。就这样，1000个抢口罩的人，真正去后台买的只有5个人。基于大量的秒杀系统都是这样实现的，很多人觉得他们在隐藏它。很明显，我已经秒提交了。为什么我抢不到口罩？现在大家应该明白了吧。欢迎大家关注我，一起学习，一起进步。您的支持是我继续聊天的动力。
