【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下:

1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类;

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品;

3. 正常的日活大约 100 万用户;

4. 老板要求万无一失。

【技术背景】

1. 技术团队以 Java 为主，已经落地了微服务架构;

2. 主要渠道是自有的 App(包括 iOS 和 Android)和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动;

3. 目前只有单机房。

【架构设计】

存储架构

负载均衡架构

缓存架构

先看看秒杀场景特点。秒杀开始前几分钟，大量用户开始进入秒杀商品详情页面，很多人开始频繁刷新秒杀商品详情页，这时秒杀商品详情页访问量会猛增。秒杀开始，大量用户开始抢购，这时创建订单，扣库存压力会显著增大。实际上，秒杀场景基本都是秒杀参与人多，秒杀成功的人却寥寥无几，结合本次案例来看 100 万用户抢 1010 个商品库存。

针对本次案例的业务背景设计秒杀系统主要涉及以下几个方面：

秒杀业务流程上的考虑：

由于参加秒杀的商品售卖价格非常低，基本都是“抢到即赚到”，成功下单后却不付款的情况非常少。所以我们采用下单减库存的方案，下单时扣减库存，然后再进行支付。假如真有个别订单不付款怎么办？没关系，秒杀好活动最主要的目的是吸引流量，个别订单不支付对秒杀活动本身影响不大。况且，没支付剩下的库存还可以做为普通商品继续售卖。不过要注意对机器人和自动脚本的防御。

秒杀商品信息缓存：

“秒杀开始前几分钟，大量用户开始进入秒杀商品详情页面，很多人开始频繁刷新秒杀商品详情页，这时秒杀商品详情页访问量会猛增”。如果请求全部打到后端服务，那后端服务的压力会非常大（后端服务要处理业务逻辑，而且还要访问数据库，吞吐量比较低）。

考虑到秒杀是运营同学提前安排的活动，要秒杀哪些商品、商品价格等信息在秒杀活动开始前已经确定下来，所以我们可以把秒杀商品详情分两部分做缓存，图片上传到 CDN 上预热，用 CDN 扛流量，文字描述用 redis 缓存并且提前预热商品防止缓存击穿。这样既可以提高访问速度，也没有给网站增加压力，同时也减少了网站带宽压力。

另外也可以在 app 内做一层缓存。

请求拦截：

前端页面，相关按钮点击后置灰，防止重复提交

网关（gateway，nginx）层，为了避免前端恶意请求，比如一些攻击脚本，在网关层要对下单等接口按 userID 限流，几秒钟只能访问一次。考虑到秒杀场景参与人多，秒杀成功的人极少，我们可以把绝大部分抢购下单请求在网关层直接拒掉，按秒杀失败处理。这样就极大减少了后端服务的压力。

因为本次抢购商品库存 1010 个，我们可以只放行 1010 个请求到后端服务。要注意，为了尽量避免库存被机器人和自动脚本抢走，1010 个请求不能在秒杀开始瞬间同时放行，可以分段放行，比如秒杀开始后随机选取 200ms 内的 202 个请求放行（这 200ms 内的其他请求直接拒掉，按秒杀失败处理），之后每隔 200ms 放行 202 个请求，1 秒钟可以放行完 1010 个请求。分段放行，除了限制了机器人和自动脚本，把请求分散在各个时间段，还进一步缓解了后端服务的压力。

分段放行总时间不能太长，假如每 200ms 放行 1 个请求，放行完所有 1010 个请求需要 202 秒时间，这样用户就会明显感知到下单早的人没秒杀成功，下单晚的人反而秒杀成功了，用户体验会变差。

另外，秒杀过程网关压力会比较大，网关可以做成集群，多节点分摊访问压力。

后端服务设计：

秒杀库存只有 1010 个，经过网关拦截，再加上采用分段放行的方式，对于后端服务基本没什么压力了，日常的后端服务就完全可以支撑秒杀活动了。不用再做更复杂的设计。不过，假如秒杀库存有几万个，放行的下单请求就有几万个，为了用户体验放行总时间也不能太长，这时后端服务该怎么设计呢？

这时主要压力就在数据库了，扣减库存压力，创建订单压力。

库存可以放到 Reids 缓存中，来提高扣减库存吞吐能力。对于热点商品的库存可以利用 Redis 分片存储。

创建订单可以走异步消息队列。后端服务接到下单请求，直接放进消息队列，监听服务取出消息后，先将订单信息写入 Redis，每隔 100ms 或者积攒 100 条订单，批量写入数据库一次。前端页面下单后定时向后端拉取订单信息，获取到订单信息后跳转到支付页面。用这种批量异步写入数据库的方式大幅减少了数据库写入频次，从而明显降低了订单数据库写入压力。

网络：

秒杀前要和网络运营商、CDN 服务商提前申请带宽。

还有哪些细节要考虑：

1.如何避免超卖？如果在 redis 中扣减库存，可以利用 decr 命令扣减库存，decr 是原子操作，在分布式环境下也不会有并发问题，decr 扣减库存后，判断返回值，如果返回值小于 0，扣减库存失败，秒杀也就失败了；如果在数据库中扣减库存可以在 where 后面加上库存大于 0 的条件，来避免库存被减成负值。这样就可以避免超卖情况发生了。

2.接口防刷，前面已经提到过，在网关层对下单等接口按 userID 限流。

3.网关层除了对 userID 做限流外，还要做整体限流。在实际访问量超过预估访问量时，整体限流可以起到保护作用，避免系统被压垮。

4.防止重复下单，按 userID 限流已经起到了防止重复下单的作用。假如限制同一个用户 10 分钟能下一次单，一般情况下 10 分钟内，商品早已经被抢光了，用户也就没有再次下单的机会了。

5.可以结合风控系统，在网关层把羊毛党等有问题的用户请求直接拒掉。

6.可以在网关层上面再加一层防火墙或者高防服务，来防御 DDos 等分布式网络攻击。

百万级电商秒杀架构设计相关推荐

架构思维成长系列教程（七）- 大型电商系统架构设计
背景大型电商网站,指的是每日用户访问量达到数百万,每日页面访问量达到数千万乃至上亿级别的网站,达到这个规模的电商网站在国内不多. 内容架构设计分为两部分:应用架构设计和基础架构设计应用架构设计: ...
技术干货（2 of 5）：电商秒杀架构分析
在上一篇"分析与实战:微信红包体系的整理"文章中,我们对微信红包的体系结构进行了非常深入详细的剖析,并且着重讨论了微信红包在高并发环境下所面临的问题及应对的策略. 说到高并发,其实 ...
电商系统架构设计系列（一）：电商系统到底是如何设计出来的？
引言电商这个业务,和我们的生活息息相关.你可能对电商多少有一些了解,但是,即使是一个最小化的电商系统,它仍然非常复杂. 在这个系列的文章里,我们将一起以一个创业公司的 CTO 的视角,来设计一个最小 ...
电子商务商城系统开发方案：中大型交易类电商网站架构设计
电子商务平台企业打造一个交易型电商网站,首先必须考虑几个基本要素:用户.电商平台商品.订单信息等,那么要能够支持一个电子商务网站平台打造完整交易过程就需要包括用户信息.商品数据的匹配过程.安全支付过程 ...
百万级报警平台的架构设计与实现
本文根据肖双2018年10月19日在[第十届中国系统架构师大会]上的演讲内容整理而成. 讲师介绍: 肖双,去哪儿网高级运维开发,目前负责去哪儿网监控系统的设计.开发和运维工作,对DevOps理念有深入 ...
图胜千言：电商支付架构设计
交易核心支付编排作者:热黄油啤酒来源:juejin.cn/post/7004756545741258765 往期推荐千万级流量的大型分布式系统架构设计技术转管理,用什么来拯救自己? 40岁从 ...
电商数仓描述_大数据企业级电商数据仓库架构设计和实现（技术点与企业接轨）...
课程咨询和资料获取请加老师QQ 1011800132 该项目以国内电商巨头实际业务应用场景为依托,紧跟大数据主流需求,对电商数仓的常见实战指标以及难点实战指标进行了详尽讲解,让你迅速成长,获取最前沿 ...
图解：电商支付架构设计
欢迎关注方志朋的博客,回复"666"获面试宝典交易核心支付编排作者:热黄油啤酒来源:juejin.cn/post/7004756545741258765 热门内容: Doc ...
图解电商支付架构设计，这才是真电商！
交易核心支付编排作者:Petter Liu 出处:http://www.cnblogs.com/wintersun/

百万级电商秒杀架构设计