前端优化

  秒杀列表页,详情页,在秒杀开始前,会有大量的刷新操作,所以在设计列表页和详情页的时候,就尽量保证简洁,无关的数据展示尽量不要放。

  1、CDN资源(image,js,css)能小则小,串行加载js css。

  2、页面端 承担一部分 缓存功能,减少不必要的资源请求,

  主要业务接口:由服务器端 控制和缓存每次刷新页面都会请求接口 保证接口的数据少且响应快,

  次要业务接口:存放商品图片标题详情等一些 没时效性的数据,请求一次缓存到前端。

  3、如果可以,多服务器 负载均衡 是上策!

  4、流量削峰

  让用户点击抢购后,输入点什么才能走下一步下单!增加购买的复杂度,第一个目的是防止部分买家使用秒杀器在参加秒杀时作弊,第二个目的其实就是延缓请求。

  后端优化

  1、减少编码,减少计算

  2、能缓存的都缓存起来

  3、扣减库存(如何保证不会卖超)

  秒杀开始前,根据秒杀活动的库存数量,初始化生成相应个数的具有唯一标示值的token,并将所述token保存在Redis缓存队列中。

  抢购时拿到token则走下单流程

  插入成功,则库存扣减成功,订单完成创建。(如果10分钟内未付款,取消订单,将获取的token回退至Redis缓存队列)

  插入失败,则库存扣减失败,将获取的token回退至Redis缓存队列。

  队列的任务就是 找到手速快的N个人,N=秒杀库存数,保证不会卖超。

  4、下单逻辑简单化

  秒杀开始前,根据秒杀活动的库存数量,Redis 创建一个计数器,用于给前端展示 未付款人数,如果未付款的人10分钟内未付款,其他人还有机会抢到!

  如果是超级优惠:创建订单扣库存,不考虑下单不付款的情况。

  如果是一般优惠:创建订单预扣库存,库存为其保留一定的时间(如 10 分钟),超过这个时间,库存将会自动释放。

  MySQL 并发锁问题:MySQL COMMIT_ON_SUCCESS 和 ROLLBACK_ON_FAIL 的补丁程序

  使用Redis 采用乐观锁,同一时间只处理一个token订单!

  兜底方案

  抢购活动 时间段,集中并发请求,可在活动时间为活动让步,减少系统其它功能开销,暂停部分功能运行,给活动腾出更多资源!