江苏龙网

  1. 首页 > 资讯 > 资讯 > >

程序|关于电商秒杀系统中防超卖、以及高性能下单的处理方案简述( 二 )


问题又出来了，如果商品数量很少，几百几千个，通过分布式锁也能很快的处理完。实测，redis加锁、释放锁耗时约1ms，再加上客户端逻辑处理时间，按下一单要5-10ms（非常急速了），那么一秒在对同一个分布式锁的操作上，也就百单而已。
可以发现，通过对同一个商品id加分布式锁，商品数量巨多时就麻烦了，因为是对商品id加锁，那么上锁解锁这个动作被执行几十万次，时间耗费巨大。
那么这个分布式锁就会有严重的性能问题，就要再次对商品数量进行分片，譬如一个用来分布式锁的redis key，只放500个商品数量，耗完结束，对应这个key的请求就算全部卖光。譬如商品id是10，那么我们就用goodsId-10-1，goodsId-10-2，goodsId-10-3这样，建立count/500个key，当请求来时，按照hash将分布式锁加到不同的key上。这样也能大幅提高分布式锁的性能。
当然这样会造成redis压力巨大，再将redis做个集群也行。总的来说这个方案貌似很复杂，而且很难控制，譬如比较难以控制不同key的余量消耗。
那么太复杂的方案就还是抛弃。我们直接在服务实例里写商品数量，这样直接在内存里判断商品剩余量，谁也不通信了，性能达到极致。
譬如我们部署了20个订单实例，20万个商品，我们将服务接入配置中心（Apollo，disconf，nacos之类的），通过配置中心来下发每个实例的商品数量，而且可以动态控制。可以在抢购开始前，通过配置中心下发到每个服务1万个商品数量，当这个实例将内存里的商品数量消耗完毕，就算售罄。当然，由于服务的处理速度，和请求的不均匀，可能导致某个实例早早售罄，别的实例还有大量剩余。也就是在页面上比你晚的人，来了还能买到，而你早早售罄了。那就不要怪程序员了。
要是中途个别实例挂掉了怎么办？挂掉了我们就不管它了。不要为它再设置什么复杂逻辑了。大不了少卖一些而已。既然是售罄，卖20万个，和卖了19万3千个，也没什么区别。可以等其他实例全卖光后，统计一下redis的订单数量，譬如卖了19万个3千，再把它启动起来，设置个7000的剩余量，这样也行。但这不重要了。可以将这部分放到30分钟后，没付款的被丢回库存池里再卖也一样。


推荐阅读


上一篇： 华山论剑|真实的道士老照片: 图1道友110岁, 图6是“华山论剑”现场

下一篇： 判断|检查轮胎也能判断是不是调表车？