Java生鲜电商平台-促销架构以及秒杀解决方案实战

Java生鲜电商平台-促销架构以及秒杀解决方案实战

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

1. 构建秒杀活动架构

1.1 说明

  系统架构的设计,必定程度上取决于流量的多少、流量的洪峰值和波谷值,有效的预估好流量是相当重要的一步,流量的大小不同,咱们的架构设计相应的也会不同.这会影响到后续的系统架构设计.反而系统的搭建并非最难的部分,由于如今不少大公司,都有一套本身的成熟架构体系

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)分段锁