周五晚上十一点四十，阿杰盯着监控大盘发呆。

P99 从 80ms 飙到 4 秒。流量没涨，曲线平得像一条直线——问题不在流量，在他那个"很优雅"的设计上。

订单状态、用户画像、商品标签，他全塞进了 Redis；为了"数据绝对不丢"，他还专门开了 AOF 持久化。

老陈端着咖啡路过，扫了一眼他的架构图。

「我开了 AOF，不会丢的。」阿杰说得挺有底气。

「正因为你开了 AOF，你才更危险。」老陈拉开椅子坐下，「你把两个本来该分开的东西，塞进了一个组件里。」

小迪从旁边探过头来：「杰哥，开持久化不是好事吗？数据不丢，不是很稳吗？」

「稳不稳，得看它是在给谁服务。」老陈说，「你先想想，Redis 这东西，到底是存储，还是缓存。」

一、Redis 的持久化，不该成为你的存储方案

阿杰的架构里，Redis 同时扮演了两个角色：缓存和数据库。

第一，健壮性根本撑不起"存储"这两个字。

Redis 的持久化在各种故障场景下极易丢数据：异步复制在主库宕机时丢掉一批没同步过去的写入；AOF 的 everysec 策略本身就允许丢秒级的数据；主从切换的那一瞬间，还没来得及复制的写入直接蒸发。RDB 更直接，它就是某个时间点的快照。

这些机制设计出来，是为了"重启后缓存能快速恢复、不至于全冷"，不是为了"一条都不能丢"。拿这种不健壮的持久化当存储组件用，是极度危险的。

第二，开了持久化，性能会掉一个档次。

持久化不是免费的：fsync、AOF rewrite、fork 子进程，这些开销在 Redis 单线程处理命令的模型下，会造成明显的延迟抖动。写放大、重写期间的内存翻倍，一个都跑不掉。

结果就是：你为了"不丢数据"开了持久化，Redis 的吞吐和延迟都退化了。而它退化之后的性能，作为缓存已经没有太好的优势——除非你再单独起一组不开持久化的缓存节点，那你的架构就又多了一套东西要维护。

第三，存储必须要有明确的格式定义，而 Redis 恰恰鼓励你不定义。

这是最容易被忽视、但最要命的一条。

很多人在用 Redis 存数据时，存法是五花八门的：用 Hash 存对象、用 RedisJSON 存文档、或者干脆把一个 JSON 字符串塞进某个 key 的 value 里。

从工程管理的角度看，这是灾难——数据被隐性地藏在了 Redis 里，藏的规则又散落在各处代码里。整个项目的数据字典没法统一管理，数仓团队要拉数据时，得先问你三个问题：这个 key 是什么格式？那个 Hash 的 field 有哪些？谁写的？什么时候写的？

对数据治理团队来说，这叫极度不友好。

第四，业务一旦复杂，Redis 的存储能力就是个笑话。

多表关联？痛苦。按任意条件查询？痛苦。跨 key 的事务？基本没有。

这些东西数据库花了几十年才磨出来，你指望用一堆 Hash 和字符串去替代它，注定会在某个业务迭代的深水区翻车。

所以老陈的结论很干脆：不要用 Redis 的持久化，不要把 Redis 当存储来用，就把 Redis 当缓存用。

聚焦做缓存，也就在字段类型上聚焦——用那些简单的就行。

「杰哥，那 Redis 那么多字段类型，不就白设计了？」小迪问。

「不是白设计，是那些东西不属于'缓存'这个场景。」老陈说，「工具什么都想做，你就得自己知道该拿它做什么。」

二、缓存在架构里到底是什么定位

想清楚怎么用缓存，先得想清楚缓存是什么。

拿浏览器缓存打个比方：浏览器不缓存，页面就打不开吗？当然不是，只是慢一点。

所以判断一个架构是否健康，有个很朴素的检验方式：

当 Redis 从线上摘除，系统会出问题吗？

如果会，那你的问题不是缓存没做好，是你把缓存当成了关键路径上的依赖。

正确的状态是：缓存有则加速，没有也正常请求，只是压力大一些。

这句话听起来像废话，但它直接决定了后面所有的设计选择。

围绕"缓存非必要"这个原则，最简的设计长这样：

if 缓存在:
    用缓存返回
else:
    执行逻辑
    把结果放入缓存
    返回


简单、直接，能覆盖绝大多数读多写少的场景。

四、高并发下，缓存失效的那一瞬间

高并发的流量下，缓存失效（或者冷启动缓存为空）的那一刹那，会有大量请求同时走进执行逻辑那一段。

而这段逻辑之所以需要缓存，往往是因为它性能低——慢查询、复杂聚合、远程调用。

于是，几百个请求同时压上那条慢路径，数据库瞬间被打穿。这就是缓存击穿。

二级缓存 + 冷启动时的多余请求作废逻辑。

if 一级缓存在:
    用一级缓存返回
elif 加锁成功:
    执行逻辑
    结果写入一级缓存 + 二级缓存
    解锁
    返回
else:
    加锁失败 —— 说明已经有人在加载了
    读二级缓存
    if 二级缓存有:
        用二级缓存返回
    else:
        不执行逻辑了，直接宣告本次查询失败


二级缓存的过期时间通常要大于一级缓存，比如设成一级缓存的两倍。这样一级缓存失效时，二级缓存还没到过期时间，正好能顶住那波瞬时流量。

小迪举手：「所以二级缓存就是给一级缓存当备胎的？」

「对，但它是个有保质期的备胎。」老陈说，「它存在的时间窗口，刚好够一级缓存重新加载一遍。」

五、严格执行缓存定位之后，扩缩容其实非常简单

这一部分，是"把 Redis 只当缓存"带来的最大红利。

先说不用的方案：官方给的 Redis Cluster，在缓存场景里我们基本不考虑。太龟毛、太严谨、也太慢——它的槽位迁移、故障判定、一致性保证，都是为"数据不能丢"这个前提服务的。

但缓存场景里，我们本来就接受缓存的局部短时失效。

hash 分片 + 每个分片做一组主从。

没有复杂的槽位概念，路由规则一句话能说清：

压力大了怎么办？翻倍加节点。原本 4 个节点，直接加到 8 个，单节点压力降一半。

好计算、好运维，不需要迁移数据，也不需要协调者。

代价是：扩容那一瞬间，取模结果变了，大约 50% 的缓存会瞬时失效。

如果担心 50% 的瞬时失效率影响用户体验，可以做一个

这样一级缓存瞬间失效掉 50% 的时候，过期时间更长、还没被切换的二级缓存能临时顶住，而穿透过去的请求会走进缓存加载逻辑，顺手把一级缓存重新填满。

等二级缓存再切换，系统已经在新的分片结构上跑稳了。

「所以那个二级缓存，不光是防击穿的，还是扩容的缓冲垫。」阿杰说。

「同一个设计，同时解决两个问题。」老陈把咖啡喝完，「这才是好的架构设计——不是堆组件，是让一个机制承担多个职责。」

Redis 是一个简单好用的缓存组件。

在实战中，不要被它花里胡哨的字段类型和高可用解决方案所诱惑。

任何一个工具，都想把自己做成万能。但"万能"也就意味着，任何一个工具身上，既有精华，也有糟粕。

做为架构师，一定要能理性分辨，并且用精华、去糟粕。

Redis 的精华是什么？是高吞吐的内存读写、简单直接的 key-value 语义、以及极低的使用心智负担。

把这三样用好，你的架构就赢了。剩下的那些，留给真正需要它们的地方。

Redis 只是个缓存：老陈让我关掉 AOF，也把 Hash 和 RedisJSON 全删了

阿杰为了「数据不丢」给 Redis 开了 AOF，还把订单、画像、标签全塞进 Hash 和 JSON 里，直到 P99 从 80ms 飙到 4 秒。老陈一句话点破：你在拿缓存当数据库用。本文讲清 Redis 该只用哪一部分、缓存的真实定位、最简缓存设计、二级缓存防击穿，以及为什么 hash 分片比官方 Cluster 更好用。

数据库

后端

架构设计

缓存非必要，摘除Redis系统应照常运转。避免用持久化当存储，AOF/快照机制会丢数据且拖累性能。采用二级缓存+锁回填防击穿：抢锁者写双级缓存，失败者读二级缓存，过期时间设为两倍。hash分片扩缩容只需翻倍节点数，分阶段切换两级缓存容忍瞬时失效，一个机制兼顾防穿透与扩容缓冲。

数据治理

路由

Redis

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Redis 只是个缓存：老陈让我关掉 AOF，也把 Hash 和 RedisJSON 全删了

Redis 只是个缓存：老陈让我关掉 AOF，也把 Hash 和 RedisJSON 全删了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐