Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
79224 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 53 讲
开篇词 (1讲)
实践篇 (28讲)
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

36 | Redis支撑秒杀场景的关键技术和实践都有哪些?

你好,我是蒋德钧。
秒杀是一个非常典型的活动场景,比如,在双 11、618 等电商促销活动中,都会有秒杀场景。秒杀场景的业务特点是限时限量,业务系统要处理瞬时的大量高并发请求,而 Redis 就经常被用来支撑秒杀活动。
不过,秒杀场景包含了多个环节,可以分成秒杀前、秒杀中和秒杀后三个阶段,每个阶段的请求处理需求并不相同,Redis 并不能支撑秒杀场景的每一个环节。
那么,Redis 具体是在秒杀场景的哪个环节起到支撑作用的呢?又是如何支持的呢?清楚了这个问题,我们才能知道在秒杀场景中,如何使用 Redis 来支撑高并发压力,并且做好秒杀场景的应对方案。
接下来,我们先来了解下秒杀场景的负载特征。

秒杀场景的负载特征对支撑系统的要求

秒杀活动售卖的商品通常价格非常优惠,会吸引大量用户进行抢购。但是,商品库存量却远远小于购买该商品的用户数,而且会限定用户只能在一定的时间段内购买。这就给秒杀系统带来两个明显的负载特征,相应的,也对支撑系统提出了要求,我们来分析下。
第一个特征是瞬时并发访问量非常高
一般数据库每秒只能支撑千级别的并发请求,而 Redis 的并发处理能力(每秒处理请求数)能达到万级别,甚至更高。所以,当有大量并发请求涌入秒杀系统时,我们就需要使用 Redis 先拦截大部分请求,避免大量请求直接发送给数据库,把数据库压垮
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(45)

  • 最新
  • 精选
  • 新世界
    一般秒杀场景 用redis 扣减库存,不去保证原子性,扣减后有可能超卖,再用数据库去保证最终不超卖,因为超卖的不会多,能够打到mysql的操作就是超卖+实际库存,所以mysql压力也会比较少 课后习题: redis的 800个库存,分布到4个server上,打到哪个server上,取决于key,如果key分布不均匀,会导致 一定的不公平,就像高考一样,有的地方考生多,有的地方考生少,虽然在每个省中录取名额一样,但是也不公平

    作者回复: 高考的比喻很形象!

    4
    22
  • Geek_f6a7c7
    不是一个好方案,一个商品库存数切片不同实例存储的确可以减少单个实例的压力,但是在业务上可行性有待商榷,如果当前切片实例没有库存,是不是要再请求别的切片实例?特别是库存数都被抢购完成后,后面的请求是不是都要请求4个切片节点做库存数的聚合才知道又没人退货,做库存数的聚合?

    作者回复: 分析的不错。使用切片后,处理逻辑要考虑分布式的数据情况了,变得复杂了。

    2
    14
  • 花轮君
    设计上是可行的,将秒杀请求也进行分片,库存的校验可以按照分库顺序扣。

    作者回复: 请求分片的均衡度会比较难控制,另外,如果按照分库顺序扣的话,那么设计四个分片期望达到的支持并发扣减库存的目标就达不到了。

    2
    8
  • 曾轼麟
    我个人认为这个方式不是很好,因为单个sku分开后,需要对用户的请求做路由判断,假如一个用户请求本身就发出了两条,按照随机路由的方式,他有可能在两个切片中抢到商品。假如路由规则是固定的,那么会出现sku还有库存,但是用户就是抢不到的情况

    作者回复: 这里的关键技术挑战就是:请求分发规则和库存分布式查询。

    4
  • 范闲
    如果秒杀请求能够比较均匀的分别打到4个实例上是没有问题的。 这个时候不返回剩余库存,不做聚合,能大幅度提高速度。

    作者回复: 关键是这个假设不一定能实际做到。。。

    2
    3
  • yyl
    将800个商品均分至4个实例,并不能保证客户端请求被均分至不同的实例;毕竟用户的行为是无法预测的,有可能出现某个实例的请求量比较大

    作者回复: 这是个关键因素。 而且如果某个实例上的库存扣除完了,并不代表所有库存都扣完了,这时要想判断是否还有库存,就要去其他实例查询,逻辑就复杂了。

  • @%初%@
    我觉得,是可行的,主要要考虑最后的余量怎么处理,0~2个分片上有余量,而3号分片上有余量,这样怎么处理,还有,就是最后的用余量足够,而每个分片的余量不够,这个又怎么去处理,我觉得这些处理好了,分片存储可以考虑使用。

    作者回复: 这种情况下余量查询的逻辑就比较复杂了,会增加查询请求的分发复杂度,反而可能会得不偿失。

  • tt
    每个实例200个库存,当某个请求在某个实例上查询不到库存时,并不是库存真的为0了,还需要去其它实例查询,这个是一个缺点。 好处时可以承受更大的流量。

    作者回复: 查询逻辑会变得比较复杂了。

  • Kaito
    使用多个实例的切片集群来分担秒杀请求,是否是一个好方法? 使用切片集群分担秒杀请求,可以降低每个实例的请求压力,前提是秒杀请求可以平均打到每个实例上,否则会出现秒杀请求倾斜的情况,反而会增加某个实例的压力,而且会导致商品没有全部卖出的情况。 但用切片集群分别存储库存信息,缺点是如果需要向用户展示剩余库存,要分别查询多个切片,最后聚合结果后返回给客户端。这种情况下,建议不展示剩余库存信息,直接针对秒杀请求返回是否秒杀成功即可。 秒杀系统最重要的是,把大部分请求拦截在最前面,只让很少请求能够真正进入到后端系统,降低后端服务的压力,常见的方案包括:页面静态化(推送到CDN)、网关恶意请求拦截、请求分段放行、缓存校验和扣减库存、消息队列处理订单。 另外,为了不影响其他业务系统,秒杀系统最好和业务系统隔离,主要包括应用隔离、部署隔离、数据存储隔离。
    22
    209
  • Dovelol
    老师好,想问下,用redis扣库存直接用HINCRBY已秒杀库存量,判断返回值>=总库存就是没库存,小于总库存就是扣减库存成功可以购买,这样判断有什么问题么?为什么要引入lua脚本来增加复杂度呢?
    37
    22
收起评论
显示
设置
留言
45
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部