秒杀系统有那么复杂吗？

限制流量

静态资源

• 静态资源怎么得要上个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个订单时，可直接返回“抢光了”，保证有一部分客户订单失效时，仍然达到预期销售量。