秒杀系统设计
传统系统架构设计
在ToB场景下可以正常完成,但是在ToC场景下,用户量会非常大,活动开启瞬间,带宽资源很稀缺的情况下,可能会出现用户进不了结算页,或者进了结算页却不能正常渲染页面的问题,导致抢购体验大幅下降。
秒杀系统架构设计
NGINX的优点:模块化,事件驱动,异步,非阻塞,多进程单线程
Nginx的工作模型。以Linux为例,其采用的是epoll模型(即事件驱动模型)该模型是IO多路复用思想的一种实现方式,是异步非阻塞的,什么意思呢?就是一个请求进来后,会由个worker进程去处理,当程序代码执行到IO时,比如调用外部服务或是通过upstream分发请求到后端Web服务时,IO是阻塞的,但是worker进程不会一直在这等着,而是等 IO 有结果了再处理,在这期间它会去处理别的请求,这样就可以
充分利用 CPU 资源去处理多个请求了。
Web/RPC服务技术选型
SpringMVC+Dubbo+MySQL+Redis
首先至少有3个系统服务
- Nginx服务:
流量筛选:根据黑白名单,登录态和参数有效性等进行流量筛选,将无效的请求拦截在Nginx层,减少无效请求对后端服务的压力。
流量分发:通过设置的负载均衡算法进行流量分发,也可以自定义算法,比如根据IP做hash分发或者根据用户ID做hash分发,这样可以保证同一个用户的请求都会分发到同一个后端服务上,从而保证秒杀的一致性。
简单业务以及校验:提供活动数据、活动有效性校验、库存数量校验和其他业务相关的简单校验等。
限流:根据IP或者自定义参数进行限流,比如限制每秒钟只能访问一次,或者每秒钟只能访问N次,或者每秒钟只能访问N个商品等。
异常提示页面:当后端服务出现异常时,可以通过Nginx服务返回一个友好的提示页面,比如活动还未开始,活动已经结束,活动已经售罄等。 - Web服务
提供结算页H5:灰色发布,项目功能一般不是全量发布的,而是有计划第逐步灰度上线,这样可以保证系统的稳定性
业务聚合接口
其他功能 - RPC服务
提供基础服务,数据支持,包括活动数据、商品数据、用户维度数据、提单等,主要模拟基础服务,正常情况下,应该是按业务模块做细致划分的
demo-web服务设计
- 基于SpringMVC框架,新建三个子模块:gateway,common,service
- gateway:对外HTTP接口定义,以及SpringMVC相关文件配置
- service:业务逻辑实现,包括秒杀活动数据查询,活动有效性校验,库存数量校验,提单等
- common:用来存放公共的类,比如常量类,工具类,异常类等
当web项目搭建完成后,就可以和我们之前搭建的nginx项目联动一下了,即请求先到 Nginx,被其配置的location拦截,经过处理后将其分发给web。所以接下来我们需要对 nginx做一些修改。
- 在config文件夹中,新建一个upsteam.conf文件,用来配置web服务的地址和端口
upstream backend {
server 127.0.0.1:8080;
}
- 修改domain.com中的server配置文件,新加一个proxy_pass配置,用来将请求分发给web服务
server {
listen 7081;
localtion /sayhello {
default_type text/plain;
proxy_pass http://backend;
}
}
- 在nginx.conf中引入upstream.conf文件
worker_processes 1;
err_log logs/error.log error;
events {
worker_connections 256;
}
http {
lua_package_path "/usr/local/Documents/seckillproject/demo-nginx/lua/?.lua;;";
include /usr/local/Documents/seckillproject/demo-nginx/domain/domain.com;
include /usr/local/Documents/seckillproject/demo-nginx/upstream.conf;
}
- 重启nginx服务
demo-rpc服务设计
新建5个子模块:common,service,dao,export,launcher
common 存放公共类,比如常量类,工具类,异常类等
dao:存放数据访问层代码,比如数据库访问层代码,redis访问层代码等
export:存放对外提供的接口,比如dubbo接口,http接口等
service:存放业务逻辑代码,比如秒杀活动数据查询,活动有效性校验,库存数量校验,提单等
launcher:项目文件配置,监控,拦截器等,同时也是打包部署的入口
秒杀项目流程
所以秒杀系统的主要接口有:
- 活动数据查询接口:查询活动相关信息,包括开始,结束时间
- 进结算页页面接口:结算页H5,并通过AJAX异步加载结算页数据
- 结算页页面初始化渲染锁需数据的接口:大体上包括活动信息,商品信息,结算信息等
- 结算页页面用户行为操作接口:支持地址列表查看和选择,虚拟资产的查看和使用等,并在操作后更新页面价格相关信息
- 结算页提交订单接口:支持秒杀活动商品下单
因此数据库需要如下三张表:
上述接口配置到Nginx中,为此修改domain.com中的server配置文件,新加一个proxy_pass配置,用来将请求分发给web服务
server {
listen 7081;
localtion /sayhello {
default_type text/plain;
proxy_pass http://backend;
}
# 活动数据查询
location /activity/query {
default_type text/plain;
proxy_pass http://backend;
}
# 进结算页页面(H5)
location /settlement/page {
default_type text/plain;
proxy_pass http://backend;
}
# 结算页页面初始化渲染所需数据
location /settlement/initData {
default_type text/plain;
proxy_pass http://backend;
}
# 结算页提交订单
location /settlement/submitData {
default_type text/plain;
proxy_pass http://backend;
}
# 结算页用户行为操作,模糊匹配
location ~*/useAction/ {
default_type text/plain;
proxy_pass http://backend;
}
}
隔离策略
- 业务隔离:由于秒杀商品的稀缺性,决定了业务不会像普通商品那样进行投放售卖,一般是有计划的进行营销策划,所以会有个申报的过程,有了申报的基本信息来预估活动当天的流量,并发数,以及活动的时长,从而来决定是否需要对业务进行隔离,比如是否需要单独部署,是否需要单独的数据库,是否需要单独的缓存等。
- 系统隔离:我们知道,用户的秒杀习惯,一般是打开商品详情页进行倒计时等待,时间到了点击秒杀按钮进行抢购。因此第一个需要关注的系统就是商品详情页,我们需要申请独立的秒杀详情页域名,独立的 Nginx 负载均衡器,以及独立的详情页后端服务,并采用 Dubbo 独立分组的方式单独提供秒杀服务
- 数据隔离:在数据层面,我们也应该进行相应的隔离,否则如果共用缓存或者共用数据库,一旦瞬时流量把它们冲垮,照样会影响无辜商品的交易。数据层的专有部署,需要结合秒杀的场景来设计部署拓扑结构,比如 Redis 缓存,一般的场景一主一从就够了,但是在秒杀场景,需要一主多从来扛读热点数据。
如何让秒杀流量正确地路由到秒杀系统专有环境中
通过对商品进行打标,在商品的主数据上增加一个秒杀标识,比如秒杀商品的商品ID前面加上秒杀标识,这样就可以通过商品ID来判断是否是秒杀商品,从而将秒杀商品的请求路由到秒杀系统专有环境中。打标的基本思路:我们可以使用一个 long 型字段 skuTags 来保存,long 是 64 位,每一位代表一种类型的活动,0 代表否,1 代表是,通过对 skuTags 进行二进制操作即可完成商品的打标和去标。假设秒杀的标识我们定义在 skuTags 的第 11 位,那么要给一个sku 打上秒杀标,我们就可以对这个标实际进行“或”操作:skuTags=skuTags|1024,这样 skuTags 字段的第 11 位就变成了 1,对其它 bit 位没影响。去标过程相反,同样进行位操作,skuTags=skuTags&~1024,把第 11 位置为 0。
流量管控
- 活动前期采用预约制:因此我们需要一个预约管理后台,进行活动的设置和关闭;需要一个预约 worker 系统,根据时间调用商品系统进行预约打标和去标,向预约过的用户发短信或消息提醒;还需要一个面向 C 端的预约核心微服务,提供给用户预约和取消预约能力,商详在展示时获取预约信息的能力,秒杀下单时检查预约资格的能力,以及获取用户的预约列表能力为此设计数据库表:
CREATE TABLE `t_reserve_info` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '预约活动id',
`sku_id` bigint(20) unsigned DEFAULT NULL COMMENT '商品编号',
`reserve_start_time` datetime DEFAULT NULL COMMENT '预约开始时间',
`reserve_end_time` datetime DEFAULT NULL COMMENT '预约结束时间',
`seckill_start_time` datetime DEFAULT NULL COMMENT '秒杀开始时间',
`seckill_end_time` datetime DEFAULT NULL COMMENT '秒杀结束时间',
`creator` varchar(255) DEFAULT NULL COMMENT '活动创建人',
`update_time` datetime DEFAULT NULL COMMENT '更新时间',
`yn` tinyint(255) unsigned DEFAULT NULL COMMENT '是否删除',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `t_reserve_user` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '关系id',
`reserve_info_id` bigint(20) unsigned DEFAULT NULL COMMENT '预约活动id',
`sku_id` bigint(20) unsigned DEFAULT NULL COMMENT '商品编号',
`user_name` varchar(255) DEFAULT NULL COMMENT '用户名称',
`reserve_time` datetime DEFAULT NULL COMMENT '预约时间',
`yn` tinyint(255) unsigned DEFAULT NULL COMMENT '是否删除',
PRIMARY KEY (`id`),
KEY `reserve_id_ref` (`reserve_info_id`),
CONSTRAINT `reserve_id_ref` FOREIGN KEY (`reserve_info_id`) REFERENCES `t_re
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
缓存设计:Redis存储内容:Redis key:t_reserve_info:skuId:userId,Redis value使用JSON string存储
t_reserve_user可以设置为hash结构,key为skuId,value为userId的集合
预约期间为更好的限制活动人数:限制预约人数,当人数达到上限后进行预约熔断机制,将活动状态改为等待秒杀
秒杀的削峰
秒杀活动开始后的流程
- 验证码+问答题:快速拦截掉部分刷子流量,防止机器人刷单,另一方面就是平滑秒杀的毛刺请求,延缓并发,对流量进行削峰设计验证码流程,一般是在用户进入详情页时,先判别秒杀活动是否已经开始,如果已经开始,同时秒杀活动也配置了需要校验验证码标识,那么就需要从秒杀系统获取图片验证码,并进行渲染;用户手工输入验证码后,提交给秒杀系统进行验证码校验,如果通过就跳转至秒杀结算页。验证码的实现调用google提供的开源工具kaptcha,kaptcha是一个生成验证码的工具,可以生成图片验证码,也可以生成语音验证码,同时也可以自定义验证码的样式,比如字体,字体颜色,字体大小,背景颜色,干扰线颜色等。验证码的校验,可以通过redis来实现,将验证码存储到redis中,key为用户ID,value为验证码,设置过期时间为5分钟,当用户提交验证码后,从redis中获取验证码,进行比对,如果一致,就返回true,否则返回false。
- 异步消息队列:秒杀活动开始后,用户进入详情页,点击秒杀按钮,会发送请求到秒杀系统,秒杀系统会根据用户ID和商品ID来判断用户是否有资格参与秒杀,如果有资格,就会将用户ID和商品ID发送到消息队列中,然后返回用户秒杀成功的页面,如果没有资格,就会返回秒杀失败的页面。消息队列的消费者会从消息队列中获取消息,然后调用秒杀系统的下单接口,进行下单操作。消息队列的实现,可以使用RocketMQ,RocketMQ是阿里巴巴开源的消息中间件,具有高吞吐量,高可用性,适合大规模分布式系统应用的特点。
- 限流:令牌桶和漏洞算法,线程池限流提供设置最大连接数来实现
服务降级
- 简化系统功能,干掉不必要的流程:比如各种附加信息的展示,比如商品的评价,商品的推荐,商品的咨询等,这些都可以在秒杀活动期间暂时干掉,只保留最核心的功能,比如商品的基本信息,商品的价格,商品的库存等。
- 建立多级缓存:比如在秒杀活动期间,可以将商品的基本信息,商品的价格,商品的库存等信息都缓存到Redis中,这样就可以减少对数据库的访问,从而减少数据库的压力。
- 写服务降级,暂时接受数据不一致性,使用最终一致性数据方案
容灾设计
- 同城双活:在同一个城市部署两套系统,一套为主系统,一套为备系统,主系统和备系统之间通过数据库的主从同步来保证数据的一致性,当主系统出现故障时,可以将流量切换到备系统上,从而保证秒杀系统的高可用性。