Redis 该放在哪一层：个人项目也用得上的缓存分层思路

很多人一提到性能优化，第一反应就是“上 Redis”。但真正落到项目里，问题通常不是要不要用 Redis，而是它到底该放在哪一层、缓存什么、失效策略怎么设计，以及一旦缓存不命中，后面的数据库和接口是否还能稳住。

对中小型项目来说，缓存并不是越多越好。最怕的是刚开始为了追求快，把所有东西都塞进 Redis，结果后面业务一改，缓存逻辑比业务本身还复杂。

先分清楚你要优化的是哪种慢

我一般会先把“慢”拆成三类：

1. 某个接口查询非常频繁，但数据变化不快。
2. 某个页面拼装成本高，需要聚合多次查询。
3. 某些热点数据在短时间内被高频读取。

这三类场景都可以用 Redis，但放置位置并不一样。

第一层：结果缓存

这是最容易理解的一层。比如文章列表、分类导航、热门文章这些内容，不需要每次都从数据库重新查一遍。对于这类数据，直接缓存最终结果最省事。

优点是实现简单，命中后响应速度也很明显。缺点是粒度偏粗，一旦底层数据变化，通常要整体刷新。

适合这层的数据通常有这些特点：

1. 查询频繁。
2. 展示结果固定。
3. 更新频率低于读取频率。

如果你的博客首页每次都要查最新文章、热门文章、标签云，这些就很适合做结果缓存。

第二层：对象缓存

对象缓存的思路是，把单个实体直接缓存下来，比如某篇文章详情、某个用户资料、某个分类信息。这样多个接口都能复用，而不是每个接口各自缓存一份结果。

这一层比结果缓存更灵活，但也更考验缓存键设计和失效策略。因为你要保证：文章更新后，详情缓存、相关推荐缓存、列表页缓存不会互相打架。

我的习惯是把对象缓存作为“中间层”能力，而不是一上来就把所有接口都重构成对象缓存。先从最稳定、最常被读取的实体开始，收益会更高。

第三层：局部聚合缓存

有些页面并不是某一条 SQL 慢，而是要把很多块数据拼起来。例如：

1. 用户中心首页
2. 仪表盘面板
3. 首页推荐区

这类页面特别适合做局部聚合缓存。不是把整个页面硬缓存，而是把“最贵的那几块”缓存掉。这样改动局部模块时，影响面也更小。

设计缓存时更容易忽略的 3 个问题

1. 缓存键没有统一命名

如果不同模块各自拼字符串做 key，后面维护会很乱。我更建议一开始就把命名规范定下来，例如：

article:detail:{id}
article:list:latest
user:profile:{uid}
dashboard:summary:{uid}

命名统一之后，调试、删除、排查热点键都会轻松很多。

2. 只考虑命中，不考虑失效

缓存真正难的不是写进去，而是何时删、谁来删、删不掉怎么办。对个人项目来说，最稳的方式通常是“两条腿走路”：

1. 设置合理的过期时间。
2. 在关键更新动作后主动删除对应缓存。

这样即使主动删除漏了一次，也不至于让脏数据永远留在缓存里。

3. 数据库和缓存没有降级思路

缓存一旦挂掉，系统是不是还能退回数据库查询？如果不能，那 Redis 就从“加速器”变成了“单点”。这一点在个人项目里尤其容易被忽略，因为很多时候测试环境都很顺，真正线上出问题才发现代码默认 Redis 永远可用。

一个更适合个人项目的思路

如果你的网站或接口规模还不大，我更建议这样分层：

1. 先给高频列表做结果缓存。
2. 再给文章详情、用户资料做对象缓存。
3. 最后才考虑复杂页面的聚合缓存。

换句话说，不要一开始就把 Redis 设计成“系统核心”，而应该先把它当作“减少重复查询的工具”。这样你的系统复杂度会可控得多。

结语

Redis 真正的价值，不在于“加上它就更高级”，而在于它能不能准确放到合适的一层。对个人项目来说，缓存设计越克制，后面越容易维护。

先从最明显的热点读场景下手，建立统一的 key 规范和失效策略，再逐步往更复杂的聚合层扩展，这样做出来的缓存体系才是长期可用的。