缓存设计的那些坑

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 追风笔记

缓存设计的那些坑

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

三大经典故障

热 key 与大 key