男朋友说是做竞彩网站维护的软文营销

场景

特价商品如茅台，在8月1日22点10分0秒开始秒杀

平台用户量：几千万，预计几十万用户感兴趣

需求

临时性的活动，不要太大技术改动

原则

• 商品不能超卖
• 下单成功的订单不能丢失
• 服务器和数据库不能崩溃
• 尽量不让机器人抢走商品

整体思路

其实设计方案就是不断过滤请求的过程。

浏览器-负载均衡-网关-后台服务器-缓存-数据库

• 浏览页面 尽可能将静态资源放入CDN， 防止占用过多出口带宽
• 下单
• 付款
• 成功

动态请求

• 评论、商品详情、购买数量等相关请求，在秒杀场景可以把重要商品的详情页变成静态页面，当然如果实在不行，放入redis也行
• 秒杀前端需要获取秒杀开始的时间，根据时间开启秒杀的标志，将下单设置为可用。这个获取开始时间的请求，可以放到负载均衡层
• 判断秒杀结束，将秒杀结束的标志放入cookie，没有结束标志再请求后台服务，后台服务判断本地内存没有结束标志，再请求缓存，缓存也没有，说明秒杀没结束

下单页面如何拦截

为防爬虫，下单页面做两层防护

• 页面url后台动态获取，秒杀时间一到，就通过另一个请求获取该url
• 用户点击下单按钮后，就设置为diable，防止不断点击

提交订单

这是核心环节

网关层面的过滤

• 限定每个用户的访问频率，比如每5秒下单一次
• 限定每个IP的访问频率，避免机器人下单，错失真实用户
• 一个时间段内的请求拦截掉一定比例，或者只允许特定数量的请求进入后台服务器，如限流的漏桶或令牌桶算法

后台服务：保证特价商品不超卖，保证订单的准确性

• 商品库存放入缓存Redis中，decr操作扣减库存，库存扣减后小于0，说明秒杀失败，将库存用incr操作恢复；如果Redis的库存扣减后不小于0，说明秒杀成功，开始创建订单
• 如果有别的服务修改db的库存？通过业务流程保证，具体操作：在秒杀活动开始前，明确规定一个操作窗口，在这个时间内完成所有上架、库存修改和其他准备工作，在秒杀期间，对相关的业务操作（如上架和库存修改）进行冻结
• 订单写缓存 先写缓存，每隔一段时间(100ms)批量落库。用户下单，进入等待页面，向后台定时轮询查订单，如果落库成功，弹出成功提示并跳转

批量落库失败的处理：
查缓存-落库-删对应缓存数据，落库用事务包裹，失败回滚，其他不用处理，落库需要支持幂等性，根据手机号作为唯一索引

付款页面

订单未及时付款而被取消需要把数据库和redis的库存加回去

MQ

服务间触发通知需要使用