如何设计一个小而美的秒杀系统

背景:
随着这几年的电商的大热,我们经常看到一些商家为了促销和快速收益,纷纷推出了秒杀活动.不管是日常的超市里面的促销,明星演唱会门票售卖,还是春节订阅火车票,等等我们都能看到秒杀活动的影子.

image.png

1. 构建秒杀活动架构

1.1 说明

  系统架构的设计,一定程度上取决于流量的多少、流量的洪峰值和波谷值,有效的预估好流量是至关重要的一步,流量的大小不一样,我们的架构设计相应的也会不一样.这会影响到后续的系统架构设计.反而系统的搭建并不是最难的部分,因为现在很多大公司,都有一套自己的成熟架构体系.

系统架构图.png

1.2 关键设计

1.2.1 围绕着产品设计,驱动技术.

  1).一般秒杀活动都是T+N的,这样设计的好处,就是提前帮我们预估好用户流量,这一步也会影响到我们是否扩容,至于坊间传说的临时扩容,本人一直持保守态度,显然对于大流量洪峰来临,这种临时扩容的方案还不够成熟,因为微博一直在砰砰打脸.
  2).秒杀活动前,来一波小游戏,有些人问是不是产品脑子冒泡?我是来秒杀商品的.....
  3).秒杀活动前,需输入12306式的验证码,产品是不是又该挨打?
  4).秒杀活动前,倒计时弹幕提醒,产品已gg

其实这些小伎俩的设计,一方面为了防止活动未开始前大流量涌入,一方面是为了防止恶意用户攻击,另一方面是为活动造势

1.2.2 缓存和预热

  1).页面静态话,静态页面部署在CDN服务器上,服务器多机房部署,异地多活,使得用户能就近访问到相应的节点服务器.
  2).redis双泳道
  3).热点数据提前落地

1.2.3 消息中间件MQ

  延迟队列、阻塞队列

1.2.4 限流、降级

  推荐sentinel开源中间件,sentinel是以流量为切入点,从流量控制、熔断降级、系统负载保护等多个纬度保护服务稳定性.sentinel和谷歌guaval不同的地方在于它可以做到全局性的限流.对于快到水位线时候,可以随机拒绝一些请求,做好保护.

1.2.5 网关拦截

  过滤和限制恶意请求和爬虫之类的,限制参与秒杀的用户需要登陆的token

1.2.6 是否查询数据库

  大型秒杀活动是可以不查数据库的,数据异步落库就行

2. 技术难点

其实在第一章节,我并没有过细的赘述,因为现在业界这些框架已经非常成熟了,拿来即用,甚至有些活动并没有那么的流量,可能都无需限流.

2.1 库存是否锁定

  是否锁定库存需要看场景,像卖林俊杰演唱会门票这种,是无需锁库存的,why?
  对于用户购买意愿非常强烈的活动中,是无需锁定库存的,一方面可以做到公平购买,另一方面防止一些用户其实就是看看的心态,下单了不付钱,导致那些真正想买的人买不到票.而一般的活动是需要锁定库存的,即用户预下单后就锁定库存,但是一般我们秒杀的订单都具有时效性,一般在5-30分钟不等.

2.2 如何释放库存

  1)首先查询库存,检查库存状况,库存不足直接返回前端.
  2)库存够,用户可以购买商品,用户预下单
  3)服务端构建用户订单消息,锁定库存,推送订单消息给延迟消费队列和更新订单缓存,调用预下单接口,然后调用第三方预支付接口
  4)前端唤起sdk去付款
  5)支付成功,第三方支付会回调通知商户,然后通知业务线去更新支付状态
  6)规定时间里面成功支付的订单,删掉缓存
  7)延迟消费队列监听,先查询缓存,看缓存数据是否存在,存在的为,超时订单,需要释放库存加1,缓存里面不存在的订单为成功支付的有效订单,落库

支付.jpg

2.3 如何解决超卖的问题

redis本质上是没有办法保证是否超卖的问题,在高并发下这种现象很常见.以下提供一些解决方案,性能上可以根据实际情况做调整.

  1)悲观锁
  2)乐观锁
  3)分布式锁
  4)队列串行化
  5)异步队列分散
  6)分段锁