Redis 与缓存

软件设计师考试 · 考点总结 · 2026

Redis 与缓存
├── 1. Redis 基础
│   ├── Redis vs Memcache
│   ├── 五大数据类型
│   └── 持久化（RDB / AOF）
├── 2. 缓存三大问题 ⭐⭐⭐
│   ├── 缓存雪崩（大量key同时失效）
│   ├── 缓存穿透（查询不存在的数据）
│   └── 缓存击穿（热点key过期）
├── 3. 缓存与数据库协作
│   ├── Cache-Aside 策略 / 读写流程
│   └── 缓存预热 / 缓存更新
├── 4. Redis 分布式方案 ⭐⭐
│   ├── 主从模式（一主多从，手动切换）
│   ├── 哨兵模式（自动故障转移）
│   └── 集群模式（slots分片）
├── 5. 分片策略
├── 6. 淘汰机制
└── 7. CAP 定理 ⭐⭐

一Redis 基础

1.1 Redis vs Memcache ⭐

对比项	Memcache	Redis
数据类型	简单 key-value	丰富的数据结构
持久化	不支持	支持（RDB / AOF）
分布式存储	客户端哈希/一致性哈希	多种方式，主从/哨兵/集群
多线程支持	支持	Redis 5.0 及以前不支持（6.0+ I/O多线程）
内存管理	私有内存池	无（依赖系统分配器）
事务支持	不支持	有限支持（MULTI/EXEC，非原子回滚）
容灾恢复	不支持，不能数据恢复	支持，可通过持久化恢复数据

记忆要点：Redis 功能更全面（数据类型丰富、支持持久化、支持容灾），Memcache 更简单轻量，适合纯缓存场景。

1.2 五大数据类型 ⭐

类型	底层结构	特点	典型应用
`String`	SDS（简单动态字符串）	二进制安全，最大 512MB	缓存、计数器、共享 Session
`Hash`	ziplist / hashtable	无序字典，key 对应 HashMap	存储/读取/修改用户属性
`List`	quicklist（双向链表）	有序、可重复	消息队列、文章列表、最新动态
`Set`	intset / hashtable	无序、唯一	独立IP统计、共同好友、标签
`Sorted Set`	ziplist / skiplist	有序（按score）、唯一	排行榜、延迟队列

记忆口诀

"S H L S Z" → String、Hash、List、Set、ZSet

1.3 持久化 ⭐⭐

对比项	RDB（快照）	AOF（日志追加）
备份方式	全量备份	增量备份（只保存写命令）
保存间隔	长（分钟级）	短，默认每秒 fsync
还原速度	快	慢（需重放所有命令）
阻塞情况	save 阻塞，bgsave 不阻塞	不阻塞
文件体积	小（二进制压缩）	大（文本命令）
数据安全性	低，可能丢失分钟级数据	高，最多丢失 1 秒数据

考试陷阱：RDB 的 save 命令会阻塞主线程，bgsave fork 子进程不阻塞。这是高频考点！

RDB = 快照 = 全量 = 快恢复 = 低安全
AOF = 日志 = 增量 = 慢恢复 = 高安全
混合持久化（Redis 4.0+）= AOF 文件前半段是 RDB，后半段是 AOF 增量，兼顾速度与安全

二缓存三大问题 ⭐⭐⭐ 高频必考

2.1 三大问题对比

问题	核心原因	影响	解决方案
缓存雪崩	大量 key 同时失效	数据库被大量请求压垮	①加锁/队列 ②随机失效时间 ③二级缓存
缓存穿透	查询不存在的数据	每次请求都穿透到数据库	①布隆过滤器 ②缓存空值
缓存击穿	单个热点 key 过期	大量并发请求打到数据库	①热点永不过期 ②逻辑过期 ③互斥锁

2.2 详细解析

缓存雪崩

大量 key 同时失效

→

所有请求直达数据库

→

数据库崩溃

方案	说明
加锁/队列	控制并发，只允许一个线程查询数据库并更新缓存
随机失效时间	在固定过期时间基础上 + 随机偏移量，避免同时失效
二级缓存	本地缓存（Caffeine）+ Redis 缓存，降低 Redis 失效影响

缓存穿透

查询不存在的 key

→

缓存未命中

→

数据库也无数据

→

每次都打到 DB

方案	说明
布隆过滤器	快速判断 key 是否存在，不存在直接返回（有误判率，无漏判）
缓存空值	将不存在的数据缓存为 null，设置较短过期时间（如 5 分钟）

缓存击穿

热点 key 过期

→

大量并发请求同时到达

→

全部打到数据库

方案	说明
热点永不过期	对极高频热点 key 不设置物理过期时间
逻辑过期	缓存值中保存逻辑过期时间，过期后先返回旧值，异步线程刷新缓存
互斥锁	只有一个线程回源查询数据库并重建缓存，其他线程等待或返回旧值

记忆技巧

缓存雪崩 = 大量 key 同时失效 → "雪崩" → 一大片雪同时落下
缓存穿透 = 查询不存在的数据 → "穿透" → 穿过缓存直达数据库
缓存击穿 = 单个热点 key 过期 → "击穿" → 一个点被击穿

案例分析答题模板：
"大量缓存同时过期" → 缓存雪崩 | "查询不存在的数据" → 缓存穿透 | "热点数据过期、高并发" → 缓存击穿

三缓存与数据库协作 ⭐⭐

3.1 Cache-Aside 策略

读流程

1. 先查询缓存
2. 缓存命中 → 直接返回
3. 缓存未命中 → 查询数据库 → 将结果写入缓存 → 返回

写流程

1. 先更新数据库
2. 再删除缓存（而非更新缓存）

为什么先更新数据库，再删除缓存？
若先删缓存再更新DB：并发读请求会在删除后、更新前将旧数据写回缓存，造成脏数据。
先更新DB再删缓存：即使并发读在更新后、删除前读到旧缓存，下次请求会重建缓存，最终一致。

3.2 缓存预热

系统启动前，预先将热点数据加载到缓存中，避免启动后大量请求穿透到数据库。

系统启动时触发数据加载任务
定时任务提前加载热点数据
根据历史访问记录预测热点数据

3.3 缓存更新策略

策略	说明	适用场景
定期过期	设置 TTL，过期后下次请求重建	数据实时性要求不高
主动更新	数据变更时同步删除/更新缓存	数据一致性要求高
异步更新	通过消息队列异步刷新缓存	高并发写场景

四Redis 分布式方案 ⭐⭐

4.1 三种模式对比

方案	特点	故障切换	数据分片	适用场景
主从模式	一主多从	手动切换	不支持	读多写少，可接受手动运维
哨兵模式	主从 + Sentinel 监控	自动切换	不支持	需要高可用，数据量不大
集群模式	多节点对等	自动切换	支持（16384 slots）	海量数据，需横向扩展

4.2 主从模式

一主多从的复制方案，主节点负责写入，从节点复制主节点数据
可分担读请求，提高读能力（读写分离）
支持全量复制（首次同步）和增量复制（断线重连后）
局限：主节点故障时需要手动切换，存在单点风险

4.3 哨兵模式

在主从模式基础上引入 Sentinel 进程监控
核心能力：监控主从节点健康状态、发现故障、自动选举新主节点
通常部署奇数个 Sentinel（至少 3 个），通过投票机制决策
适用场景：需要自动故障转移，但数据量不需要分片扩展

4.4 集群模式（Redis Cluster）

通过 16384 个 slots 将 key 空间切分到不同节点
key 通过 CRC16 哈希后对 16384 取模，确定所在 slot
客户端访问错误节点时，服务端返回 MOVED 重定向（永久迁移）或 ASK 重定向（迁移中）
每个主节点可配置从节点，支持自动故障转移

记忆要点

主从模式 = 基础版（手动切换）
哨兵模式 = 主从 + 自动切换（高可用）
集群模式 = 主从 + 自动切换 + slots 分片（高可用 + 高扩展）

五分片策略 ⭐

分片方式	说明	优点	缺��
范围分片	按数据范围分片，如按用户 ID 段	实现简单，范围查询方便	数据分布不均，热点问题
哈希分片	对 key 进行 hash 取模，余数相同的在同一节点	数据分布均匀	节点增减时大量数据迁移
一致性哈希	哈希分片的改进，节点映射到哈希环	节点增减只影响相邻节点数据	数据分布可能不均（虚拟节点解决）

5.1 Redis 集群切片方式

切片方式	特点	代表
客户端切片	客户端通过 key 的 hash 值路由到不同服务器	Jedis ShardedJedis
中间件切片	中间件实现路由分配，客户端无感知	Codis、Twemproxy
客户端服务端协作分片	服务端提供 slot 重定向，客户端缓存路由表	Redis Cluster

六淘汰机制 ⭐

当 Redis 内存不足时触发，根据配置的策略决定淘汰哪些数据。

淘汰范围	策略名	说明
不淘汰	`noeviction`	禁止驱逐，内存不足时写入报错（系统默认）
过期键空间（volatile-）	`volatile-random`	随机移除某个有过期时间的 key
	`volatile-lru`	优先移除最近最少使用的有过期时间的 key
	`volatile-lfu`	优先移除使用频率最低的有过期时间的 key（Redis 4.0+）
	`volatile-ttl`	TTL 值越小越优先淘汰
全键空间（allkeys-）	`allkeys-random`	随机移除任意 key
	`allkeys-lru`	优先移除最近最少使用的 key（推荐通用场景）
	`allkeys-lfu`	优先移除使用频率最低的 key（Redis 4.0+）

默认策略：noeviction（不淘汰，写入报错）
LRU = Least Recently Used（最近最少使用，按时间）
LFU = Least Frequently Used（最不经常使用，按频率，Redis 4.0 新增）
volatile- 开头 = 只淘汰有过期时间的 key | allkeys- 开头 = 淘汰所有 key

七CAP 定理 ⭐⭐

7.1 三个维度

维度	全称	含义
C - Consistency	一致性	所有节点在同一时刻看到的数据保持一致
A - Availability	可用性	每次请求都能在有限时间内得到响应（不保证最新数据）
P - Partition Tolerance	分区容错性	网络分区（节点间通信故障）时系统仍能继续运行

7.2 核心结论

分布式系统必须考虑网络分区，因此通常默认需要 P
在出现网络分区时，系统需要在 C 和 A 之间做权衡
三者不可兼得，最多只能同时满足两个

7.3 常见组合

组合	说明	示例系统
CP	一致性 + 分区容错（牺牲可用性）	ZooKeeper、HBase
AP	可用性 + 分区容错（牺牲强一致性，最终一致）	Cassandra、DynamoDB、Eureka
CA	一致性 + 可用性（无分区容错）	传统单机关系型数据库（理论上）

考试要点：分布式系统通常选择 CP 或 AP，CA 在分布式环境中几乎不可能实现（网络分区无法避免）。

八高频考点速记

8.1 选择题高频

Redis vs Memcache：Redis 支持丰富的数据结构和持久化
五大数据类型：String、Hash、List、Set、Sorted Set
RDB vs AOF：RDB 快但不安全，AOF 慢但安全；save 阻塞，bgsave 不阻塞
缓存雪崩 vs 穿透 vs 击穿的区分（核心原因不同）
默认淘汰策略：noeviction
CAP 定理：三者不可兼得，分布式系统默认需要 P
Redis Cluster 共 16384 个 slots

8.2 案例分析高频

识别缓存问题类型（雪崩/穿透/击穿）并给出解决方案
Cache-Aside 策略的读写流程（先更新 DB，再删缓存）
选择合适的 Redis 分布式方案（主从/哨兵/集群）
CAP 权衡分析（CP vs AP 的选择依据）
缓存与数据库的一致性问题

8.3 论文写作素材

Redis 在大型网站中的应用实践（缓存层设计）
缓存架构设计方案（多级缓存、缓存预热、缓存更新策略）
分布式缓存的一致性与可用性权衡（CAP 理论应用）

九速记口诀

"Redis五类型，RDB快AOF安，雪崩穿透击穿三兄弟，主从哨兵集群三级跳，CAP不可兼得P必选"

口诀片段	含义
五类型	String · Hash · List · Set · ZSet
RDB快AOF安	RDB 快照全量快恢复低安全；AOF 日志增量慢恢复高安全
雪崩穿透击穿	大量key同时失效 / 查询不存在数据 / 热点key过期
主从哨兵集群	手动切换 / 自动切换 / slots分片
CAP不可兼得P必选	分布式系统必须保证分区容错，在C和A间权衡