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

前言

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

1 库存的那些事

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

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

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

1.1 扣减库存方式

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

一般扣减库存常有以下3种方式&＃xff1a;

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

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

&＃xff08;对于“支付后扣减库存”这种方式&＃xff0c;当出现库存不足时&＃xff0c;有些商家是可以后续再补货的&＃xff09;

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

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

1.2 在千万级流量的“秒杀”中&＃xff0c;如何扣减库存&＃xff1f;

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

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

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

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

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

&＃xff08;1&＃xff09;将某个商品的库存数量查询出来&＃xff1a;

select num from stock where prod_id &＃61; $prod_id

&＃xff08;2&＃xff09;更新库存。用【库存数量】减去【购买的商品数量】&＃xff0c;然后将结果值更新到库存数据库中。例如&＃xff0c;商品库存数量为10&＃xff0c;之后用户购买了2件&＃xff0c;则d得到的结果值是&＃xff1a;10 - 2 &＃61; 8&＃xff0c;只需要将 8 更新为最新的库存数量即可。

问题&＃xff1a;为什么是更新“结果值”的操作&＃xff0c;而不是直接更新“扣减”的操作呢&＃xff1f;

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

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

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

    在更新库存数量时&＃xff0c;需要将【当前库存数量】与【之前的库存数量】进行对比&＃xff1a;

update stock set num &＃61; $new_num where prod_id &＃61; $prod_id and num &＃61; $old num

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

但是&＃xff0c;在这种并发场景中&＃xff0c;如果没有进行对比&＃xff0c;则会出现以下问题&＃xff1a;

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

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

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

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

&＃xff08;1&＃xff09;利用好缓存。

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

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

&＃xff08;2&＃xff09;异步处理。

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

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

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

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

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

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

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

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

&＃xff08;1&＃xff09;数据的静态化技术&＃xff0c;用来应对高并发读的请求。

• 各层级缓存的处理&＃xff08;即多级缓存的技术&＃xff09;。

• 分布式缓存技术。

&＃xff08;2&＃xff09;负载均衡反向代理技术。

• LVS。

• Nginx。

&＃xff08;3&＃xff09;异步处理技术。

• 消息队列技术。

• 排队系统技术。

&＃xff08;4&＃xff09;系统架构设计技术。

• 系统模块化划分。

• 微服务架构思想。

&＃xff08;5&＃xff09;系统监控技术。

• 日志监控。

• 服务监控。

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

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