如果1分钟内要支持抢购10w个口罩，你该如何设计系统架构？

目录

• 业务背景
• 业务架构设计
• 网络拓扑架构设计
• 秒杀业务流量洪峰
• 架构设计优化
• 总结

背景

大家好，这篇文章给大家介绍一个非常经典的去大厂面试经常被问的一个问题，就是瞬时高并发抢购问题。

通常来说，大厂开发的系统经常会遇到一些类似电商秒杀抢购、景点门票高并发抢购、特殊商品（比如口罩）高并发抢购、类似 12306 的高并发抢票类的系统。

所以经常会问这一类高并发抢购类的问题，这个时候，小伙伴们如果不能有理有据的给出一整套高并发场景下系统可能遇到的各种问题，以及你对应的架构设计和解决方案，那基本面试可能就会凉掉。

所以今天就手把手带着大家来分析一下，假设在特殊物品库存紧缺的场景下，1 分钟内要抢购 10w 个口罩这类特殊物品，此时可能有数十万人这个量级瞬时涌入来进行抢购，这个时候系统可能会遇到哪些问题，我们应该如何来设计架构解决这类问题呢？

---

业务架构设计

首先在分析这一类问题的时候，我们先不要考虑这个瞬时高并发到底有多高，先得把实现购买这类特殊商品的一个基础业务架构图画出来，同时把业务流程分析清楚。

大家看下图，如果你要搞一个商品抢购的系统，肯定得有一个抢购系统，这个抢购系统你得依赖商品系统吧，毕竟抢购过程中需要对商品数据进行读写，你还得依赖库存系统进行库存扣减，同时你还得依赖价格系统来计算当前商品的购买价格，还得依赖营销系统来验证商品购买的优惠。

最后还得依赖鉴权认证、风控拦截类的基础系统来确定本次抢购是否可以执行，所以说，一次抢购涉及到的各种系统其实是很多的，完整的基础高并发抢购系统基础业务架构图。

如下图 1 所示：

网络拓扑架构设计

另外的话，大家还得对你的抢购请求是如何一步一步到达你的抢购系统的，这个事情流程大家也是要画出来的。

一般来说，我们的 APP 移动端对后端访问都是通过一个域名来发起请求的，这个域名会经过 DNS 进行解析得到我们的 SLB 负载均衡系统的 ip 地址。

然后请求会发送到我们的 SLB 负载均衡系统上去，接着 SLB 负载均衡系统会把请求均匀分发给我们后端的 API 网关系统，然后 API 网关系统再把流量分发给我们的抢购系统。

所以大致如下图 2 所示：

好的，当大家能当着面试官的面，麻溜儿的把上面那套业务架构图和生产部署网络拓扑图大致画出来以后，我们可以跟大家保证，虽然这个时候面试官看起来面无表情，但是心里的真实反映应该是这样的：小兄弟可以啊，一般人听到这个问题就直接懵逼了，这小子居然知道先从业务架构和网络拓扑架构入手进行分析。

但是大家别高兴的太早，距离你圆满的完成这个问题的分析，大致