秒杀系统设计初稿

一、运营端关键点设计

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