秒杀系统为什么难做？
根本原因，是库存访问集中在一个地方，所有请求会在集中的时间读写库存数据，导致系统锁死。
比如说：华为抢手机，可能库存只有5K部，但瞬时进入的流量可能是十万百万。
又比如说，12306抢票，余票很少，瞬时流量会更高。
怎么优化？
最核心的优化思路是：尽量将请求拦截在系统的上游，而不要压到库存数据。
怎么拦截？
常见的分层架构如上，从上到下逐层拦截。
首先，端上拦截。
- 产品层面：用户点击“查询”或者“抢购”后，按钮置灰，禁止用户重复提交请求。
- 技术层面：前APP端，或者H5端，限制同一个用户在10秒之内只能向服务端提交一次请求，重复的请求前端直接返回。
如此限流，可拦截不少流量。
有人要说了，这个可行吗？端上拦截，只能拦住小白用户，大部分流量都是程序员抓包写脚本，for循环，直接调用后端的HTTP接口访问，那怎么办？
第二步，web-server站点层拦截。
秒杀类的电商场景，用户需要登录，登录就有token，有uid的唯一标识。
在站点层，同一个uid，做限速，限制同一个用户在10秒之内只能向service提交一次请求，重复的请求直接返回。
如此限流，用脚本写for循环抢购的请求，99%又被拦住了。
又有人要说了，同一个uid确实被拦住了，那万一有一个黑客，控制了10W个账号，10W个uid同时抢手机，该怎么办呢？
第三步，service服务层拦截。
系统上线，一般都做过压测，对service的服务能力是清楚的，假如每秒只能服务1W的吞吐，中间可以加一个MQ，采用拉模式来做削峰填谷，service根据自己的服务能力去处理请求，对自己实施保护。
又有人要说了，万一没做过压测，不知道service的服务能力怎么办？
业务层面，我们知道手机的库存量，假如库存只有5K部手机，放过去10W个请求，没有意义。还是加一个MQ，还是采用拉模式来做削峰填谷，service根据库存情况去处理请求，对自己实施保护。
如此限流，只有非常少的读写请求，会压到后端数据层。
最后，数据层怎么优化？
如果做了前端，站点层，服务层的优化，数据库上的压力就很小了：
- 没有数据量大的问题，不需要做水平切分；
- 没有吞吐量大的问题，系统根据自身压力，根据业务库存来保护自己；
数据库层闲庭信步，最多加加缓存抗一下查询压力，单机也能扛得住。
如果有多SKU，可以根据压力情况与SKU情况加机器拆分，总之系统具备线性扩容能力。
总结
还是那句话：尽量将请求拦截在系统的上游，而不要压到库存数据。
知其然，知其所以然。
思路比结论更重要。
