Redis 缓存设计

Tue, 25 Aug 2026 00:00:00 +0000

引入缓存能显著降低数据库压力，但设计不当会引入穿透、击穿、雪崩等经典问题。下面逐一拆解成因与对策。

三大经典问题

缓存穿透：查询不存在的数据，缓存与数据库都查不到，请求每次都打到 DB。应对：缓存空值（短过期）、布隆过滤器拦截非法 key。
缓存击穿：某个热点 key 过期瞬间，大量并发同时回源 DB。应对：互斥锁（只放一个线程重建）、逻辑过期（异步刷新）、热点 key 不过期。
缓存雪崩：大量 key 同一时刻集中失效，或 Redis 整体不可用，DB 被冲垮。应对：过期时间加随机抖动、多级缓存、Redis 高可用（哨兵/集群）。

Cache-Aside 与一致性

最常用的是 Cache-Aside（旁路缓存）：

读: 先读缓存 -> 命中返回; 未命中读 DB -> 写入缓存
写: 先更新 DB -> 再删除缓存 (而非更新缓存)

「先更新 DB 再删缓存」可降低并发下读到旧值的概率；极端不一致可通过延迟双删或订阅 binlog（如 Canal）补偿。注意：不要盲目「更新缓存」，否则并发写可能产生脏数据。

大 key 与热 key

大 key：如包含百万元素的 hash/list，删除或序列化会阻塞主线程。应对：拆分、分批删除（unlink）、定期清理。
热 key：单个 key 访问极高，单节点成为瓶颈。应对：本地缓存副本、key 打散到多个副本、Redis 集群分片。

过期与淘汰策略

Redis 提供主动 + 惰性两种过期删除，内存不足时按 maxmemory-policy 淘汰：

缓存设计的那些坑

Wed, 08 Jul 2026 00:00:00 +0000

缓存是最容易加的优化，也是最容易埋雷的优化。加的时候只要几行代码，出问题时往往是深夜的数据不一致或者数据库被打穿。

一致性：先更库还是先删缓存

这个问题的正确答案是先更新数据库，再删除缓存（Cache Aside）。但要理解它为什么仍然不完美。

先删缓存再更库的问题很直接：删完缓存到更库完成之间，另一个请求读到旧数据并把它写回缓存，之后缓存里就一直是脏数据。

先更库再删缓存也有极小概率出问题：读请求恰好在缓存失效后读到旧库值，且回写发生在删除动作之后。概率很低，但在高并发下不等于零。

@Transactional
public void updateLimit(String accountNo, Money newLimit) {
 limitRepository.update(accountNo, newLimit); // 1. 先落库
 // 2. 事务提交后再删缓存，避免删除后事务回滚导致缓存空档
 TransactionSynchronizationManager.registerSynchronization(
 new TransactionSynchronization() {
 @Override public void afterCommit() {
 cache.delete(limitKey(accountNo));
 }
 });
}

afterCommit 这一步很关键。在事务内删缓存，如果事务随后回滚，缓存已经被清掉，下一次读会把旧值再加载回来——看起来是对的，但实际上你丢失了一次删除的语义保证。

更重要的判断是：这个数据到底能不能容忍短暂不一致。限额、开关、风控规则这类直接影响资金准入的配置，我们干脆不缓存或者只做几秒的本地缓存，宁可多查一次库。

三大经典故障

穿透：查一个根本不存在的 key，每次都落库。恶意刷不存在的账号就是这么打穿数据库的。做法是缓存空值并设短过期（比如 60 秒），或者前置布隆过滤器。
击穿：热点 key 过期瞬间大量请求同时落库。做法是加互斥锁，只让一个线程去加载，其余等待或返回旧值。
雪崩：大批 key 同时过期，或者 Redis 整体不可用。前者靠给过期时间加随机抖动解决；后者必须有降级预案——限流加返回兜底数据，不能让流量全量透传到数据库。

// 过期时间加抖动，避免批量同时失效
private Duration ttlWithJitter(Duration base) {
 long jitter = ThreadLocalRandom.current()
 .nextLong(base.toSeconds() / 10 + 1); // 上下浮动约 10%
 return base.plusSeconds(jitter);
}

热 key 与大 key

这两个是运维阶段最常见的问题，开发时基本不会注意到。

缓存 on 追风笔记