副标题 / 摘要

缓存大小不是拍脑袋，而是命中率、成本与稳定性之间的平衡。本文给出确定缓存大小的工程方法。

目标读者

  • 负责缓存系统和性能优化的工程师
  • 做容量规划与成本控制的团队
  • 需要提升命中率与稳定性的开发者

背景 / 动机

缓存太小会导致频繁穿透，太大则成本高且失效风险增加。
正确做法是用数据驱动的方式确定缓存大小。

核心概念

  • 命中率（Hit Rate）：缓存命中 / 总请求
  • 工作集（Working Set）：短期内频繁访问的数据集合
  • 淘汰策略：LRU/LFU 等
  • 成本曲线：边际命中率收益逐渐降低

实践指南 / 步骤

  1. 采集访问分布（热度、访问频率）
  2. 估算工作集大小
  3. 用不同容量做离线回放
  4. 评估命中率与成本曲线
  5. 预留安全余量（波峰期、突发流量）

可运行示例

下面模拟不同缓存容量的命中率：

from collections import OrderedDict


def lru_hit_rate(requests, capacity):
    cache = OrderedDict()
    hits = 0
    for key in requests:
        if key in cache:
            hits += 1
            cache.move_to_end(key)
        else:
            if len(cache) >= capacity:
                cache.popitem(last=False)
            cache[key] = True
    return hits / len(requests)


if __name__ == "__main__":
    reqs = [1,2,3,1,2,4,1,2,3,5,1,2,3,4]
    for cap in [1, 2, 3, 4]:
        print(cap, lru_hit_rate(reqs, cap))

解释与原理

缓存大小的收益是递减的：容量越大，新增命中率提升越小。
因此需要找到“边际收益开始下降”的拐点，而不是盲目扩容。

常见问题与注意事项

  1. 命中率越高越好？
    不一定，可能换来过高成本或更复杂的失效管理。

  2. 缓存会不会导致一致性问题？
    会，需要明确失效策略与更新路径。

  3. 只靠 LRU 足够吗？
    取决于访问分布，热点不稳定时需更复杂策略。

最佳实践与建议

  • 用离线回放或仿真确定容量
  • 结合成本和 SLA 做综合决策
  • 关注尾部延迟与缓存穿透

小结 / 结论

缓存大小的确定必须建立在访问数据与成本曲线上。
用数据驱动，才能避免“拍脑袋扩容”。

参考与延伸阅读

  • Cache replacement policies (LRU/LFU)
  • CDN 缓存策略与容量规划
  • Redis 官方性能调优文档

元信息

  • 阅读时长：7~9 分钟
  • 标签：缓存、性能、容量规划
  • SEO 关键词：缓存大小, 命中率, LRU
  • 元描述：给出确定缓存大小的工程方法与示例。

行动号召（CTA）

找一段真实请求日志，跑一次离线回放，你会更清楚缓存该多大。