报表环境回放Go缓存一致性治理与故障处理 - 第4节

4.1 缓存的核心作用与价值

在分布式报表系统中，缓存是提升读取性能、降低后端压力的第一道防线。缓存的核心思想是“用空间换时间”——将频繁访问的数据临时存储在高速存储层，避免每次请求都穿透到数据库或远程服务。

缓存解决的三大问题

4.2 常见缓存策略：LRU 与 TTL

缓存不能无限增长，必须通过淘汰策略控制内存使用。业界最常用的两种策略是 LRU（最近最少使用） 和 TTL（生存时间），实际生产环境通常组合使用。

LRU 淘汰策略

LRU 基于“时间局部性”原理：如果一个数据最近被访问过，那么将来被访问的概率也更高。当缓存满时，淘汰最久未被访问的条目。

• 数据结构：哈希表 + 双向链表（Go 标准库 container/list 可实现）
• 时间复杂度：Get 和 Put 均为 O(1)
• 适用场景：数据访问模式有明显的热点变化，如用户最近查看的报表列表
• 缺点：无法处理“冷数据突发热访问”的抖动场景

TTL 过期策略

TTL 为每个缓存条目设置一个绝对或相对过期时间，到期后自动失效。这是报表缓存中最常用的策略，因为报表数据天然具有时效性。

LRU + TTL 组合策略

生产环境通常将两者结合：先按 TTL 淘汰过期数据，再按 LRU 淘汰最久未使用的数据。这种组合既能保证数据时效性，又能控制内存上限。

// 组合策略伪代码
func (c *Cache) Get(key string) (value interface{}, ok bool) {
    c.mu.RLock()
    entry, exists := c.items[key]
    c.mu.RUnlock()
    if !exists {
        return nil, false
    }
    // 1. 检查 TTL 是否过期
    if time.Now().After(entry.expireAt) {
        c.Delete(key)
        return nil, false
    }
    // 2. 更新 LRU 访问顺序
    c.moveToFront(entry)
    return entry.value, true
}

func (c *Cache) Set(key string, value interface{}, ttl time.Duration) {
    c.mu.Lock()
    defer c.mu.Unlock()
    // 如果缓存已满，淘汰 LRU 尾部
    if len(c.items) >= c.maxSize {
        c.evictLRU()
    }
    entry := &entry{value: value, expireAt: time.Now().Add(ttl)}
    c.items[key] = entry
    c.list.PushFront(entry)
}

4.3 缓存策略对比与选型

下表对比了三种主流缓存策略在报表环境中的表现：

4.4 Go 缓存库选型分析

Go 生态中有多个成熟的缓存库，选型需综合考虑性能、功能、社区活跃度和报表场景适配性。

主流缓存库对比

选型决策流程

1. 单机 vs 分布式：单机选 freecache 或 bigcache；分布式选 groupcache 或 Redis 客户端
2. GC 敏感度：高并发低延迟场景优先 freecache（零 GC 压力）
3. 命中率要求：追求极致命中率选 ristretto（TinyLFU 算法）
4. 报表数据大小：大对象（> 1KB）慎用 bigcache（分片存储小对象更优）

4.5 缓存架构示意

下图展示了报表系统中缓存层的典型架构，以及 LRU + TTL 组合策略在其中的位置：

4.6 缓存一致性基础

缓存一致性是分布式缓存的核心难题。在报表回放场景中，数据源变更后，缓存必须及时失效或更新，否则用户将看到过时的报表数据。

常见一致性问题

• 脏读：数据库已更新，缓存仍返回旧数据
• 缓存穿透：查询不存在的数据，每次穿透到数据库
• 缓存雪崩：大量缓存同时过期，数据库瞬间被打满
• 缓存击穿：热点 key 过期，高并发同时回源数据库