如何设计秒杀系统? _秒杀系统

前言
redis在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。
作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（请允许我使用一下夸张的修辞手法）。
于是在一个寂寞难耐的夜晚，我痛定思痛，决定开始写《吊打面试官》系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！
絮叨
之前写了很多Redis相关的知识点，我又大概回头看了下，除了比较底层的东西没写很深之外，我基本上的点都提到过了，我相信如果只是为了应付面试应该是够了的，但是如果你想把它们真正的吸收纳为己用，还是需要大量的知识积累，和很多实际操作的。
就我自己而言Redis在开发过程中实在用得太普遍了，热点数据的存储啊，整体性能的提升啊都会用到，但是就像我说的技术就是一把双刃剑，使用它们随之而来的问题也会很多的，我在老东家双十二就遇到缓存雪崩问题让整体服务宕机3分钟，相必大家都知道阿里今年的双十一数据了，那三分钟在这种时候到底值多少钱？真的不敢想象。
Redis的普遍我就拿掘金我自己的认知举例，不知道对不对，但是目测是对的。

文章插图

大家看到问题所在了么？是的热门的赞的数据不是最新的，我盲猜一波上面的热门文章是缓存。失效时间应该是几十分钟的，为啥这么做呢？
热门文章是大家共同都会看到的，也就是热点数据，在那做缓存，他是不需要那么高的实时性的，那下面的文章列表是最新发布的文章，有高实时性的特点，大家访问多的放在缓存还可以给DB减少压力，我也不知道掘金是不是这么做的哈，反正道理是这么个道理了。
那什么场景是使用Redis比较复杂的场景，而且需要大量中间件和业务逻辑去配合的呢？
秒杀！是的就是今天的主题秒杀，我就用我自己的思路带大家一起看一下，设计一个秒杀从前到后，从内到外到底要技术人员做多少准备。
正文
首先设计一个系统之前，我们需要先确认我们的业务场景是怎么样子的，我就带着大家一起假设一个场景好吧。
场景
我们现场要卖100件下面这个婴儿纸尿裤，然后我们根据以往这样秒杀活动的数据经验来看，目测来抢这100件纸尿裤的人足足有10万人。（南极人打钱！）

文章插图

你一听，完了呀，这我们的服务器哪里顶得住啊！说真的直接打DB肯定挂。但是别急嘛，有暖男码农之屋在，我们在开始之前应该先思考下会出现哪些问题？
问题
高并发：
是的高并发这个是我们想都不用想的一个点，一瞬间这么多人进来这不是高并发什么时候是呢？
是吧，秒杀的特点就是这样时间极短、瞬间用户量大。
正常的店铺营销都是用极低的价格配合上短信、App的精准推送，吸引特别多的用户来参与这场秒杀，爽了商家苦了开发呀。
秒杀大家都知道如果真的营销到位，价格诱人，几十万的流量我觉得完全不是问题，那单机的Redis我感觉3-4W的QPS还是能顶得住的，但是再高了就没办法了，那这个数据随便搞个热销商品的秒杀可能都不止了。
大量的请求进来，我们需要考虑的点就很多了，缓存雪崩，缓存击穿，缓存穿透这些我之前提到的点都是有可能发生的，出现问题打挂DB那就很难受了，活动失败用户体验差，活动人气没了，最后背锅的还是开发。

超卖：
但凡是个秒杀，都怕超卖，我这里举例的只是尿不湿，要是换成100个华为MatePro30，商家的预算经费卖100个可以赚点还可以造势，结果你写错程序多卖出去200个，你不发货用户投诉你，平台封你店，你发货就血亏，你怎么办？
那最后只能杀个开发祭天解气了，秒杀的价格本来就低了，基本上都是不怎么赚钱的，超卖了就恐怖了呀，所以超卖也是很关键的一个点。