秒杀系统如何设计

Alleria Windrunner 2021-10-05

298

上一篇我们分析了秒杀系统要面临的挑战，那在清楚了秒杀系统所面临的挑战，接下来我们就可以考虑如何应对了。所谓知己知彼，百战不殆。在设计系统之前，我们不妨先来看下，一次 HTTP 请求所经过的链路路径：

这是一个比较宏观的图谱，如果我们提供的是一个 HTTP 服务，那么每个客户端请求进来都要经过这些链路，而每个链路节点的作用又是什么呢？我们逐一看下。

DNS：负责域名解析，会将你的域名请求指定一个实际的 IP 来处理（事先配置好处理请求的 IP，DNS 按顺序指定），并且一般客户端浏览器会缓存这个 IP 一段时间，当下次再请求时就直接用这个 IP 来建立连接，当然如果指定的 IP 挂了，DNS 并不会自动剔除，下次依然会使用它。

Nginx：也就是上面的被 DNS 指定来处理请求的 IP，一般都会被用来当做反向代理和负载均衡器使用，因为它具有良好的吞吐性能，所以一般也可以用来做静态资源服务器。当 Nginx 接收到客户端请求后，根据负载均衡算法（默认是轮询）将请求分发给下游的 Web 服务。

Web 服务：这个就是我们都比较熟知的领域了，一般我们写业务接口的地方就是这了，还有我们的 H5 页面，也都可以放到这里，这里是我们做业务聚合的地方，提供页面需要的数据以及元素。

RPC 服务：一般提供支撑业务的基础服务，服务功能相对单一，可灵活、快速部署，复用性高。RPC 服务一般都是公司内部服务，仅供内部服务间调用，不对外开放，安全性高。

在了解了一次请求所经过的链路节点后，接下来我们再看下，在用户的一次抢购过程中，每次和系统的交互都要做什么事情。

结合之前的秒杀业务流程来看，商品详页部分和支付页部分，对于一般平台来说，都是通用板块，而从“点击抢购”开始到“下单成功待支付”，这一段是属于秒杀系统的业务范畴，在这里我们梳理下，有哪几件事情是需要秒杀系统来做的。

提供活动数据：提供参加秒杀活动的商品信息，主要用于商详页判断活动的倒计时、开始、结束等页面展示和抢购入口校验。

提供结算页：如果把秒杀做成一个单独业务模块，可跨平台（安卓、PC、iOS）嵌入，那么就需要提供一整套服务，包括 H5 页面，主要用于展示商品的抢购信息，包括商品名称、价格、抢购数量、地址、支付方式、虚拟资产等等。

提供结算页页面渲染所需数据：包括用户维度的地址、虚拟资产等数据，活动维度的名称、价格等数据。

提供下单：用户结算页下单，提供订单生成或是将下单数据透传给下游（如果平台有通用的订单接入接口）。

当然在这中间，还有个隐形的，但却是非常重要的核心能力，那就是做流量的精细化筛选，尽量确保传给下游接口的流量，都是优质请求。

以上，我们了解了 HTTP 请求所经过的链路，也总结了秒杀系统所需要提供的能力，那么接下来，我们就可以着手做秒杀系统的设计了。

对于系统的设计，有一些基本的原则，比如校验前置、分层过滤，再结合我们上面的链路路径图，效果如下所示：

一般我们会在 DNS 层做一些和网络相关的防攻击措施，公司的网络安全部门有统一的一些配置措施，这层我们无法写业务，但是可以拦截一些攻击请求。

接下来到 Nginx 层。Nginx 不仅可以作为反向代理和负载均衡器，也可以做大流量的 Web 服务器，同时也是一款非常优秀的静态资源服务器。如果把业务校验也放到这里来，就可以实现校验前置的原则了吗？

Nginx+Lua 说，没问题。这时候可能你会有顾虑，Nginx 担负了那么多任务，会被拖垮吗？不会，因为 Nginx 很强大，能力越大，责任越大。那么 Nginx 为什么比 Apache 服务更强大呢？你可以自己先想一想。

接下来就到了 Web 服务了。我们在这里做业务的聚合，提供结算页页面渲染所需要的数据以及下单数据透传，同时也负责流量的筛选与控制，保证下游系统的安全。

最后就是 RPC 服务。它提供基础服务，一般经过上面 3 层的严格把关，到这里的请求，量已经小很多了，我们写业务逻辑，在技术上也有更多的发挥空间。

文章转载自Alleria Windrunner，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。