10 篇博文 含有标签「缓存」

RAG 缓存层 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 每次都全链路重跑检索和生成，高频场景的成本和延迟会持续被放大，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

缓存失效策略 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 改了一条数据后不知道该刷新哪个层级，最后只能一股脑全刷，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

Redis 在项目里跑起来之后，缓存命中率看着不错，并不代表系统就稳了。到 2021 年很多内容和后台服务都会碰到两个更现实的问题：某几个 key 被打得特别热，以及 TTL 设得过于随意，导致缓存失效节奏非常难看。

Redis 到了 2021 年，已经不是“可选优化”了。很多 Node.js 服务一旦扛到真实流量，列表读取、热点详情、配置查询这些地方，很自然就会想到把 Redis 接进来。

很多项目第一次接 Redis，都把注意力放在“怎么查得更快”上。但真正在 2021 年做内容或后台服务时，我觉得更应该先想清楚的是 key 设计。因为缓存逻辑可以改，key 一旦遍布代码和运维脚本，后面想统一重构就很难了。

第一次把 LevelDB 用进项目时，很容易被它的简单和直接打动：本地 KV、读写快、嵌入式、不用额外起服务。可也正因为它太像一个“很方便的本地抽屉”，很多人会自然把它当缓存来用，然后默认它应该顺便帮你解决缓存该有的那套问题。

给老 PHP 项目加缓存，表面上看很像一件“性能补丁”工作：慢了就加缓存，数据库忙了就挡一层。
可 2016 年我自己在碰这类改造时，最大的感受不是技术难，而是很多老项目根本没人能完整说清楚数据到底是怎么读出来、又是从哪里被改掉的。

2016 年做接口优化时，缓存几乎是最容易被提起的方案。接口慢了，加缓存；数据库忙了，加缓存；列表页扛不住了，还是加缓存。可真正做过几轮之后，我反而越来越谨慎，因为缓存很少是“开了就完事”的提速按钮。

列表页做缓存，最先想到的写法通常很直接：第一页缓存成一个 key，第二页再来一个 key。
刚开始看完全没问题，可 2014 年我在给后台列表和内容列表做 Redis 缓存时，很快就遇到现实难题：真正决定一页内容的，根本不只是页码。

2014 年前后，Node.js 配 Redis 是很常见的一套轻量组合。大家一开始都觉得 Redis 上手快，set、get 会用就能干活，但真把它放进登录态、验证码、计数器、页面缓存之后，问题很快就来了：key 越堆越多，过期时间各写各的，最后自己都看不懂线上到底存了什么。