阅读 1209

秒杀系统有那么复杂吗?

限制流量

静态资源
  • 静态资源怎么得要上个CDN吧,要不买服务器也得花钱,还要配置,多麻烦
  • 有了CDN,秒杀页面的URL绑定个域名即可,其他啥也不用配置
接口
  • 网关总有限流功能吧,按需把80%流量直接返回抢购失败消息,20%流量正常进入秒杀策略
至此,大部流量被稀释了,以下进入正常的秒杀策略。

秒杀策略

本文采用了并发锁,并发锁更好的支持业务

并发锁
  • redis setnx
  • 分布式并发锁
变量
  • limit - 秒杀数量
  • product - 商品唯一标签
  • project - 秒杀项目唯一标签
  • book - 实时产生的订单表(uuid,status)
  • inervalBook - 监控book定时器,实时更新book,可以通过book查看当前订单数量,和用户是否已存在
  • inervalOver - 监控book定时器,实时查看book中所有订单是否所有都支付完成,此时达到limit则设置结束标签,活动结束
  • 如果需要实时更新库存,可以在设置一个定时器
接口
  • checkOrder - 下单接口
  • getOrderStatuss - 查询订单接口,该接口需要根据uuids列表返回对应的订单status列表,以便实时更新book
流程

redis并发锁不足

总结

一般为支付订单有效期为15分钟,如果某个用户在15分钟才支付或者一直未支付直到失效,就会浪费一个库存;如果库存满了,但真实购买量并没有满,假设我们规定此时新用户去抢,返回“抢光了”的消息,那么用户就不会去抢了,于是浪费一个名额;假设我们规定返回“请继续抢”,那么用户持续抢15分钟,体验很差。
针对以上问题,我们可以根据经验适当扩大库存量,比如预计秒杀100台,那么库存可以增加到105,这样,当产生105个订单时,可直接返回“抢光了”,保证有一部分客户订单失效时,仍然达到预期销售量。

关注下面的标签,发现更多相似文章
评论