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

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

使用Lua脚本
库存扣减操作不能交给后端数据库处理
使用Redis保存库存量
数据库订单异常处理
库存信息过期时间处理
请求拦截和流控
前端静态页面的设计
基于分布式锁支撑秒杀场景
基于原子操作支撑秒杀场景
使用切片集群
Redis本身高速处理请求的特性
库存查验、库存扣减和订单处理
大量用户点击商品详情页上的秒杀按钮
使用CDN或浏览器缓存服务
静态化商品详情页
Redis对键值对查询的高效支持
Redis并发处理能力
秒杀系统是一个系统性工程
保证库存查验和库存扣减原子性执行
支持高并发
秒杀活动结束后
秒杀活动开始
秒杀活动前
读多写少,读操作是简单的查询操作
瞬时并发访问量非常高
小结
Redis的哪些方法可以支撑秒杀场景
Redis可以在秒杀场景的哪些环节发挥作用
秒杀场景的负载特征对支撑系统的要求
Redis支撑秒杀场景的关键技术和实践

该思维导图由 AI 生成,仅供参考

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

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

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

Redis在秒杀场景中发挥关键作用,满足了高并发和原子性执行的需求。秒杀活动分为秒杀前、秒杀中和秒杀后三个阶段,其中秒杀中阶段对Redis的需求最大。在这个阶段,Redis支持高并发的库存查验和扣减操作,避免了数据库压力过大和超售问题。文章还介绍了Redis切片集群和原子操作、分布式锁等功能特性,以及如何在不同阶段使用Redis来支撑秒杀场景。 在秒杀场景中,Redis的高并发处理能力和高效的键值对读写特性能够满足瞬时高并发请求和读多写少的特点。通过前端CDN和浏览器缓存,可以拦截大量秒杀前的请求。在实际秒杀活动进行时,库存查验和库存扣减是承受巨大并发请求压力的两个操作,同时,这两个操作的执行需要保证原子性。Redis的原子操作、分布式锁这两个功能特性可以有效地来支撑秒杀场景的需求。 除了Redis的支持,秒杀系统还需要处理前端静态页面设计、请求拦截和流控、库存信息过期时间处理以及数据库订单异常处理等环节。对于秒杀场景来说,建议将秒杀商品的库存信息用单独的实例保存,避免干扰业务系统的正常运行。 在使用切片集群时,让每个实例各自维护库存量并分发秒杀请求到不同实例进行处理是一个好方法,可以有效减轻实例的压力。 总的来说,Redis在秒杀场景中发挥着重要作用,通过其高并发处理能力和特性功能,能够有效支撑秒杀活动的需求。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(45)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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