3. 业务接口缓存设计原则

在 Go 项目业务接口落地中，缓存不是“加一层就能快”的简单事。错误的缓存策略会导致数据不一致、内存浪费甚至系统雪崩。本节围绕四个核心原则展开：读多写少、热点数据、数据时效性、缓存粒度，帮助你建立业务接口缓存设计的决策框架。

3.1 原则一：读多写少 —— 缓存收益的基线

缓存只对“读频率远高于写频率”的数据产生正向收益。如果一个接口的读写比接近 1:1，缓存不仅无法提升性能，反而会引入一致性问题与额外的维护成本。

3.2 原则二：热点数据 —— 缓存空间的帕累托法则

缓存空间有限，必须优先覆盖“20% 的数据承载 80% 的请求”的热点数据。全量缓存不仅浪费内存，还会因缓存淘汰导致热点数据被冷数据挤出。

热点识别通常依赖以下指标：

• 访问频率：单位时间内被请求的次数
• 访问集中度：前 N% 的数据占总请求的比例
• 时效窗口：数据在特定时间段内突然升温（如秒杀、大促）

// 热点数据识别示例：基于滑动窗口计数
type HotKeyCounter struct {
    mu       sync.RWMutex
    counters map[string]*windowCounter
    window   time.Duration // 例如 10s
    threshold int64        // 例如 100 次/窗口
}

func (h *HotKeyCounter) IsHot(key string) bool {
    h.mu.RLock()
    defer h.mu.RUnlock()
    if wc, ok := h.counters[key]; ok {
        return wc.Count() > h.threshold
    }
    return false
}

3.3 原则三：数据时效性 —— 一致性窗口的权衡

业务接口对数据“新旧”的容忍度不同，决定了缓存失效策略的选择。时效性要求越严格，缓存设计越复杂。

时效性设计的关键在于明确业务可接受的最大不一致窗口。例如，商品详情页允许 1 分钟内的价格延迟，但下单接口必须读取最新库存。

3.4 原则四：缓存粒度 —— 对象级 vs 列表级

缓存粒度直接影响命中率、存储开销和失效复杂度。最常见的两种粒度是对象级缓存和列表级缓存。

3.4.1 对象级缓存

以单个业务对象为缓存单元，Key 通常为对象 ID。例如 user:1001、order:20240001。

• 优点：命中率高，失效精确，修改某个对象只需删除对应 Key
• 缺点：列表查询需要二次回源，N 条数据可能产生 N 次缓存访问
• 适用场景：详情页、配置项、用户信息等以 ID 为入口的接口

3.4.2 列表级缓存

以查询条件+分页为缓存单元，Value 通常存储 ID 列表或摘要数据。例如 user:list:status:active:page:1。

• 优点：一次缓存返回整页数据，减少回源次数
• 缺点：组合条件导致 Key 爆炸；新增/删除数据时难以精确失效
• 适用场景：首页推荐、文章列表、分类目录等查询条件相对固定的接口

3.5 四原则综合决策矩阵

在实际项目中，四个原则需要联合评估。以下矩阵帮助你在接口设计阶段快速定位缓存策略：

3.6 原则落地检查清单

在 Go 项目代码审查或架构设计评审中，逐条核对以下问题：

1. 读写比验证：是否通过监控数据确认该接口读多写少？
2. 热点覆盖：缓存是否只覆盖了 Top 20% 的热点数据？冷数据是否被排除？
3. 时效性声明：业务方是否明确接受当前 TTL 下的不一致窗口？
4. 粒度合理性：列表级缓存的失效逻辑是否覆盖了新增、删除、更新三种场景？
5. 降级预案：缓存失效或 Redis 宕机时，接口是否能自动降级到数据库直读？