提到秒杀, 很多人都会觉得这是一件技术要求很高的事情, 因为这涉及到超大访问量(可能瞬间千万倍的用户访问商品)、维护数据一致性(不能超卖), 前者对性能有极高的要求, 而后者又正好拉低了性能,本文谈谈秒杀的设计思路, 并在最后给出秒杀设计的简单模型图。

秒杀的情景

生活中有很多秒杀的情景, 例如商家促销, 像一元抢茅台, 五毛钱抢宝马(这儿只是一个例子), 假如一百万人来抢十瓶茅台, 这时候肯定不能多卖出, 也就是不能被大于10的人数抢到, 通常最后时间会有一个倒计时按钮, 30...29...28......3...2...1 GO! 之后跃跃欲试的人们开始抢。

这时候有以下问题需要被考虑 :

第一是多个客户端的时间如何保持同步, 也就是让大家看到时间是一致的, 不能你显示3, 而我这还显示 30 。

第二是如何保证有没有黄牛用机器人抢 。

第三是如何确保后端服务器可以支撑住这巨大的流量。

......

秒杀解决思路

有了上面的情景以及引出来的问题, 来看看秒杀方案的设计思路, 我们服务器如何应对这一百万的TPS呢?

首先想到的是扩容, 但这是不现实的, 因为扩容需要很多很多机器, TPS增加一万倍对物理服务器的性能要求远远不止一万倍, 另外对于一个商家来说, 为了这一次促销活动购置服务器是不划算的, 平时势必有众多的机器处于闲置状态。

没法扩容, 那么也就意味着要使用其他方法, 如果所有请求访问一台物理机器肯定不行, 一百万的数据访问无论如何分库分表都无济于事, 因为面对的每一条都是热点数据, 所以要用到分布式架构的思路。

秒杀的技术方案

分布式, 可以降低服务器的压力, 下面开始讲述秒杀的设计思路。

方案一

很明显, 要让一百万用户能够同时打开抢货的网页, 势必要用要到CDN(内容分发网络, CDN主要作用有两个, 一方面是将一些不会改变的静态资源放到离客户端较近的边缘服务器上, 这样客户端请求数据的时候可以直接从边缘服务器获取, 降低中心服务器的压力, 另外一方面可以把小服务部署到 CDN 结点上去，这样，当前端页面来问开没开始时，这个小服务除了告诉前端开没开始外，它还可以统计下有多少人在线。每个小服务会把当前在线等待秒杀的人数每隔一段时间就回传给我们的数据中心，于是我们就知道全网总共在线的人数有多少。

假设，我们知道有大约 100 万的人在线等着抢，那么，在我们快要开始的时候，由数据中心向各个部署在 CDN 结点上的小服务上传递一个概率值，这个概率值为CDN节点人数权重乘以获奖概率, 比如说是