手把手带你搭建秒杀系统
佘志东
前京东交易平台(上海)负责人、资深架构师
12374 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 18 讲
前期准备:技术选型与环境准备 (2讲)
准确无误:打造不超卖和公平的秒杀系统 (2讲)
雷令风行:性能调优更上一层楼 (3讲)
手把手带你搭建秒杀系统
15
15
1.0x
00:00/00:00
登录|注册

10|不差毫厘:秒杀的库存与限购

你好,我是志东,欢迎和我一起从零打造秒杀系统。
你应该还记得,在介绍秒杀系统所面临的挑战时,我们就有提到库存超卖的问题,它是秒杀系统面临的几大挑战之一。而库存系统一般是商城平台的公共基础模块,负责所有商品可售卖数量的管理,对于库存系统来说,如果我只卖 100 件商品,那理想状态下,我希望外部系统就放过来 100 个下单请求就好了(以每单购买 1 件来说),因为再多的请求过来,库存不足,也会返回失败。
并且对于像秒杀这种大流量、高并发的业务场景,更不适合直接将全部流量打到库存系统,所以这个时候就需要有个系统能够承接大流量,并且只放和商品库存相匹配的请求量到库存系统,而限购就承担这样的角色。限购之于库存,就像秒杀之于下单,前者都是后者的过滤网和保护伞。
所以在有了限购系统之后,库存扣减的难题其实就转移到限购了。当然从纯技术的角度来说,不管是哪个系统来做库存的限制,高并发下库存扣减都是绕不开的难题。所以在今天这节课里,首先我们会了解限购的能力,然后会详细地讲解如何从技术角度解决库存超卖的问题。这样只要你学会了这类问题的解决方案和思路,不管是否做活动库存与真实库存的区分,都能从容应对。

限购

顾名思义,限购的主要功能就是做商品的限制性购买。因为参加秒杀活动的商品都是爆品、稀缺品,所以为了让更多的用户参与进来,并让有限的投放量惠及到更多的人,所以往往会对商品的售卖做限制,一般限制的维度主要包括两方面。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

秒杀系统面临的挑战之一是库存超卖问题,限购系统在解决这一问题中扮演着重要角色。限购系统通过商品维度和个人维度的限制,确保活动库存能够公平分配给更多用户。文章详细介绍了限购系统的功能和实现方案,重点讨论了利用Redis执行Lua脚本来实现库存扣减的原子性和有序性。通过预加载Lua脚本并使用EVALSHA命令,成功实现了对库存扣减操作的高效处理。作者还通过模拟场景验证了该方案的有效性,最终成功避免了库存超卖的情况。整体而言,本文为读者提供了解决库存超卖问题的技术思路和解决方案,对于开发高性能的秒杀系统具有一定的借鉴意义。 文章还提到了库存系统的业务边界和限购系统在处理高并发流量中的重要性。限购系统可以有效过滤无效流量,确保只有与商品库存相匹配的请求被放行。同时,文章分析了库存超卖发生的原因,并提出了利用Redis的单线程原理和EVALSHA命令来解决库存扣减的原子性和顺序性的方案。经过实测验证,该方案有效解决了库存超卖挑战,为读者提供了可行的解决思路。 总的来说,本文深入探讨了秒杀系统中库存超卖问题的解决方案,突出了限购系统和Redis的关键作用,为开发高性能秒杀系统提供了有益的技术参考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《手把手带你搭建秒杀系统》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(19)

  • 最新
  • 精选
  • 呆萌白的大白。
    有几点疑问,还希望老师可以解答: 文章强调了限购对秒杀的重要性是重中之重,却没把限购中线上环境经常可能发生的情况进行代码说明或者是逻辑说明,希望老师这块重点讲一下。 1、单机redis没有高可用,redis宕机怎么处理?redis仅支持异步复制,宕机必然会丢失数据这怎么处理? 2、服务redis获取锁之后,hang住一直持有锁怎么办? 3、用户1,用户2都是用同一个锁未做区分,会不会用户1获取到锁,超时。用户2获取到锁,用户1活过来把用户2的锁释放掉? 4、锁自动续期的问题也没说啊 5、感觉最终都绕回成了直接用java的 Redisson框架就好照抄官方示例。这样又失去了这一章节的意义。

    作者回复: 这里回复下您的疑问: 1.一般使用redis都是用的集群,我们首要任务是通过削峰、限流等方式确保放过去的流量是安全的,对系统不会造成冲击。如果您还是担心主挂了,导致数据不一致问题,可以通过异常感应措施将redis降级掉,并通过严格限流的方式,将流量放到下游库存系统。 2.文章中并不建议使用分布式锁的方式,不然会出现您上面提到的那些问题,使用lua脚本的方式是不需要加锁的。

    2021-10-21
    8
    15
  • 清风
    老师,秒杀减库存和下单两个操作的顺序是什么呢,是先扣减库存再下单吗?如果下单后没有及时支付,对应的库存该怎么恢复呢

    作者回复: 一般会预生成订单号,然后开始下单前的一系列校验,过限购看是否被限购,过预约看是否有预约资格,过库存进行库存预占,还可能需要过风控看是否风险用户,中间任何一个步骤出错都会进行回滚。大部分平台是采用下单扣库存的方式,所以下单成功库存就预占成功了,如果超期(可配置,一般24小时,大促时调整1小时)用户没有支付,就会有定时任务进行自动取消,释放库存。

    2021-10-26
    3
    6
  • ꧅꧅꧅꧅꧅꧅꧅꧅꧅꧅꧅꧅꧅꧅꧅
    有没有考虑过一个问题。如果中途活动进行时,库存被修改过。原先是30件。现在改成10件。如果缓存没有及时同步过去,数据库10件,缓存30件。这时候。请求还是要过到库存上。该加的行锁还是要加。

    作者回复: 您说的这种情况,只要放到库存的流量是安全的,对数据库来说是没有问题的。

    2021-10-21
    3
    2
  • 清风
    前置检验应该不太好。如果前置检验,后面的过程中有可能库存就发生变化了,最后可能造成下单失败

    作者回复: 您说的情况是可能存在的,大部分前置的本地库存都会比数据库或redis要延时,所以要视自身业务和系统资源情况做取舍。

    2021-10-26
  • 小五
    1 秒杀流量经过之前的削峰和限流后,到达限购系统的流量是不是不会很多?如果很多的话,如使用 Redis 做库存限购的话有上限问题吧,不过采用分片好像可以解决。 2 限购后,把适应库存的流量打到库存系统,使用行锁做兜底,就不会超卖了吧? 3 老师提到 “通过分布式锁的方式可以实现,但不建议使用。“ 这个操作是在类似削峰、限购后的逻辑吧?

    作者回复: 这里解答一下您的疑问: 1.削峰和限流的目的其实就是在了解系统能力之后所做的保护措施,所以一般放过去的流量都是系统所能承受的,redis单片操作有上限,对于写操作,如果想硬抗流量只能通过拆key到不同分片的方式,但这种会带来新的问题 2.是的 3.是的,整个秒杀系统,流量较高的链路,都不建议使用锁,会带来新问题

    2021-10-18
    3
  • Geek2014
    老实说这一章讲解库存方案很初级,如果像回答其他人所说的限流之后都是安全流量,那么给定初始库存值、直接调用原子增减函数就可以了。为什么不调研一下同行如何做的呢?比方说阿里巴巴、小米电商的库存如何实现的。
    2022-01-27
    1
    17
  • 寒溪
    这个方案有点儿自我YY,最好提供方案对比,比如竞对是怎么做的
    2023-04-27归属地:上海
    5
  • xben
    活动库存在redis中扣减完之后,需要是否同步扣减数据库一致性如何保证呢?亦或者 不同步扣减数据库,在redis扣减完成之后,web-server宕机-此次扣减库存的操作也无法回溯呢?这个问题怎么解
    2021-11-27
    3
    5
  • 疯子
    老师 redis和mysql数据怎么同步怎么没说呢, redis 不支持事物, mysql数据回滚 redis数据怎么处理?而且redis扣减扣减成功之后 不一定都会到mysql里面去吧
    2021-12-15
    2
    4
  • 陈浪
    如果redis一个主节点挂了,从节点升主,是不是也会超卖?
    2022-08-17归属地:四川
    1
    2
收起评论
显示
设置
留言
19
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部