数据库看看秒杀系统是怎么实现的

今年这波新型冠状肺炎，对很多公司的后台系统是一个大考，有一朋友，之前主要做医疗药物的云商城，这次服务也被压垮了好几次，几乎每次口罩、消毒水等物品上架，就被秒杀一空。今天，我们来简单地讨论讨论，一个秒杀系统要怎么做。

首先我们应该了解一下一个口罩秒杀系统是怎么运作的。首先是我们在前端页面上看到口罩的商品详情页，然后这个时候可能有一个计时器，显示着还未到秒杀时间，然后开始倒数计时。当到达秒杀时间的时候，就有非常多的人开始点击购买，这些点击会变成无数的请求，穿过复杂的网络环境，到了系统的后台，一般会先到接入服务器，接入服务器校验完地址后，知道上秒杀的请求，转发给对应的CGI,在CGI层会进行一些简单的检验，例如是否是登陆用户，秒杀的数量填写对不对，然后将请求转发给库存系统，进行库存预扣，库存系统会将数据写到数据库里面，然后告诉用户，秒杀成功。

对于一般的业务，我们通常使用的是直筒型的架构设计，也就是有100个人在前端发起抢口罩，就有100个人请求到后台，100个请求到数据库。但是对于这种秒杀这么巨量的业务，海量的查询往往可以让数据库奔溃，所以，我们一般使用漏斗型的架构设计。什么是漏斗型的架构设计呢?就有100万人同时发起抢口罩的请求，可能只有10万人请求到逻辑层，逻辑层再过滤掉一部分人，服务层再过滤掉一部分人，最后只有1万个请求到达数据库，他们都是幸运儿，最终抢到了口罩。

那么怎么去实现这样的功能呢?通常我们会在客户端上面就加上保护，首先是防止用户多次点击，如果用户拼命地点击购买按钮，那么对后台的压力是非常巨大的，所以，我们通常会在用户多次点击的时候，实际只往后台发送一次请求。接下来，我们可以按照一定的百分比，让客户端直接返回失败，或者提醒用户在排队中。低级一点的做法，就是在客户库或者页面生成一个随机数，例如这次口罩的备货只有预约人的千分之一，那么我们可以生成一个小于1000的数，如果生成的数小于5，那么就向后台发起请求，否则直接失败。高级一点的做法，是在cnd这样的边缘节点上部署一些简单的随机数服务，让一定概率的请求到真正的服务后台。这样，1000个人抢口罩，实际上就只有5个人真正到后台去抢购了。

基于大量的秒杀系统都是这么实现的，所以有很多人有遮掩的感觉，明明我已经秒提交了，为什么没能抢购到口罩呢?这下大家应该都明白了吧。欢迎大家关注我，共同学习，共同进步。大家的支持是我继续唠嗑的动力。

严格来说，数据库是长期储存在计算机内、有组织的、可共享的数据集合。数据库中的数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享。