03. Redis：过期淘汰、持久化、高可用（深挖版）¶

Redis 到了这一章，面试官通常已经不满足于"为什么快"。他们更常问的是：

key 过期了为什么内存没立刻降？

淘汰策略怎么选？

大 key 为什么危险？

主从复制、Sentinel、Cluster 分别解决什么问题？

缓存一致性为什么永远像打地鼠？

这章的重点，就是把 Redis 从"缓存工具"讲到"工程系统"。

本章建议按“先理解知识主线，再练问答表达，最后吃透边界条件”的顺序阅读：

先把过期删除策略、内存淘汰策略

再展开大 key、主从复制、Sentinel vs Cluster

最后把缓存一致性、Redis 高可用与最终一致

先把这一章的知识骨架搭起来¶

Redis 高可用不是“背 RDB / AOF / Sentinel / Cluster 名字”，而是理解 一个以内存为主的数据系统，怎样在速度、持久化、复制延迟和故障恢复之间做权衡。因为 Redis 快，但它也更怕丢数据、怕单点、怕热点、怕大 key、怕内存打满。

所以建议你沿着“单机 Redis 为什么快 → 单机 Redis 会遇到什么风险 → 主从、哨兵、集群分别解决哪一类问题”的顺序来读。过期淘汰和持久化是在处理内存与数据安全问题，主从复制在处理读扩展与备份问题，Sentinel 在处理自动故障转移问题，Cluster 在处理分片扩展问题。

面试里如果你能顺着这条线讲，就会显得像在讲系统设计，而不是背组件名。

第一部分：先把概念和主线讲清楚¶

进入问答前，先把最小前置知识补齐¶

Redis 高可用题不能只背组件名，最好先建立一个单机到分布式的演进视角：单机为什么快、单机会遇到哪些风险、复制和分片分别在解决什么问题。

过期与淘汰解决的是内存有限时怎样保热点，RDB/AOF 解决的是速度与数据安全的平衡，主从复制解决读扩展和备份，Sentinel 解决自动故障转移，Cluster 解决容量和分片扩展。只要这条演进线清楚，后面的问答就不会散。

1. Redis 过期删除策略有哪些？¶

标准回答¶

定时删除
惰性删除
定期删除

实践中通常结合使用，以平衡 CPU 开销和内存回收及时性。

为什么不能只用一种？¶

只用定时删除¶

如果每个 key 到点都精确删除：

CPU 开销会很大
维护成本高

只用惰性删除¶

只有访问时才发现过期：

CPU 省了
但很多长期不访问的过期 key 会继续占内存

定期删除的意义¶

后台周期性抽样扫描一部分过期 key：

比精确逐个检查省成本
又能避免大量垃圾长期堆着

一句总结¶

Redis 过期删除不是追求"绝对实时清理"，而是在 CPU 成本和内存回收及时性之间做折中。

2. Redis 内存淘汰策略有哪些？¶

常见策略¶

noeviction
allkeys-lru
volatile-lru
allkeys-lfu
volatile-ttl 等

这些策略本质在回答什么问题？¶

当内存达到上限时：

哪些 key 应该优先被牺牲？

常见理解¶

allkeys-*：所有 key 都可能被淘汰
volatile-*：优先从设置了过期时间的 key 里淘汰
lru：倾向淘汰最近最少使用
lfu：倾向淘汰使用频率更低的

怎么选？¶

取决于业务特征：

热点相对稳定：LFU 常更有价值
访问局部性明显：LRU 常较合适
不允许写入失败：不能只看淘汰命中率，也要看兜底策略

3. Redis 为什么会有大 key 问题？¶

风险¶

单次操作阻塞更久
网络传输耗时大
删除成本高
主从复制压力大
AOF / RDB 持久化负担更重

为什么"大"会变成系统问题？¶

因为 Redis 很多性能优势建立在：

单次操作足够轻
主线程尽快处理完命令

一旦某个 key 很大：

读取/删除/迁移都会拖长命令执行时间
其他请求也会被排队影响

高分点¶

大 key 的风险不只是"占内存多"，更在于它会放大 Redis 单线程主路径、网络复制和持久化链路上的延迟问题。

第二部分：围绕高频追问继续展开¶

4. Redis 主从复制有什么作用？¶

常见作用¶

读扩展
故障恢复基础
数据备份冗余

但不要把它理解得太理想化¶

主从复制能提高可用性，但也带来：

复制延迟
主从不一致窗口
故障切换复杂性

面试高分点¶

主从复制不是强一致复制系统，它更多提供的是高可用基础和读扩展能力，而不是无条件实时一致。

5. Sentinel 和 Cluster 区别？¶

Sentinel¶

偏高可用，负责：

监控
故障检测
主从切换

它不负责数据分片。

Cluster¶

同时解决：

高可用
数据分片

它把数据分散到多个节点上，提升容量和横向扩展能力。

怎么理解两者定位？¶

Sentinel：更像"主从复制 + 自动故障转移控制面"
Cluster：更像"带分片能力的 Redis 集群架构"

面试别答混¶

很多人会把 Sentinel 说成"Redis 集群方案"，这不够准确。它偏高可用管理，不是分片方案。

第三部分：把难点、边界和代价吃透¶

6. 缓存一致性怎么做？¶

常见策略¶

先更新数据库，再删缓存
延迟双删
基于消息队列异步失效
业务层幂等和兜底校验

为什么这个问题永远难？¶

因为缓存和数据库天然是两个系统：

更新顺序不可能绝对完美
网络抖动、重试、并发都会制造竞态

为什么常见推荐是"更新 DB，再删缓存"？¶

因为如果先删缓存再更新数据库，可能出现：

缓存删了
旧数据又被并发请求回填进缓存
数据库才更新完成

这样缓存里会重新躺进旧值。

但"先更 DB 再删缓存"也不是绝对完美¶

因为还可能发生：

数据库更新成功
缓存删除失败

所以常见还要配：

重试
延迟双删
MQ 补偿
过期时间兜底

一句总结¶

缓存一致性很多时候不是"彻底杜绝不一致"，而是把不一致窗口尽量缩小，并提供补偿与兜底机制。

7. 为什么 Redis 高可用不等于高一致性？¶

原因¶

高可用关注的是：

节点挂了还能不能继续服务

高一致性关注的是：

数据在主从切换、复制延迟、故障瞬间是否完全一致

Redis 常见架构里：

高可用可以做得不错
但强一致通常不是它的核心卖点

高分点¶

Redis 适合做高性能缓存和轻量状态系统，但如果业务要求极强一致，不能只靠"有主从/有 Sentinel"就放心。

8. 一组典型追问链¶

Redis key 过期为什么不是立刻删除？
过期删除和内存淘汰是一个概念吗？
淘汰策略应该怎么选？
大 key 为什么危险？
主从复制会不会强一致？
Sentinel 和 Cluster 各解决什么问题？
缓存一致性为什么难？
为什么"删缓存"也会删出竞态？

9. 一份更像面试现场的总结回答¶

Redis 真正难答的地方，不在"为什么快"，而在于你能不能把它讲成一个完整系统。过期删除和内存淘汰是在内存资源有限前提下做成本权衡，大 key 会拖慢主线程与复制链路，主从复制和 Sentinel / Cluster 解决的是不同层面的高可用问题，而缓存一致性则本质上是数据库与缓存两个系统之间的竞态控制问题。真正成熟的回答，不是说 Redis 很快，而是能说清它在哪些地方快、在哪些地方脆，以及应该怎么兜底。

10. 复习建议¶

至少做到：

能区分过期删除和内存淘汰
能说明为什么过期 key 不会立刻全部消失
能讲清大 key 的系统性风险
能区分 Sentinel 和 Cluster 的职责
能把缓存一致性说成"竞态控制 + 补偿兜底"问题

做到这里，Redis 这一章就开始有工程味了，而不只是记忆点堆砌。