缓存工程全景知识图谱

4.1 缓存模式

Cache-Aside（旁路缓存）：应用自行管理缓存读写，最常见也最灵活。读时先查缓存，未命中则查 DB 并回填。写时先更新 DB，再删除缓存。简单但一致性窗口依赖删除时机。

Read-Through / Write-Through：缓存层代理所有读写，应用只和缓存交互。一致性更强但缓存层变重，适合读多写少且能接受缓存层故障影响写入的场景。

Write-Behind（异步写回）：写入先落缓存，异步批量刷回 DB。吞吐最高但有数据丢失风险，适合允许短暂不一致的计数、日志类场景。

4.2 一致性策略

延迟双删：先删缓存 → 更新 DB → 延迟再删一次。覆盖并发读导致的脏数据回填，但延迟时间难以精确估算。

Canal/Binlog 订阅：通过监听 DB 变更日志异步更新缓存，解耦业务代码。延迟取决于 Binlog 消费速度，适合最终一致性场景。

版本号/CAS：缓存写入时携带版本号，只有版本匹配才更新。防止旧数据覆盖新数据，但增加了读写复杂度。

阅读提醒：这里更像总览速写。删除顺序、旧值回填、业务正确性和止血策略的展开分析，建议继续看 缓存一致性图谱。

4.3 穿透、击穿与雪崩

缓存穿透：查询不存在的数据，每次都打到 DB。防御：布隆过滤器拦截、空值缓存（短 TTL）、请求参数校验前置。

缓存击穿：热点 Key 过期瞬间大量请求涌入 DB。防御：互斥锁（singleflight）、逻辑过期（后台异步刷新）、永不过期 + 主动更新。

缓存雪崩：大量 Key 同时过期或缓存集群宕机。防御：过期时间加随机抖动、多级缓存兜底、熔断降级、集群高可用。

4.4 热点 Key 与大 Key 治理

热点 Key：单个 Key 的 QPS 远超均值，导致单分片过载。应对：本地缓存兜底（L1 挡热点）、Key 拆分（加后缀分散到多分片）、读写分离（从节点分担读）。

大 Key：单个 Value 超过 10KB（String）或元素数超过 5000（集合类型）。危害：网络带宽占满、慢查询阻塞、集群迁移超时。应对：拆分为多个小 Key、异步删除（UNLINK）、定期扫描告警。

过期策略：惰性删除 + 定期采样删除是 Redis 默认策略。内存淘汰策略选择：allkeys-lru 适合缓存场景，volatile-ttl 适合混合持久化场景。避免 noeviction 导致写入阻塞。

4.5 分布式锁与限流

Redis 分布式锁：SET NX EX 是基础实现，但存在主从切换丢锁风险。Redlock 算法尝试解决但争议大（Martin Kleppmann vs Antirez 之争）。工程建议：非金融场景用单节点锁 + 合理超时即可，强一致场景用 ZooKeeper 或 etcd。

Lua 原子操作：将判断 + 操作封装为 Lua 脚本，保证原子性。适合库存扣减、计数器、限流等需要 CAS 语义的场景。

限流实现：令牌桶（平滑突发）、滑动窗口（精确计数）、漏桶（恒定速率）。Redis + Lua 实现分布式限流，本地限流用 Guava RateLimiter 或 Resilience4j。