首先我们应该了解一下一个口罩秒杀系统是怎么运作的。首先是我们在前端页面上看到口罩的商品详情页，然后这个时候可能有一个计时器，显示着还未到秒杀时间，然后开始倒数计时。当到达秒杀时间的时候，就有非常多的人开始点击购买，这些点击会变成无数的请求，穿过复杂的网络环境，到了系统的后台，一般会先到接入服务器，接入服务器校验完地址后，知道上秒杀的请求，转发给对应的CGI,在CGI层会进行一些简单的检验，例如是否是登陆用户，秒杀的数量填写对不对，然后将请求转发给库存系统，进行库存预扣，库存系统会将数据写到数据库里面，然后告诉用户，秒杀成功。
对于一般的业务，我们通常使用的是直筒型的架构设计，也就是有100个人在前端发起抢口罩，就有100个人请求到后台，100个请求到数据库。但是对于这种秒杀这么巨量的业务，海量的查询往往可以让数据库奔溃，所以，我们一般使用漏斗型的架构设计。什么是漏斗型的架构设计呢?就有100万人同时发起抢口罩的请求，可能只有10万人请求到逻辑层，逻辑层再过滤掉一部分人，服务层再过滤掉一部分人，最后只有1万个请求到达数据库，他们都是幸运儿，最终抢到了口罩。
那么怎么去实现这样的功能呢?通常我们会在客户端上面就加上保护，首先是防止用户多次点击，如果用户拼命地点击购买按钮，那么对后台的压力是非常巨大的，所以，我们通常会在用户多次点击的时候，实际只往后台发送一次请求。接下来，我们可以按照一定的百分比，让客户端直接返回失败，或者提醒用户在排队中。低级一点的做法，就是在客户库或者页面生成一个随机数，例如这次口罩的备货只有预约人的千分之一，那么我们可以生成一个小于1000的数，如果生成的数小于5，那么就向后台发起请求，否则直接失败。高级一点的做法，是在cnd这样的边缘节点上部署一些简单的随机数服务，让一定概率的请求到真正的服务后台。这样，1000个人抢口罩，实际上就只有5个人真正到后台去抢购了。
基于大量的秒杀系统都是这么实现的，所以有很多人有遮掩的感觉，明明我已经秒提交了，为什么没能抢购到口罩呢?这下大家应该都明白了吧。欢迎大家关注我，共同学习，共同进步。大家的支持是我继续唠嗑的动力。
