架构设计｜秒杀系统设计(分布式微服务)

流程图(分布式)

例子

现场要卖1000件下面这个婴儿纸尿裤，根据以往这样秒杀活动的数据经验来看，目测来抢这100件纸尿裤的人足足有10万人

问题

高并发

秒杀的特点就是这样时间极短、 瞬间用户量大。

正常的店铺营销都是用极低的价格配合上短信、APP的精准推送，吸引特别多的用户来参与这场秒杀

秒杀大家都知道如果真的营销到位，价格诱人，几十万的流量我觉得完全不是问题，那单机的Redis我感觉3-4W的QPS还是能顶得住的，但是再高了就没办法了，那这个数据随便搞个热销商品的秒杀可能都不止了。

大量的请求进来，需要考虑的点就很多了，缓存雪崩，缓存击穿，缓存穿透这些点都是有可能发生的，出现问题打挂DB那就很难受了，活动失败用户体验差，活动人气没了，最后背锅的还是开发。

超卖

但凡是个秒杀，都怕超卖，这里举例的只是尿不湿，要是换成100个MacBook Pro，商家的预算经费卖100个可以赚点还可以造势，结果你写错程序多卖出去200个，你不发货用户投诉你，平台封你店，你发货就血亏，你怎么办？

那只能杀个开发祭天解解气了，秒杀的价格本来就低了，基本上都是不怎么赚钱的，超卖了就恐怖了呀，所以超卖也是很关键的一个点。

恶意请求

你这么低的价格，假如我抢到了，我转手卖掉我不是血赚？就算我不卖我也不亏啊，那用户知道，你知道，别的别有用心的人（黑客、黄牛…）肯定也知道的。

那简单啊，我知道你什么时候抢，我搞个几十台机器搞点脚本，我也模拟出来十几万个人左右的请求，那我是不是意味着我基本上有80%的成功率了。

真实情况可能远远不止，因为机器请求的速度比人的手速往往快太多了。

小道消息了解到的，黄牛的抢票系统，比国内很多小公司的系统还吊很多，架构设计都是顶级的

链接暴露

前面几个问题大家可能都很好理解，一看到这个有的小伙伴可能会比较疑惑，啥是链接暴露呀？

相信大家都对这个画面一点都不陌生吧，没错，这就是浏览器的开发者模式，然后看看你的网页代码，有的就有URL，但是我写VUE的时候是事件触发然后去调用文件里面的接口看源码看不到，但是我可以点击一下查看你的请求地址啊，不过你好像可以对按钮在秒杀前置灰。

不管怎么样子都有危险，撇开外面的所有的东西你都挡住了，