【高并发】- 生产级系统搭建 - 4

前言

    关于高并发系统中,当前比较热门的还是属于“秒杀”系统,前面章节在整理了“秒杀”系统的相关设计概念后,本章节,来讲解扣减库存相关的业务逻辑。

1 库存的那些事

    一般电商网站中,购买流程一般都是这样的:商品列表页看重某个商品,然后进入详情页浏览商品详细信息,有购买意向后,单击“支付”按钮(或者将商品加入购物车,从购物车进行结算),网站弹出支付方式让用户进行选择支付方式,并进行支付。

    对于这样的购买流程,用户在下单时,一般不需要关心库存的,只有没有库存了,用户才会感到没有库存了。但是在高并发场景中,这样的购买流程就会出现问题。例如,在“秒杀”活动中,用户会争抢库存,如果没有控制好,则会出现“超卖”的情况。会给公司造成损失。

(对于“秒杀”活动,一般公司是不允许商品“超卖”的,即【下单成功的数量】不能大于【商品库存数量】。一旦出现“超卖”,公司则会出现损失。如果被恶意流量利用,则损失可能是巨大的。)

1.1 扣减库存方式

    库存对于电商平台来说,是一个重要的业务指标,所以在技术上需要合理设计扣减库存,不能出现“超卖”的情况。

一般扣减库存常有以下3种方式:

  • 下单后扣减库存:用户在下单后就扣减库存,这种扣减方式最简单,也最好理解。但是问题是,可能有用户下单后不付款,特别是竞争对手利用“秒杀器”大量抢购商品,但是不支付。如果是这样,那商家就没有达到活动的真正目的,且真正想得到商品的用户也无法得到低价商品。

  • 支付后扣减库存:在用户付完款后再扣减库存,这样可以解决用户“下单但不支付”的情况。但是这种方式也有问题:会发生【超卖】情况。因为,在瞬时洪峰流量下,会有很多用户付款成功,但是只有一小部分用户能真正抢到商品,大部分用户在付完款后系统会报“已售罄”或“活动结束”等。

(对于“支付后扣减库存”这种方式,当出现库存不足时,有些商家是可以后续再补货的)

  • 预扣减库存:在用户下完订单后,系统会为其锁定库存一段时间,例如30分钟;在超过锁定时间后,会自动释放锁定的库存,让其他用户抢购。当用户付款时,系统会校验库存是否在锁定有效期内,如果在有效期内,则可以进行支付;如果锁定有效期已过,则重新锁定库存,若锁定失败则报“库存不足”的提醒。

(在用户下单后,有些平台会有一个支付时间的倒计时。例如12306网站,会有一个30分钟的有效支付时间,这种扣减库存方式相当于“预扣减库存”方式。)

1.2 在千万级流量的“秒杀”中,如何扣减库存?

    上面了解到,有三种扣减库存方式:下单后扣减库存、支付后扣减库存 以及 预扣减库存。对于“秒杀”业务,应当如何选择扣减库存的方式呢?

    由于在“秒杀”场景中,商品一般对用户具有很强的吸引力,所以,在这种场景中使用“下单后扣减库存”方式更为合适。

(在“秒杀”场景中,大部分用户抱着“抢到就是赚到”的想法,一般都会付款,但是如果真的有竞争对手恶意下单不付款,应该怎么办?前面在流量管控中已经说到,可以对请求日志进行实时分析,让风控系统选择出恶意用户,然后将其封停。)

    因此,对于“下单后扣减库存”这种方式,利用数据库的事物特性,可以保证订单和库存扣减数量的一致性。

    下面来分析该如何去做好“下单后扣减库存”,防止商品被“超卖”。

(1)将某个商品的库存数量查询出来:

select num from stock where prod_id = $prod_id

(2)更新库存。用【库存数量】减去【购买的商品数量】,然后将结果值更新到库存数据库中。例如,商品库存数量为10,之后用户购买了2件,则d得到的结果值是:10 - 2 = 8,只需要将 8 更新为最新的库存数量即可。

问题:为什么是更新“结果值”的操作,而不是直接更新“扣减”的操作呢?

回答:因为,“扣减”不是幂等的,如果接口设计的不够完善,没有考虑到幂等性,那么在由于网络原因或者其他原因重试后,会出现重复“扣减”,即会出现“超卖”,甚至库存为负值的情况。

    通过上面两步的处理,基本可以保证下单扣减库存的准确性,但是对于“秒杀”这样的高并发场景来说这样还是有风险的。例如,在大流量、高并发下,有两个用户同时抢购,都拿到了库存数量为10的商品,其中一个用户购买了5件商品,随后更新库存数量为:10 - 5 = 5 件;接着另外一个请求购买了3件商品,随后更新库存数量为:10 - 3 = 7件。

(在高并发场景中,有可能出现并发更新数据不一致的情况,对于上图的两次请求,正常来讲应该卖出8件商品,但是现在却卖出了3件商品,因为update set动作覆盖了之前的数据。)

    在更新库存数量时,需要将【当前库存数量】与【之前的库存数量】进行对比:

update stock set num = $new_num where prod_id = $prod_id and num = $old num

    有了这种对比,在并发更新时,用户A和用户B只有在更新提交前查询到的库存数量为10,才能成功更新库存数量。

但是,在这种并发场景中,如果没有进行对比,则会出现以下问题:

  • 开始库存数量为10,第一个用户更新库存数量是成功的。

  • 在第一个用户更新完库存数量后,库存数量变成了5,所以,这时另一个请求是不能扣减成功的,在代码中会提示更新失败或者提示用户扣减库存失败的提示。

1.3 在千万级流量的“秒杀”中,优化库存数量扣减方案

    在“秒杀”场景中,通过流量分层控制可以分层管控大量的“读”请求。但是,依然会有很大的流量进入真正的下单罗技。对于这么大的的流量,除了前面说的数据库个例外,还需要进一步优化库存数量,否则数据库读/写依然是系统的瓶颈。

(1)利用好缓存。

    在“秒杀”场景中,如果只是一个扣减库存数量这样简单的流程,则可以先将库存数量直接放在缓存中,然后利用分布式缓存(如Redis)去应对这种瞬时流量洪峰下的系统挑战。

ps:使用缓存是存在一定风险的,例如,缓存节点出现异常,那库存数量应该怎么计算?使用缓存不仅要考虑分布式缓存高可用,还要考虑各种限流容错机制,以确保分布式缓存对外提供服务。

(2)异步处理。

    如果是复杂的扣减库存(如涉及商品信息本身或者牵连其他系统),则建议使用数据库进行库存数量的扣减,可以使用异步的方式来应对这种高并发的库存数量更新。

  • 在用户下单时,不like生成订单,而是将所有订单依次放入队列。

  • 下单模块依据自身处理速度,从队列中依次获取订单进行“下单扣减库存”的操作。

  • 在订单生成成功后,用户即可进行支付操作了。

    这种方式是针对“秒杀”场景的,依据“先到先得”的原则来保证公平公正,所有用户都可以抢购,然后等待订单处理,最后生成订单(如果库存不足,则生成订单失败)。这样的逻辑,对于用户来说体验感不是很差。具体排队逻辑如图:

(对于用户来说,只需要在商品活动详情页中提交一次抢购请求,之后就是等待系统处理进度。当然,这个等待时间是要设计的,不要让用户等待太久的时间,不管成功或者失败。)

    上面介绍了千万级流量“秒杀”系统的基本架构、“秒杀”系统的设计原则、如何做动静分离方案和流量控制,以及扣减库存方案的内容。这些都是设计高并发“秒杀”系统必须要考虑的。

    “秒杀”系统的流程并不复杂,只是一个“下单扣减库存”的动作,但是由于其具有独特的业务特点,所以在进行系统设计时千万不能大意。对于瞬时流量洪峰的高并发“秒杀”系统,我们可以总结一下:

(1)数据的静态化技术,用来应对高并发读的请求。

  • 各层级缓存的处理(即多级缓存的技术)。

  • 分布式缓存技术。

(2)负载均衡反向代理技术。

  • LVS。

  • Nginx。

(3)异步处理技术。

  • 消息队列技术。

  • 排队系统技术。

(4)系统架构设计技术。

  • 系统模块化划分。

  • 微服务架构思想。

(5)系统监控技术。

  • 日志监控。

  • 服务监控。

    本章节主要讲解了库存扣减相关设计经验,在面对库存扣减这一业务,不能大意,需要认真进行系统设计、业务设计,选择合理的方案来解决库存扣减的场景。以及在最后进行了一个简单的前面章节的统一汇总,希望小伙伴们能够及时回顾前面章节内容。

    下一章节会针对系统交互过程中的服务通信设计进行讲解。希望大家能够分享公众号给身边的小伙伴,大家一起来学习

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值