秒杀架构优化，掌握这一个核心原则！ | 架构师之路（18）

《架构师之路：架构设计中的100个知识点》 18.秒杀架构优化

秒杀系统为什么难做？

根本原因，是库存访问集中在一个地方，所有请求会在集中的时间读写库存数据，导致系统锁死。

比如说：华为抢手机，可能库存只有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根据库存情况去处理请求，对自己实施保护。

如此限流，只有非常少的读写请求，会压到后端数据层。

最后，数据层怎么优化？

如果做了前端，站点层，服务层的优化，数据库上的压力就很小了：

1. 没有数据量大的问题，不需要做水平切分；

2. 没有吞吐量大的问题，系统根据自身压力，根据业务库存来保护自己；

数据库层闲庭信步，最多加加缓存抗一下查询压力，单机也能扛得住。

如果有多SKU，可以根据压力情况与SKU情况加机器拆分，总之系统具备线性扩容能力。

总结

还是那句话：尽量将请求拦截在系统的上游，而不要压到库存数据。

知其然，知其所以然。

思路比结论更重要。

补充阅读材料：

《实践出真知：全网最强秒杀系统架构解密》

https://bbs.huaweicloud.com/blogs/300953

来自华为开发者论坛，作者冰河，长文慎入。