开发过程中，经常会听到一些话：“这个放 Redis 里”“Redis 缓存过期了”“给这个接口加个 Redis 锁”。
Redis 到底是什么？它为什么会频繁出现在后端系统里？
一、Redis 是什么？
Redis（最初是 Remote Dictionary Server）是一个以内存为主要工作空间的高性能数据存储系统。 它可以存储字符串、列表、集合、哈希等多种结构，常用来做缓存、临时状态管理、限流和服务间协调。
可以把一个系统想成餐厅：
- MySQL 像仓库：负责存放需要长期管理的食材和记录。
- Redis 像厨房旁边的备菜台：把常用的东西提前放好，随取随用。
- 后端服务 像厨师：根据用户请求处理业务。
每次都去仓库拿东西当然可以，但如果同一份信息被反复查询，就没有必要每次都跑一趟。
Redis 的一个典型价值，就是让系统不用反复访问较慢的数据源，也能快速拿到需要的信息。
二、有了 MySQL，为什么还需要 Redis？
区别首先在存储方式。
| 对比 | MySQL | Redis |
|---|---|---|
| 主要角色 | 关系型数据库 | 内存优先的数据存储系统 |
| 数据组织 | 表、行、列 | Key-Value 和多种数据结构 |
| 访问特点 | 擅长复杂查询和可靠的业务数据管理 | 擅长低延迟、高频访问 |
| 常见用途 | 用户、订单、对话记录等持久化数据 | 缓存、会话状态、计数、限流、锁 |
| 持久化 | 支持 | 也支持 RDB、AOF，取决于配置 |
注意：Redis 不是“只能临时存数据”，它也可以持久化；MySQL 也不是“所有查询都慢”。两者的选择取决于数据特点、访问模式和业务可靠性要求。
举个例子：用户进入 AI 平台的智能体广场，系统要获取推荐智能体列表。
用户打开智能体广场
↓
后端先查询 Redis
↓
┌────找到────┐
│ │
直接返回 没找到
↓
查询 MySQL
↓
写入 Redis
↓
返回用户第一次查询可能需要访问 MySQL，后续查询就可以命中 Redis。这就是常见的**缓存（Cache）**模式。
为了避免一直显示旧数据，开发还会设置 TTL（Time To Live，生存时间）。例如：
Key: agent:recommend:list
Value: 推荐智能体列表
TTL: 3600 秒这表示缓存有效期为一小时。业务数据更新时，也可以主动刷新或删除缓存，而不必非等到过期。
三、在 AI 产品中，Redis 具体能干什么？
1. 缓存：让高频查询更快
用户信息、智能体配置、常用列表等可能被大量重复读取。缓存能减少数据库压力、缩短响应时间。
但缓存也有代价：数据库已经更新，Redis 里却还是旧值。所以产品遇到“修改成功但页面没变化”，除了前端问题，也要考虑缓存一致性。
2. Session：保存临时会话状态
系统可能需要临时记录用户登录状态、当前操作状态、任务进度等。例如：
{
"key": "session:123456",
"user_id": "10001",
"status": "active",
"current_conversation": "abc123"
}这些信息可以放在 Redis 中，并设置适当的有效期。
需要区分：Session 状态不等于完整的聊天历史。长期保留的对话消息通常还要放在数据库等持久化存储中。
3. 限流：避免请求过于频繁
大模型 API 每次调用都可能产生费用。假设产品规定“每个用户一分钟最多发起 20 次请求”，Redis 可以帮助记录请求次数，并配合限流算法判断是否放行。
它不仅能保护服务，也能控制资源消耗；具体实现要确保并发下的计数准确。
4. 分布式锁：协调重复任务
假设用户上传 PDF，后端调用 MinerU 解析。同一个文件因重复点击或网络重试触发了多个请求，可能出现多次重复解析。
开发可以通过 Redis 锁协调任务：一个任务已在执行时，其他请求不再重复启动相同工作。
但锁不等于绝对不会重复执行。生产系统通常还需要幂等设计、任务状态持久化和异常恢复机制。
四、开发提到这些 Redis 问题，到底是什么意思？
| 开发术语 | 通俗解释 |
|---|---|
| 缓存命中 / 未命中 | Redis 有 / 没有找到需要的数据 |
| TTL 过期 | 数据超过设定的有效期 |
| 清缓存 | 删除或更新部分缓存，让后续读取新数据 |
| 缓存不一致 | Redis 与数据库保存的内容不同步 |
| Redis 连接失败 | 后端暂时无法访问 Redis |
| Redis 内存满了 | 达到内存上限，可能影响写入或触发淘汰 |
| Redis 锁没释放 | 某项操作的锁仍被占用，可能阻塞其他任务 |
| 缓存击穿 | 某个热点数据失效时，大量请求同时访问后端数据源 |
对产品经理来说，最值得关心的不是 Redis 的具体命令，而是两个问题：
第一，Redis 在这个功能里负责什么？ 是加速查询、保存临时状态，还是协调任务？
第二，如果 Redis 出问题，用户会遇到什么？ 是页面变慢、需要重新登录，还是任务无法执行？
不同用途对应不同的产品风险，是否有降级、重试和恢复机制，决定了故障对用户的实际影响。
一句话总结：MySQL 擅长可靠地保存和管理业务数据，Redis 擅长快速访问数据、管理临时状态，并协调服务。它们不是替代关系，而是互补关系。
下一步可以把 MySQL、Redis 和 MQ（消息队列） 放在一起理解。看懂这三个组件的分工，就能看懂很多 AI 产品的后端架构。