秒杀系统的挑战和设计思路



Author：Jessie Yang

Date：2020/8/5 V1.0

秒杀业务的影响

1.   正常业务影响：

网站秒杀业务会堆正常网站业务流程带来影响。

2.  服务器影响：

秒杀活动是一种非运营常态的营销手段，带来并发访问用户是平时运营的数百倍甚至上千倍。应对这些最高并发访问量需要的服务器是大部分用不着的。

秒杀系统的挑战

1.   对现有网站业务的冲击

秒杀活动时间短、访问量特大，与原有系统部署一起，可能会导致网站的瘫痪。

2.   高并发下的应用、数据库负载

用户不停刷新浏览器页面，如果常规的架构：应用服务器-数据库服务器，会造成极大的复杂压力。

3.   突然增加的网络及服务器带宽

商品图片的不断刷新加载，网络带宽超过了平时使用限度。

4.   防止有漏洞直接下单

如果能绕过前面秒杀页面，直接绕到后面下单URL，则存在不等秒杀直接下单的漏洞。

秒杀系统的应对思路

1.   秒杀系统独立部署

独立部署系统、还可以独立域名，与业务网站隔离，秒杀系统不会对现有系统造成任何影响。

2.   秒杀商品页面静态化

秒杀商品页面内容全部静态化一个页面，不需要访问数据库和应用服务器。

3.   租借临时的秒杀活动网络带宽

秒杀商品页面缓存在CDN，租用新的出口带宽和CDN，应对最大并发访问。

4.   动态生成随机下单页面url

下单页面需要加动态token，秒杀系统开始时进行随机生成。只有正式开始秒杀，才能有动态url生成和处理。

秒杀系统的设计架构

1.   页面、逻辑一起都要简化；

2.   静态页面全部缓存到CDN、方向代理服务器和用户浏览器。避免到达应用服务器。

3.   秒杀开始按钮点亮，单独用轻量级JS脚本定时动态生成，单独部署JS服务集群，对动态脚本定时更新随机版本号，控制实时秒杀开始。



4.   从入口控制下单数量，利用全局计数器控制可以下单地数量，比如每台下单服务器只接收前10个下单请求，后续全部提示活动结束。（每个环节的阀门控制）。例如：





整体架构如下：

1.   CDN服务器：缓存秒杀商品（压缩合并图片）静态文件；根据实际并发数量，计算需要的服务器和出口带宽。

2.   JS服务器集群：动态生成轻量级地JS文件，控制实际秒杀开始。（按钮点亮）

3.   秒杀商品页面服务器：反向代理服务器

4.   下单服务集群：处理下单请求控制和更新全局计数器。这里会控制每台服务器的请求接受数量，超过则直接提示结束，避免给后端的压力。

5.   订单处理子系统：正常处理后续的订单和支付业务。



服务器、带宽准备举例：