一、先说一句得罪人的话

90% 用若依的人，根本没用清楚 Redis。

我不是在抬杠。
你去问一圈

• Redis 干嘛的？
  「验证码」「Token」
• Redis 挂了怎么办？
  「那就重启一下」
• Redis 里存了啥？
  「不知道，反正框架存的」

这就是现实。

而现实项目里，真正的问题是

• 数据库 CPU 飙 100%
• 接口 3 秒起步
• 一改权限，用户死活不生效
• 半夜 Redis 内存爆了，全站登录失效

然后才开始骂一句：

“若依不行。”

实则不是若依不行，是 Redis 你没搞清楚。

---

二、Redis 在若依里的真实身份

先定一个调子：

Redis 在若依中，不是“加速器”，而是“承压器”。

什么意思？

• 不是为了让你 20ms → 10ms
• 而是为了让数据库别被打死

---

❌ 许多人理解的若依架构

浏览器
  ↓
Controller
  ↓
Service
  ↓
MySQL

并发一上来：

MySQL：我裂开了

---

✅ 若依真实运行时架构

浏览器
  ↓
Filter（Token）
  ↓
Redis（权限 / 用户）
  ↓
Controller
  ↓
Service
  ↓
MySQL

Redis 是“第一道拦截层”

---

【配图｜请求链路图】

---

三、一次请求，到底“命中”了多少 Redis？

我们不抽象，直接按若依源码逻辑走一遍。

请求：

GET /system/user/list

真实执行流程（精简版）

1️⃣ 前端带 Token
2️⃣ TokenFilter 拦截
3️⃣ Redis 取 LoginUser
4️⃣ Redis 取权限集合
5️⃣ Redis 取菜单缓存
6️⃣ 执行业务 SQL

数据库只负责最后一步

---

❗ 如果没 Redis，会发生什么？

• 每个接口
• 每次请求
• 都查用户、查角色、查权限

结果：

数据库直接当缓存用

---

四、若依 Redis 里到底存了哪些“核心数据”？

下面这部分很关键，提议你对着 Redis 客户端一条条看。

---

1️⃣ 登录 Token（灵魂中的灵魂）

Key 形式：

login_tokens:UUID

值是什么？

不是字符串，是 LoginUser 对象

里面包含

• 用户 ID
• 用户名
• 部门
• 角色
• 权限集合
• 登录时间
• 过期时间

结论一句话：

Token 只是钥匙，Redis 里才是“人”。

---

【配图｜Token 生命周期】

---

2️⃣ 权限缓存（若依能不能抗并发的关键）

Key：

sys-permission:userId

存的是什么？

[
  "system:user:add",
  "system:user:edit",
  "system:dept:view"
]

为什么必定要缓存？

由于每一个接口请求
都要做一次权限校验。

没 Redis：

• 每个请求查 4～5 张表
• 接口时间直接翻倍

---

3️⃣ 菜单缓存（前端不卡的秘密）

Key：

sys-menu:userId

内容：

• 菜单树
• 路由结构

否则：

刷新页面 = 查数据库 + 递归组树
前端：转圈圈

---

4️⃣ 字典 & 系统配置（被低估的缓存）

Key：

sys_dict:type
sys_config:key

特点：

• 改得少
• 查得多
• 超级适合 Redis

---

五、为什么若依 Redis Key 都带前缀？

你可能觉得这是小事。

但我告知你：

这是运维友善型设计。

正确示范：

login_tokens:
sys-permission:
sys-menu:

好处：

• 一键清理某类缓存
• 不误删
• 出问题好定位

---

❌ 新手最爱写的 Key

user:1
data:xxx
temp:yyy

半年后你自己都不敢 FLUSHDB。

---

⏳ 六、若依 Token 过期，是怎么“悄悄续命”的？

许多人以为：

Token 到期 → 强制下线

错。

若依里有一段超级关键的逻辑：

if (token即将过期 && 用户仍在访问) {
    自动延长 Redis TTL
}

这意味着：

• 活跃用户不会被踢
• Redis 既安全又友善

---

七、真实项目里的 5 个 Redis 翻车现场

翻车 1：权限改了，用户没反应

缘由：

Redis 里还是旧权限

解决：

redisCache.deleteObject("sys-permission:" + userId);

---

翻车 2：Redis 内存越跑越大

新手常见写法：

redisCache.set(key, value);

没设过期时间。

若依推荐：

redisCache.setCacheObject(key, value, 30, TimeUnit.MINUTES);

---

翻车 3：Redis 挂了，全站登录失效

成熟系统应该：

• Redis 异常
• 自动走数据库
• 性能下降，但功能可用

若依就是这么干的。

---

翻车 4：一清缓存，全员下线

缘由：

不分 Key，直接 FLUSHALL

正确姿势：

• 只清业务 Key
• Token Key 慎动

---

翻车 5：缓存命中率低得离谱

缘由：

• Key 设计混乱
• 数据粒度不合理

Redis 不是“啥都塞”。

---

八、你在项目里，怎么“像若依一样用 Redis”？

✅ 强烈提议缓存的

• 登录态
• 权限
• 菜单
• 字典
• 系统参数

❌ 不提议缓存的

• 实时流水
• 强一致账务
• 超大对象

---

九、Redis 不是银弹，但不用必定是坑

说一句很现实的话：

Redis 用对了，是“救命稻草”
用错了，是“定时炸弹”

若依的价值就在于

• 给了你一套成熟模板
• 你照着用，少踩 80% 的坑

---

终极总结（适合收藏）

Redis 在若依里不是可选项，是必选项
缓存不是为了快，是为了系统活得久
真正的高手，敢删缓存也不慌

---

给你一句掏心窝子的结尾

当你真正看懂若依 Redis 这一套：

• Key 设计
• 缓存边界
• 失效策略
• 容灾思路

你已经不是“用框架的人”，
而是**“理解框架的人”**。