技术精进

系统QPS跌了80%？从这三个缓存“反常识”找原因

两年前的一个周五下午，正是我们电商大促前的最后一次压测。运维兄弟突然指着监控屏幕喊：“不对劲，Redis响应时间飙升，但CPU利用率才15%！”

当时我的第一反应是：不可能。我们在核心链路上全加了缓存，理论上数据库的压力应该被卸掉才对。

排查了整整两小时，结果却打了我一记响亮的耳光：导致系统吞吐量（QPS）暴跌的罪魁祸首，竟然就是我们引以为傲的“全量缓存策略”。这次事故让我彻底明白，缓存不是简单的 get/set，很多时候，我们以为的“万金油”设计，在流量洪峰下往往是致命的毒药。

这也是我在中小团队做架构评审时，最常看到的三个关于缓存粒度与更新策略的误区。

一、 贪大求全？“胖缓存”正在吃掉你的网络带宽

很多资深开发在做缓存设计时，习惯直接把数据库里的实体对象（Entity/PO）序列化后塞进 Redis。理由听起来很充分：“反正以后可能要用，一次存全了，省得以后改代码。”

配图

这在数据量小时没问题，但在高并发场景下，这就是一颗定时炸弹。

真实案例： 那个让压测崩溃的场景是“商品详情页”。我们的开发同学为了图省事，把商品的基础信息、几十张详情图的URL、甚至还有针对不同等级用户的优惠规则，全部打包成一个 ProductDetail 对象存入缓存，单个 Key 的 Value 大小接近 50KB。

结果： 当 QPS 达到 2万时，Redis 的出入口带宽瞬间被打满（50KB * 20,000 = 1GB/s）。这就是为什么 CPU 没满，但请求却堵死的原因——千兆网卡撑不住了。

改进方案：缓存切分（Slicing） 我后来强推了“按需缓存”策略，将那个巨大的 Key 拆成了三个维度的粒度：

  1. 基础信息（极少变动）： prod:base:{id}（标题、主图），大小仅 1KB。
  2. 详情富文本（大且低频）： prod:desc:{id}，独立存储，且前端懒加载（点击“查看详情”才请求）。
  3. 实时状态（高频变动）： prod:state:{id}（库存、价格），大小仅 100 Bytes。

代码逻辑变更：

// ❌ 错误示范：一把梭全量获取
ProductDetail detail = redis.get("product:" + id);

![配图](https://picsum.photos/800/450?random=1768531642930)

// ✅ 优化后：按需组装，动静分离
ProductBase base = redis.get("prod:base:" + id);
// 库存单独获取，且TTL设置更短
Integer stock = redis.get("prod:state:" + id);

效果： 重构后，核心接口的平均响应包大小从 50KB 降至 2KB，在同等硬件配置下，QPS 提升了 20 倍。

二、 强一致性的执念：中小团队的架构陷阱

“先更数据库还是先删缓存？”、“要不要上 Canal 做订阅更新？” 这是我面试候选人时听到最多的讨论。但我发现，90% 的中小项目根本不需要复杂的“最终一致性”方案，过度追求一致性，往往牺牲了系统的可用性和开发效率。

真实案例： 我们曾有一个 CMS 内容管理系统，架构师设计了一套复杂的“双删策略”配合消息队列重试，确保编辑修改文章后，前端缓存立即更新。结果因为消息队列积压，导致文章发出去 10 分钟了前台还刷不出来，运营部门直接炸锅。

反思与修正： 我们冷静下来分析了业务场景：用户真的在乎这 5 秒钟的延迟吗？对于绝大多数非交易类场景（如文章、配置、列表），短暂的不一致是完全可接受的。

我现在的实操建议：

  1. 拥抱 TTL（过期时间）： 给所有缓存加上过期时间，这是最兜底的“一致性”保障。
  2. Cache Aside（旁路缓存）简化版： 修改数据 -> 提交事务 -> 事务成功后尝试删除缓存。
  3. 容忍失败： 如果删除缓存失败了怎么办？对于中小项目，不要为了 0.01% 的失败概率引入重型的重试中间件。依赖 TTL 自动过期即可。

“在分布式系统中，试图用同步思维解决一致性问题，通常是灾难的开始。”

除非涉及金钱交易（余额、库存），否则请大胆地告诉业务方：“数据会有 30 秒以内的延迟”，这能为你省下几十万的架构维护成本。

三、 更新频率失控：被忽视的“热点写”

缓存粒度不仅指“存了多少数据”，还包括“更新了多大范围”。

真实案例： 我们有一个“热榜”功能，每当有用户点击，榜单分数就会变化。起初，开发人员每有一个点击，就去更新一次缓存中那个包含 Top 100 数据的 List。

结果： Redis 的写操作飙升。更要命的是，每次更新都要序列化/反序列化整个 List，导致 Redis 频繁进行内存分配。

方法论：数据离散化与聚合更新

针对这种高频写的场景，我们采用了两种策略组合：

  1. 写离散： 比如库存扣减，不要锁住整个商品记录，而是单独对 stock 字段进行 decr 操作（Redis 原子递减）。
  2. 读聚合（Buffer）： 对于热榜，我们不再实时更新 List。而是每分钟由定时任务从数据库或计算引擎拉取一次 Top 100，覆盖写入 Redis。

实操对比：

策略 实时性 Redis压力 适用场景
实时回写 毫秒级 极高 (Write heavy) 强一致性要求 (如抢票)
定时聚合 分钟级 低 (Read heavy) 排行榜、推荐列表

对于中小团队，如果业务允许，定时刷新（Refresh-Ahead） 往往比 被动失效（Write-Through/Cache-Aside） 更能保护数据库。

结语：架构是取舍的艺术

回顾这几年踩过的坑，我逐渐形成了一个极简的缓存设计检查清单（Checklist），每当周四代码评审（Code Review）时，我都会拿着它问团队成员：

  1. 你的 Value 真的需要这么大吗？ 能不能只存 ID 或者核心字段？
  2. 这个数据真的需要实时一致吗？ 加上 60秒 的 TTL 会死人吗？
  3. 如果是列表缓存， 只有第 1 页需要缓存，还是所有分页都要缓存？（通常建议只存前 3 页）

落地行动指南：

  • 本周行动： 检查你 Redis 中 Memory 占用最高的 Top 10 Key（使用 redis-cli --bigkeys），分析其中是否混入了不必要的字段。
  • 下周计划： 找出系统中更新最频繁的缓存，评估是否可以降级为“定时刷新”模式。

开放讨论： 你在项目中是否遇到过“缓存穿透”或者“缓存雪崩”导致数据库被打挂的经历？当时你们是如何快速止损的？欢迎在评论区分享你的“救火”故事。

© 2026 SelfTechHub