---
tags: [redis, multi-level-cache, caffeine, cache-consistency, avalanche]
create time: 2026-08-08 18:43
update time: 2026-08-08 18:43
---

# 多级缓存架构设计

## 概述

在大型分布式系统中，仅靠 Redis 单级缓存已不足以支撑超高并发场景。多级缓存通过在客户端本地（L1）和远程服务（L2）之间分层存储热点数据，大幅降低远程调用延迟和网络带宽消耗。本文介绍 Caffeine 到 Redis 到 MySQL 的三级架构设计及一致性、雪崩等核心挑战的解决方案。

## 核心原理

### 三级缓存层次

```mermaid
graph LR
    A["应用服务 App Service"] -->|"L1: Caffeine<br/>内存缓存 (微秒)"| B["应用服务 App Service"]
    B -->|"L2: Redis<br/>远程缓存 (毫秒)"| C["MySQL<br/>持久化存储"]
    A -->|"miss"| B
    B -->|"miss"| C
```

**L1 — Caffeine（本地缓存）**：
- 基于 JVM 堆内内存，读写延迟小于 1 微秒
- 支持 LRU、LFU、Window LFU 多种淘汰算法
- 通过 maximumSize 限制内存占用，自动驱逐过期条目
- 局限：多实例间数据无法同步，每个实例有自己的缓存视图

**L2 — Redis（远程缓存）**：
- 集中式共享缓存，所有实例共享同一份数据
- 网络 RTT 通常在 1~5ms（同城）到 50ms+（跨城）
- 支持 TTL、持久化、复杂数据结构

**L3 — MySQL（持久层）**：
- 最终数据来源，保证数据的持久性和强一致性
- 查询延迟通常 10ms~数百 ms

### 缓存一致性挑战

多级缓存最大的痛点是数据更新时如何让所有层的缓存保持一致。

```mermaid
sequenceDiagram
    participant Writer as 写请求
    participant DB as MySQL
    participant Redis as L2: Redis
    participant App1 as 实例A (L1)
    participant App2 as 实例B (L1)

    Writer->>DB: UPDATE key = val
    DB-->>Writer: OK
    Writer->>Redis: DEL key
    Redis-->>Writer: OK
    
    Note over App1,App2: 注意：此处只删除了 Redis<br/>L1 缓存需要下次访问时刷新
    
    App1->>Redis: GET key (miss)
    Redis->>DB: SELECT * FROM ...
    DB-->>Redis: result
    Redis->>App1: result
    App1->>App1: 写入 L1 Caffeine
```

> [!TIP]
> 最实用的策略是先删缓存再更新 DB（或先更新 DB 再删缓存）。推荐先更新 DB 再删缓存因为后一种情况下极端竞态（读请求在新旧值切换期间读到旧值并回写到缓存）的概率更低。绝不使用先删缓存再写 DB——那会导致写操作完成后、DB 写入前的窗口期内读请求拿到陈旧缓存。

### 二级缓存失效传播方案

当多个应用实例同时修改同一个 key 时，可能出现两个问题：
1. **重复重建**：多个实例同时发现缓存缺失，各自去查 DB 并重写缓存
2. **脏数据残留**：L1 缓存不知道 L2 已经被删除

解决策略：

| 方案 | 做法 | 优缺点 |
|------|-----|--------|
| **短 TTL + 异步刷新** | 给缓存设置随机短 TTL（如 5~15min），后台线程提前 2min 刷新 | 简单有效，容忍短暂不一致 |
| **消息队列广播** | DB 更新后发 MQ，各实例监听后清除自己的 L1 | 实时性好，但增加系统复杂度 |
| **Canal + binlog 监听** | 通过 Canal 解析 MySQL binlog，自动推送 invalidate 事件 | 解耦彻底，适合大规模部署 |

> [!WARNING]
> 不要依赖定时扫描比对来做一致性校验——延迟太高且成本高。生产环境首选方案：MQ 或 binlog 监听加短 TTL 兜底。

### 过期时间随机化防雪崩

大量缓存同时过期会导致请求瞬间穿透到数据库，引发雪崩。解决方法是在 TTL 基础上加上随机偏移量：

```go
import "math/rand"

func generateTTL(baseMinutes int, jitterPercent int) time.Duration {
    jitter := baseMinutes * jitterPercent / 100
    actualMinutes := baseMinutes - jitter + rand.Intn(2*jitter)
    return time.Duration(actualMinutes) * time.Minute
}

// 例如 baseMinutes=10, jitterPercent=30
// 实际 TTL 落在 [7, 13] 分钟之间均匀分布
```

### 缓存穿透防护

场景：恶意用户或异常流量反复查询不存在的 key，绕过缓存直接打到 DB。

防护策略：

| 策略 | 做法 | 适用场景 |
|------|-----|---------|
| **空值缓存** | 查询结果为空时也缓存一个特殊标记（如 nil），设极短 TTL（30s~2min） | 适用于不存在的数据比例较低的场景 |
| **布隆过滤器** | 在缓存前先用 Bloom Filter 判断 key 是否存在 | 适用于 key 集合相对稳定、允许误判的场景 |
| **接口层鉴权限流** | 对高频无效查询做 IP 或 token 级别的限流 | 作为辅助防线 |

## 代码示例

Go 中用 singleflight 防止缓存击穿：

```go
import "golang.org/x/sync/singleflight"

type Cache struct {
    group singleflight.Group
    mu    sync.RWMutex
    local map[string]cache.Entry
}

func (c *Cache) Get(ctx context.Context, key string,
    fn func() (interface{}, error)) (interface{}, error) {
    
    // 1. L1 命中直接返回
    c.mu.RLock()
    if entry, ok := c.local[key]; ok && !entry.IsExpired() {
        c.mu.RUnlock()
        return entry.Value, nil
    }
    c.mu.RUnlock()
    
    // 2. L1 miss + L2 miss → singleflight 阻止并发重复查 DB
    val, err, _ := c.group.Do(key, func() (interface{}, error) {
        val, err := redisGet(ctx, key)
        if err != nil {
            val, err = fn() // 查 DB
            if err == nil {
                redisSetWithTTL(ctx, key, val, generateTTL(10, 30))
                c.setLocal(key, val, 15*time.Minute)
            }
        }
        return val, err
    })
    return val, err
}
```

## 实践场景

1. **商品详情页缓存**：电商商品 SKU 信息变更频率低（小时级）、读请求极高（万 QPS），非常适合多级缓存。L1 存热点 SKU，L2 存全量活跃 SKU，DB 做兜底。

2. **配置中心类数据**：开关配置、规则引擎参数等全局配置，更新时通过 MQ 广播失效，L1 TTL 设 1 小时加后台预刷。

3. **限流计数**：高频调用的限流 counter 不适合放多级缓存（每次都涉及网络开销），直接用 Redis INCR 或本地原子计数器即可。

4. **容量规划参考**：假设单机 QPS 10000，L1 hit rate 90%，L2 hit rate 80%（相对 L1 miss），则对外部 Redis 的请求约 1000 × (1 - 0.8) = 200 QPS。这是评估集群规模的核心指标。

## 关联笔记

- [[03.Redis/core/Redis 五大核心数据结构]]
- [[03.Redis/strategies/缓存穿透击穿雪崩解决方案]]
- [[03.Redis/strategies/HeavyKeeper 热点探测算法]]