秒杀系统设计初稿

用户头像
jason
关注
发布于: 2020 年 08 月 04 日

一、运营端关键点设计

1、活动营销平台 :配置秒杀活动;

2、运营层面:提升日活和UV,运营人员搜刮一些有限数量的热门商品放到秒杀平台,提高商品和品牌的曝光率;

3、技术层面:秒杀活动的数据采用双写机制,提升APP展示秒杀活动时读的性能:数据库 + 缓存;



二、前端关键点设计

1、秒杀商品详情页面静态化方案:页面很少,适合纯静态化方案,不适合采用高大上的动态渲染伪静态方案(适合商品详情页面太多,经常改动的场景重复渲染的场景);

2、秒杀活动页面静态化方案:页面很少,适合纯静态化方案;

3、静态资源(js,css,图片)和页面的CDN化:需要注意怎么删除CDN缓存,一般厂商都有API接口可以删除CDN缓存,先发布新页面再删除CDN缓存,否则有ABA的问题;

4、活动页面动态展示数据和参与秒杀直接调用API接口;

5、api接口的域名必须和页面和静态资源的域名区分开,否则没有办法做CDN缓存;

6、尽量禁用html的浏览器缓存,避免读取不到最新的页面;

7、小细节设计:秒杀活动前按钮时灰色的,点击秒杀购买按钮后按钮变灰;



三、后端关键点设计

1、安全性设计:

(1)如何防刷单器:秒杀抢购的URL地址通过”动态随机数“动态隐藏url、动态验证码、waf基于session的限流;

(2)倒计时时间同步:根据服务端的秒杀活动的时间同步服务返回的时间为准,不能以本地时间为准,10s同步一次即可;

2、高性能设计:

(1)接入层:负载均衡架构设计通常采用LVS(四层) + NGINX(七层);

(2)服务层:异步下单设计,先写订单数据到缓存集群codis,然后通过异步拉单线程同步到DB,非核心逻辑通过MQ异步处理;

(3)参数优化:操作系统,中间件,jvm参数优化;

3、可用性设计:

(1)流量层面:使用流量治理中间件,建议使用阿里的哨兵;

(2)资源层面:服务层基于注册中心自动上下线故障节点,分布式中间件都使用基于命名服务nameServer/zk的高可用架构部署,mysql数据库采用双主架构;rabbit mq的镜像队列集群模式 --内容比较多,后续再补充;

4、可靠性设计:

(1)缓存redis开启always持久化,尽可能的减少异常时丢单的发生,但是边界场景无法彻底避免丢单场景,比如redis master挂了,redis slave自动升级为master的场景;

(2)MQ:多副本存储机制,手动提交offset, ack机制;

5、稳定性设计:

(1)稳定性梳理:容量评估梳理,风险识别梳理,预防监控梳理,压测测试和故障演练梳理

(2)稳定性验证:故障演练 + 预案演练

(2)稳定性专项治理:依赖中间件保障专项,依赖下游服务保障专项,代码层面改造,日志和监控指标专项,开关和紧急预案专项

6、异步下单服务核心逻辑设计

(1)查询用户地址等信息

(2)预扣库存:防止超卖设计(redis原子性自减), 分段锁提升性能

(3)算价

(4)风控

(5)写入订单到codis,同时自动开启异步线程拉取redis订单到mysql数据库;

(6)用户支付

(7)支付成功实扣库存



Jason shen --20200804



发布于: 2020 年 08 月 04 日 阅读数: 63
用户头像

jason

关注

还未添加个人签名 2017.10.22 加入

还未添加个人简介

评论

发布
暂无评论
秒杀系统设计初稿