我最近在写一个基于 Spring Boot 的项目，把登录使用 JWT 并把 JWT 存到 Redis 中。有人问： “Redis 和 MySQL 本质上不都是存数据吗？为什么要多学一个软件？MySQL 能不能直接替代 Redis？” 本文将把这些疑问拆开一一回答。

一句话结论

• MySQL：用于主数据（长期、关系型、需要事务、一致性、复杂查询）。

• Redis：用于高速、短期/半长期、频繁读写、需要 TTL / 原子操作 的场景（缓存、会话、计数、分布式锁、队列等）。 两者配合可以兼顾 持久性 与 性能，通常更优于只用其中一个来做所有事情。

为什么“看起来能互相替代”，但实际上不该互相替代

你会觉得“可替代”的原因通常是：任何持久化存储都可以把某些数据写入并读取，所以表面上都能实现某个功能。但从工程角度还要考虑：

1. 性能与延迟

   • Redis 在内存中读写，延迟更低（亚毫秒到毫秒级），适合高并发热数据。

   • MySQL 在磁盘/缓存上，复杂查询或高并发写会更慢且增加 DB 负载。

2. TTL（自动过期）与语义

   • Redis 原生支持 key 的 TTL，非常适合 token、验证码、短期缓存。

   • 在 MySQL 实现 TTL 通常需要额外字段 + 定期清理，复杂且代价高。

3. 并发原子操作

   • Redis 提供很多原子命令（INCR、SET NX PX、Lua 脚本）适合计数、限流、分布式锁。

   • MySQL 也可实现，但代价大、实现复杂。

4. 持久性与事务

   • MySQL 提供 ACID，适合金融类、订单等强一致性场景。

   • Redis 默认内存优先（可配置 RDB/AOF），面临不同的持久化与可用性权衡。

5. 成本

   • 大量长期数据放在 Redis 意味着更高内存成本。MySQL 存储成本更低。

所以：在合适的位置用合适的工具，不是谁更权威而是权衡性能、成本和业务需求的结果。

在我的场景（JWT + 登录）中常见的两种思路及优劣

A. 纯 JWT（不在服务器端存 token）

• 优点：后端无状态，签名验证即可，扩容方便（不需集中式存储 token）。

• 缺点：无法立刻“撤销”某个 token（比如管理员强制登出或发现令牌泄露），只能等 token 自然过期或额外引入黑名单机制。

B. JWT + Redis（白名单/会话存储）

• 做法：在登录时生成 JWT，同时把当前有效 JWT 字符串写入 Redis（key = login:），校验请求时既验证签名也对比 Redis 中的 token 是否一致。

• 优点：实现即时 logout、可控撤销、能在 Redis 上轻松设置过期（记住我 7 天 / 默认 30 分钟）。

• 缺点：增加了 Redis 的依赖（可用性、成本），并造成 token 的双重存储（JWT 自包含 + Redis 白名单），同时要考虑 Redis 不可用时的容错策略。

在多数后台管理系统、需要强制下线或频繁登出控制的系统中，B（JWT+Redis）是常见且合理的选择。

常见问答（FAQ）

Q：JWT 已签名，为什么还要存 Redis？ A：存 Redis 可以实现服务器端的 可撤销、支持“记住我”不同过期策略、并且在需要强制登出或强制踢人时非常方便。若你的系统对“能不能强制下线”没有需求，纯 JWT（不存）也能工作。

Q：Redis 掉线了怎么办？ A：实现降级策略（例如当 Redis 不可用时，仅依靠 JWT 签名校验并做 DB 检查），同时监控 Redis 并报警。关键是设计好在 Redis 不可用时的可接受行为，避免全部拒绝服务。

Q：Redis 会增加成本吗？ A：是的。Redis 是内存数据库，长期大量数据放在 Redis 会增加内存成本。一般把热点/短期/高并发数据放 Redis，长期主数据放 MySQL。

结语

Redis 与 MySQL 各有侧重：MySQL 是你的“权威事实库”，而 Redis 是你的“高速短期记忆”。把两者按照职责分开，既能保证数据可靠性，也能让系统在性能上更灵活可伸缩。