简介围绕 Redis 核心技术点的分享课件适合后端开发、运维人员及对内存数据库感兴趣的学习者快速建立知识框架。PPT 从简介、配置文件、持久化机制到常用命令逐步展开涵盖每秒 11 万次读、8.1 万次写的高性能表现string、hash、set、sorted set、list 等数据结构以及原子性操作与主从复制带来的读写分离优势同时客观指出在线扩容困难、宕机时短暂影响读写等局限。内容系统梳理 redis.conf 中 port、timeout、daemonize、databases 等配置含义对比 RDB 与 AOF 两种持久化策略的优缺点和核心参数并对 EXISTS、DEL、EXPIRE、SET、GET、APPEND、INCR 等常用命令作了分类讲解便于日常查阅与团队内部分享。Redis 常用于缓存、消息代理与数据存储等场景这份课件对理解生产环境中的选型与调优尤其有帮助。资源包共 1 个文件为 1.59MB 的 PPTX 演示文稿已有 161 人学习。通过这份课件读者可快速掌握 Redis 的选型依据、配置调优思路和持久化方案权衡适合作为技术分享或入门复习的配套材料。1. Redis 分享这个主题一份能撑起两小时技术分享的 pptx 主线Redis 分享这个主题几乎是后端技术分享里出现频率最高的。团队里来了新同学要讲 Redis季度技术交流轮到你也要讲 Redis面试复盘时还是绕不开 Redis。这份 pptx 不是把官方文档搬进幻灯片而是把一条主线讲清楚缓存怎么用、数据怎么不丢、挂了怎么恢复、流量大了怎么扩容。下面按一线工程师准备分享的顺序把这份 pptx 拆开来看——每个知识点怎么讲才有人听、演示命令跑哪几条、观众最可能追问的坑在哪。适合要准备内部技术分享的后端开发者也适合想系统过一遍 Redis 核心知识的人照着搭自己的提纲。2. 讲 Redis 先讲数据结构五种类型与 IO 多路复用的分享切入点一份 Redis 分享 pptx 的前半段基本都围绕数据结构展开。这部分讲得好不好直接决定听众愿不愿意继续听下去。常见做法是每个类型配一个业务场景幻灯片上不要铺满命令一页只放一个类型加两三行命令现场用 redis-cli 跑一遍比念文档直观得多。这里要特别注意分享的目的是让听众记住这个结构解决什么问题而不是背命令。2.1 五类基本类型加三个进阶结构怎么讲才不变成念文档下面这组命令可以原样放进课件里分享时逐条执行每执行一条就点出它对应的业务场景。String 配计数和会话Hash 配对象存储List 配轻量队列Set 配去重和黑名单ZSet 配排行榜——五个类型五个锚点听众不容易走神。# 分享现场直接演示比念文档直观 redis-cli # String计数场景INCR 是原子的并发下不会加出重复值 SET login:count 0 INCR login:count # String 带过期时间会话、验证码都靠它600 秒后自动消失 SETEX token:9527 600 session-data # Hash对象存储比拆成多个 String 省内存、好管理 HSET user:1001 name A同学 age 24 HGETALL user:1001 # List轻量消息队列BRPOP 阻塞读常用于任务分发 LPUSH notify:queue task-1 BRPOP notify:queue 0 # Set去重与集合运算黑名单判断是 O(1) SADD blacklist:ip 10.0.0.1 SISMEMBER blacklist:ip 10.0.0.1 # ZSet排行榜核心按分数倒序取前三名 ZADD leaderboard 99 userA 85 userB ZREVRANGE leaderboard 0 2 WITHSCORES逐条说明几个关键参数INCR 的卖点是原子性它的语义就是加一多线程并发下不会丢计数SETEX 的 600 是过期秒数这是 Redis 最常用的一个参数后面讲缓存过期时要反复提到它。BRPOP 的 0 表示永久阻塞等待直到队列里有数据才返回这是用 List 做队列和用数据库轮询的本质区别。SISMEMBER 的时间复杂度是 O(1)所以黑名单、已读状态这类判断特别适合用 Set。ZREVRANGE 的 WITHSCORES 让结果带上分数排行榜页面的原始数据就是这条命令出来的。讲完五种基本类型建议再补三个进阶结构用一张表带过即可不需要展开命令细节目的是让听众知道 Redis 不止五种类型。Bitmap 做签到和在线状态亿级用户也只要几百 MB 内存HyperLogLog 做 UV 去重统计单 key 固定占用约 12KB 内存换来的是极低的内存开销但要注意 PFCOUNT 返回的是近似值误差在 0.81% 左右Geo 底层就是 ZSet存经纬度附近的人、门店距离检索都靠它。2.2 单线程与 IO 多路复用把为什么快讲透每场分享到这里几乎必有人问Redis 为什么快最常见的回答是因为它是内存数据库这个答案只对了一半。内存快是基础但真正让 Redis 在单线程模型下还能扛住高并发的原因是 IO 多路复用加非阻塞 IO——一个线程同时盯着成千上万个连接哪个连接有数据就处理哪个没有数据就继续监听避免了大量线程切换和锁竞争的开销。单线程模型有一个非常容易被忽略的代价任何一条慢命令都会堵住后面所有命令。分享时我会在这里放一个翻车演示但强调必须用本地测试实例别拿生产库开玩笑。正确的讲解方式是先跑反面教材再给替代方案# 反面教材别对生产库跑这条几百万 key 的实例会直接卡顿 redis-cli KEYS * # 正确的巡检姿势SCAN 分批扫COUNT 只是每次遍历的期望条数 redis-cli --scan --pattern user:* --count 1000 # 看慢查询确认有没有命令在拖后腿 redis-cli SLOWLOG GET 5KEYS 是全量遍历所有 key单线程执行期间所有其他命令都在排队这就是线上抖动的常见来源。SCAN 基于游标分批返回不会阻塞但 COUNT 是提示不是保证返回值可能多也可能少代码里不能依赖它做严格分页。SLOWLOG 默认记录执行时间超过 10 毫秒的命令阈值可以通过 slowlog-log-slower-than 调整单位是微秒看到慢查询日志后用 SLOWLOG GET 5 取最近五条基本就能定位是哪段业务代码在拖后腿。注意分享现场演示 KEYS 时一定是对本地测试实例跑不是对生产库。这个操作本身没有破坏性但它的阻塞效果在线上会被放大成事故。单线程还要讲清楚一个边界否则容易被较真的听众抬杠Redis 的单线程只指执行命令的核心线程持久化、异步删除、AOF 重写这些都有后台线程或子进程在干。扩展读并发靠加从库做读写分离合并多次网络往返靠 Pipeline保证多条命令原子执行靠 Lua 脚本。把这个逻辑顺下来听众对为什么快和快有什么代价就都有概念了。3. 从演示到生产缓存三大问题与持久化选型的落地讲法数据结构是 Redis 的入门真正决定一份分享含金量的是把缓存写入这件事讲到生产级。这一章对应 pptx 的中段也是听众最想抄作业的部分。很多团队用 Redis 只跑 GET 和 SET问起来就说缓存嘛但缓存和数据库之间的那层逻辑才是线上事故的高发区。分享时一定要把缓存读写的基本模式写出来再讲三个经典问题。3.1 穿透、击穿、雪崩一张表讲清区别与对策先给听众看一段最常见的缓存读写代码也就是 cache-aside 模式。这段代码建议用 Python 或 Java 写不要用 redis-cli 命令代替因为听众回去要照着写业务代码不是照着手敲命令行def get_user(user_id): cache_key fuser:info:{user_id} # 1. 先查缓存命中直接返回 data redis.get(cache_key) if data is not None: return data # 2. 缓存没命中回源查数据库 user db.query(SELECT * FROM user WHERE id%s, user_id) # 3. 数据库也没有空值也写缓存TTL 给短一点挡住穿透 if user is None: redis.set(cache_key, , ex60) return None # 4. 查询结果写回缓存TTL 加随机值避免同一时间集体过期 redis.set(cache_key, user, ex300 random.randint(0, 60)) return user这段代码里藏着两个应对思路第 3 步的空值短 TTL是防穿透的标准做法一个根本不存在的 user_id 反复被查时数据库不会被打穿代价是缓存里会多一批空 key所以 TTL 只给 60 秒第 4 步的TTL 加随机值是防雪崩的最朴素手段批量写入时每个 key 的过期时间错开 0 到 60 秒就不会出现整点集体过期的场面。ex 参数是 Redis 设置过期时间的标准写法后面所有涉及 TTL 的地方都是同一个语义。穿透解决了击穿还得单独讲。击穿和穿透最大的区别是击穿打的是一个真实存在、且访问量极高的热点 key它在过期的那一瞬间大量请求同时回源。这时候空值缓存没用因为 key 是真实存在的。常见做法是互斥重建只让一个请求去查库其余请求等锁def rebuild_hot_key(cache_key, expire_time): # nxTrue 保证只有一个请求拿到锁其余请求走等待重试 lock_key flock:{cache_key} if redis.set(lock_key, 1, nxTrue, ex10): try: # 只有拿锁的请求查数据库并重建缓存 data db.query(SELECT ...) redis.set(cache_key, data, exexpire_time) finally: # 释放锁严谨的做法是 Lua 比较 value 再删防止误删别人的锁 redis.delete(lock_key) else: # 没拿到锁短暂等待后读缓存通常已经重建完成 time.sleep(0.1) return redis.get(cache_key)参数说明nxTrue 对应 SET 命令的 NX 选项key 不存在时才写入成功这就是拿锁的语义ex10 是锁的自动过期时间防止拿到锁的线程还没执行完就崩溃锁变成死锁。finally 里释放锁是必须的但严谨的团队会用 Lua 脚本先比较锁里的 value 再删除避免一个线程误删另一个线程的锁。锁的过期时间也不能拍脑袋要大于查库和重建缓存的最坏耗时否则锁先过期又放进来一批并发重建。三个问题放一起对比听众最容易搞混一张表讲清楚问题现象根因对策缓存穿透缓存永远不命中压力全到数据库查询的 key 本身不存在空值短 TTL 缓存、布隆过滤器、接口入参校验缓存击穿某个热点 key 过期瞬间数据库被打单个热 key 到期且并发极高互斥重建、逻辑过期、热点永不过期缓存雪崩大面积 key 同时过期数据库瞬时崩溃批量 key TTL 相同或实例宕机TTL 加随机值、多级缓存、限流降级3.2 RDB 与 AOF持久化选型表与演示命令缓存之外Redis 作为存储用的时候持久化是分享里不能跳过的一段。很多团队把 Redis 当纯缓存用就关了持久化这没问题但一旦里面放了会话、任务状态、计数就得想清楚重启后数据还在不在。分享时我常跟听众说一句话缓存不是保险箱没配持久化的 Redis 重启后就是一张白纸这时候才想起来做配置是没有后悔药的。持久化部分放两组配置就够了一组是 RDB 快照触发点一组是 AOF 开关和刷盘策略# RDB 自动触发点满足任意一条就执行 bgsave save 3600 1 save 300 100 save 60 10000 # AOF 开关与刷盘策略 appendonly yes appendfsync everysecsave 的写法是时间 变化次数3600 秒内有 1 次写就存300 秒内有 100 次写就存60 秒内有 10000 次写就存多行之间是或的关系满足任意一条就触发。appendfsync 有三个取值always 每条命令都刷盘最安全也最慢everysec 每秒刷一次是默认平衡点最多丢一秒数据no 完全交给操作系统性能最好但丢得最多。生产环境绝大多数选 everysec这个参数值得在分享时重点讲因为它就是性能和数据安全之间的那个旋钮。RDB 和 AOF 的取舍用表格一页讲完维度RDBAOF文件形态二进制快照体积小命令追加日志体积大可压缩恢复速度快慢数据丢失最近一次快照之后的写入everysec 最多丢 1 秒always 不丢性能影响bgsave 时 fork 子进程大内存机器有毛刺刷盘频率直接影响写延迟首选场景缓存、可重建数据数据不能丢、一致性要求高现在主流的做法是两者同时开或者用混合持久化重启时先用 RDB 快照快速加载再补 AOF 增量兼顾恢复速度和完整性。分享现场可以演示两条手动命令和两个体检工具BGSAVE 手动触发快照BGREWRITEAOF 手动压缩 AOF 文件redis-check-rdb 和 redis-check-aof 分别校验两个文件是否损坏。这几个命令在面试里也常被问讲清楚等于给听众送分。4. 高可用与集群主从、哨兵、Cluster 的边界和参数讲到高可用ppt 的进度大概过了三分之二听众开始进入这些我好像知道的状态。这一章的关键不是背概念而是把三个层次的边界讲清楚主从解决的是读写分离和宕机恢复哨兵解决的是自动故障切换Cluster 解决的是数据量超过单机容量。很多人把哨兵和 Cluster 混为一谈分享时一定要从解决的问题不同切入。4.1 主从复制与哨兵故障切换的流程与最小配置主从复制的最小配置就一行从节点上写好主节点地址重启生效主节点不用改任何东西# 从节点配置一行就够 replicaof 192.168.1.10 6379 # 主库写保护从库少于 1 个或延迟超过 10 秒时拒绝写入 min-replicas-to-write 1 min-replicas-max-lag 10复制的流程要讲两句第一次连接做全量同步主库生成 RDB 快照发给从库同时把快照期间的写命令缓冲下来补发之后是增量同步主从各自维护复制偏移量从库落后不多时用 backlog 补差价落后太多才重新全量同步。min-replicas-to-write 这个参数一定要讲它和后面的脑裂场景直接相关当从库数量不足或延迟过大时主库拒绝写入宁可损失可用性也不让数据产生分裂。主从本身不提供自动切换主库宕机后需要人工把从库提升为主或者交给哨兵。哨兵的最小部署是三台配置核心就三行# 三台哨兵quorum 为 2至少 2 台哨兵认为主库挂了才发起切换 sentinel monitor mymaster 192.168.1.10 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000这里的 2 是 quorum指判定主库故障需要几票哨兵总数是奇数三台配 quorum 2五台配 quorum 3避免出现平票。down-after-milliseconds 是主观下线的判定时长5000 毫秒内主库没有响应就标记为疑似下线failover-timeout 控制整个切换过程的超时防止切换卡死。切换流程可以一句话概括哨兵确认主库客观下线从候选从库中选一个数据最新的提升为主其余从库改为复制新主客户端通过哨兵感知新的主节点地址。这里有个高频追问主从切换后最近几秒的写入丢了怎么办。复制是异步的从库大概率落后主库一段增量切换时这段增量没同步完就丢了这是异步复制的固有窗口。结合上面的 min-replicas-to-write 就能兜住脑裂场景旧主库被隔离后切断了和所有从库的连接写保护触发拒绝写入把损失控制在隔离期间而不是让旧主库继续接收业务写入。4.2 Redis Cluster槽位分配与多 key 操作的边界单机内存不够了才轮到 Cluster 出场。Cluster 把数据打散到多个节点每个节点负责一部分槽位整个集群一共 16384 个槽。分享时的演示命令如下# 创建三主三从集群--cluster-replicas 1 表示每个主节点带 1 个从节点 redis-cli --cluster create 192.168.1.10:6379 192.168.1.11:6379 \ 192.168.1.12:6379 192.168.1.13:6379 192.168.1.14:6379 192.168.1.15:6379 \ --cluster-replicas 1 # 查一个 key 应该落在哪个槽位CRC16(key) 对 16384 取模 redis-cli cluster keyslot user:1001 # 查当前槽位分布确认数据是否均匀 redis-cli cluster slotsCluster 最大的坑在边界上。因为 key 分散在不同节点跨槽位的多 key 操作就不成立了MSET 涉及多个 key 时所有 key 必须落在同一槽Pipeline 里跨槽的命令会报错Lua 脚本操作多个 key 时也要求在同一槽。解决方法是哈希标签用花括号把要绑定在一起的 key 包起来CRC16 只对花括号里的内容计算# 用 {} 让两个 key 落进同一槽才能做多 key 操作 redis-cli MSET {order}:1001 amount 99 {order}:1001 status paid客户端访问 Cluster 时还会遇到两种重定向MOVED 表示这个 key 的槽已经迁移到另一个节点客户端要更新路由表ASK 表示槽正在迁移中数据可能还在旧节点客户端要带 ASKING 去新节点试试。这两个状态码在分享时提一句即可听众知道迁移期间请求会被重定向这个事实就够了。主从、哨兵、Cluster 三种模式放一张对比表收尾听众就能记住各自的适用边界模式自动故障转移数据分片适合规模典型场景主从无需人工介入无读多写少读写分离、备份哨兵有无单机容量内高可用、自动切换Cluster有有数据量超单机大规模缓存、存储5. 分享现场最容易被追问的坑5 个高频事故的排查路径问答环节才是分享的高潮。听众不会问ZSet 底层是什么这种背课文的问题他们问的都是线上真实事故。这一章的内容建议直接做成 pptx 的附录页遇到追问就翻出来。以下 5 个场景每个都按现象、原因、解决三步讲都是我在准备分享和帮同事排查时反复遇到过的算是一线积累下来的血泪经验。5.1 大 key 删除让主线程卡了几秒现象某接口平时 5 毫秒返回某天突然出现几秒的超时Redis 监控里 ops 曲线瞬间掉到 0 又弹回来应用日志里全是超时重试。原因有人在清理数据时对一个超大集合执行了 DEL或者业务把十几万元素的 List 当队列用删除时 DEL 是 O(N) 操作在单线程模型里执行期间所有命令都在排队。解决删除大 key 用 UNLINK后台线程慢慢回收不阻塞主线程同时打开 lazyfree 相关配置让 key 的释放都走异步。日常巡检用 redis-cli --bigkeys 提前扫出大 key超过一定大小的集合要做拆分或者换 Hash 分片存储。这个坑最麻烦的地方在于它不是每次必现而是数据量涨到某个阈值才爆发所以分享时一定要强调提前发现而不是事后处理。5.2 整点缓存雪崩数据库被打垮现象每天整点或零点缓存命中率骤降数据库 CPU 和连接数同时拉满缓存重建也建不起来接口大面积超时。原因批量初始化数据时 TTL 全部写成一样的时间一到集体过期所有请求同时回源。定时任务在整点刷新缓存是最常见的触发方式比随机写入更容易踩中。解决写入时 TTL 加随机秒数比如 300 到 360 之间随机热点数据干脆不设置过期时间由后台任务定时刷新再不行就在数据库前面加一层限流和降级让数据库先活下来。这里有个容易被忽略的点如果缓存重建本身很慢雪崩后会形成一边过期一边打库的恶性循环所以热点 key 的逻辑过期方案比单纯加随机值更彻底。5.3 主从切换后最近几秒的写丢了现象主库宕机哨兵完成切换后业务恢复但业务方对比数据库和 Redis发现 Redis 里少了最近几秒的写操作。原因复制是异步的从库大概率落后主库一段增量切换时这段增量没来得及同步就丢了。这是异步复制的固有窗口不是配置错误。解决对不能丢的数据写主库后调 WAIT 命令等待至少一个从库确认再返回在哨兵模式配上 min-replicas-to-write 和 min-replicas-max-lag让孤立主库少写甚至拒写。分享时可以明确告诉听众Redis 默认是可用性优先想要强一致就别让它当唯一数据源数据库或消息队列才是兜底。5.4 一条 KEYS 命令让线上抖了一下现象版本发布后某个接口偶发超时慢查询日志里出现大量 GET 排队超过 1 秒Redis 的 ops 曲线出现周期性凹陷。原因新上线的同学用 KEYS 做模糊搜索或者用 HGETALL 拉取了一个持续增长的大 Hash执行时间越来越长单线程被打满。这类问题隐蔽在代码审查里很难发现因为本地数据量小跑不出性能差异。解决模糊匹配改成 SCAN 游标遍历分页处理大 Hash 用 HSCAN 分页读取或者拆成多个小 key。排查时用 SLOWLOG GET 确认是哪条命令、执行了多久再顺着调用链找到代码位置。如果慢查询里反复出现同一个 key 的 HGETALL那基本可以断定是大 key 读而不是命令本身的问题。5.5 连接数被打满新请求被拒绝现象应用日志报 max number of clients reachedRedis 新连接全部失败业务大面积报错重启应用后恢复过一段时间又复现。原因客户端没有用连接池每个请求都新建连接或者某台机器连接泄漏TIME_WAIT 堆满把 maxclients 顶穿。Redis 单机默认连接数上限通常是一万看起来很多但架不住每个请求一条连接。解决客户端统一走连接池设置合理的 maxTotal 和 maxIdle空闲连接及时回收服务端调 timeout 让空闲连接被回收排查期间用 INFO clients 看 connected_clients 和 blocked_clients定位是哪个客户端没还连接。我在某跨平台系统的压测阶段就真实踩过这个坑压测脚本不走连接池直接把 Redis 打到拒绝连接后来所有压测脚本都默认先检查连接池配置。6. 最后一页演示用三个命令验证 Redis 状态顺便收尾分享分享的最后一页别放谢谢两个字就结束放一个现场体检环节听众记住的是动作不是口号。我习惯用三个命令收尾分别对应内存、性能、状态三个维度每一页放一条加一句解读三分钟讲完比任何总结都有效。# 1. 内存体检自动扫描各类 key 的大小分布揪出大 key redis-cli --bigkeys # 2. 压测现场跑出每秒几万的 ops证明 Redis 单线程也能扛高并发 redis-benchmark -c 50 -n 100000 -t set,get # 3. 看关键指标命中率、连接数、运行状态 redis-cli INFO stats redis-cli INFO clients--bigkeys 会遍历实例并对每个 key 做类型和大小估算只读不阻塞适合分享现场跑扫完会按类型列出最大的几个 key。redis-benchmark 的 -c 是并发连接数-n 是总请求数-t 是只测 set 和 get现场看到每秒几万的 ops比讲一百遍Redis 快都有说服力。INFO stats 里重点看 keyspace_hits 和 keyspace_misses两个值一除就是命中率命中率长期低于 90%基本可以断定缓存设计有问题INFO clients 看 connected_clients 是否异常增长结合上面的连接数事故一起讲正好首尾呼应。最后再补一个动作算是给想回去改代码的听众一个抓手缓存和数据库的一致性。很多人问先更新数据库还是先删缓存我的习惯是先更新数据库再删缓存并且删两次def update_user(user_id, new_data): # 1. 先更新数据库 db.execute(UPDATE user SET ... WHERE id%s, user_id) # 2. 再删缓存让下次读的时候重建 redis.delete(fuser:info:{user_id}) # 3. 延迟后再删一次兜住并发读把旧值写回缓存的窗口 time.sleep(0.5) redis.delete(fuser:info:{user_id})更新顺序必须是先库后缓存因为先删缓存再更新库的话更新期间读请求会把旧值写回缓存脏数据窗口更长。延迟双删解决的是更新完库还没删缓存的间隙里并发读把旧值写回缓存的问题——睡 0.5 秒再删一次把这个脏窗口补上。这个 0.5 不是固定值按业务读链路耗时调读链路越慢睡得越久更彻底的方案是订阅数据库 binlog异步删缓存但那需要额外的组件分享时点到为止即可。我自己在给某跨平台系统做缓存改造时就因为只删了一次缓存线上出现过一次老数据回写用户看到的是改完的资料又变回旧值。从那以后凡是用 cache-aside 的地方默认都带上延迟双删。分享收尾时把这个动作连同三个体检命令一起留给听众比再背一遍数据结构有用。希望帮到你。本文还有配套的精品资源点击获取