Redis 入门：为什么系统需要 Redis（一）
系列导航：
- 当前篇：Redis 入门：为什么系统需要 Redis（一）（本文）
- 下一篇：Redis 核心模型：键、内存、单线程与性能边界（二）
很多团队第一次接触 Redis，并不是因为“想学一个新中间件”，而是因为现有系统已经开始出现几个很现实的问题：数据库顶不住热点读，接口响应越来越慢，同一份数据被反复计算，主流程里还混进了大量本可以延后处理的工作。
这时 Redis 才会进入候选名单。它的价值不是“单纯更快”，而是给系统提供一层低延迟、以内存为主、按 Key 访问的数据能力，让原本必须每次都回源数据库或重新计算的操作，有了更短的路径。
本文只回答三个问题：
- 为什么系统会需要 Redis。
- Redis 适合承担什么职责，不适合承担什么职责。
- 这个系列接下来 13 篇会分别展开哪些主题。
为什么系统会需要 Redis
当系统规模还小的时候，应用直接访问数据库往往已经够用。问题通常出现在业务继续增长之后。
1. 热点读开始反复打数据库
商品详情、用户资料、配置、排行榜片段、首页聚合结果，往往会被高频读取，但更新频率并没有那么高。如果每次请求都回源数据库，数据库会承担大量重复读取，而这些读取并不总是值得付出完整查询成本。
Redis 最常见的第一价值，就是把这类热点数据放到更近的一层，让系统先在低延迟路径里命中。
2. 同样的结果被反复计算
有些接口慢，不是因为 SQL 特别复杂，而是因为每次都在重新做拼装、聚合、排序或序列化。只要结果在一段时间内可以复用，Redis 就可以作为这段时间里的“结果暂存层”，减少重复计算。
3. 主流程里混入了很多短状态
例如验证码、会话状态、限流窗口、短期幂等标记、临时令牌，这些信息通常都有明显的时效性。它们不是长期主数据，但又要求读写足够快、过期足够直接。Redis 对这类“有生命周期的短状态”非常合适。
4. 系统需要一个比数据库更轻的高频协调层
有些需求并不是传统业务存储，而是“快速判断一下当前状态”：
- 某个用户最近一分钟请求了几次
- 某个任务是否已经处理过
- 某个榜单当前前 100 名是谁
- 某个键是否应该在 5 分钟后自然失效
这些都更像在线系统里的高频运行状态，而不是需要复杂查询和强事务保障的主数据。Redis 的价值，往往正体现在这里。
Redis 到底解决了什么
如果把 Redis 放到系统设计里看，它通常解决的是下面四类问题：
| 问题 | Redis 带来的变化 |
|---|---|
| 读路径太慢 | 把热点数据前移，减少数据库和应用计算压力 |
| 短状态管理麻烦 | 用 TTL、原子命令和简单结构承接临时状态 |
| 高频判断成本高 | 用内存访问降低计数、存在性判断、排行读取的延迟 |
| 主库被无效流量拖慢 | 把可复用、可过期、可容忍短暂旧值的数据放到旁路 |
这里有一个前提很重要：Redis 解决的是访问路径和运行时状态问题，不是自动替你解决所有数据问题。
Redis 适合做什么
判断 Redis 是否适合，最简单的方法不是先看命令，而是先看数据和业务能否接受它的边界。
适合的场景
- 热点缓存：读多写少，允许短时间旧值
- 临时状态：会话、验证码、短期令牌、幂等标记
- 高频计数：访问次数、窗口限流、配额消耗
- 在线结构：排行榜、去重集合、短周期事件状态
- 低延迟辅助层：给数据库、搜索系统或主业务库做前置加速
这些场景有一个共同点：它们更看重访问速度、过期控制和高频读写，而不是复杂查询与严格事务。
Redis 不适合做什么
很多 Redis 事故不是因为 Redis 本身不稳定，而是因为它被放到了不该承担的位置。
不适合的场景
- 把所有业务主数据只放在 Redis
- 期待 Redis 替代关系型数据库的复杂查询和事务
- 需要跨多条记录的强一致业务写入
- 需要长期、完整、强审计的数据存档
- 把 Redis 当成“什么都能塞进去的万能桶”
尤其要避免一个常见误区：因为 Redis 很快，就把它当成默认主存。速度并不会自动替代数据模型、恢复能力和一致性要求。
一个够用的判断标准
在决定是否引入 Redis 之前，可以先问五个问题：
- 这份数据是不是会被高频读取，却没有必要每次都回源？
- 这份状态是不是天然带有生命周期，需要自动过期？
- 这次操作是不是更像高频在线判断，而不是复杂业务查询？
- 如果短时间读到旧值、丢掉一小段临时状态，业务是否可接受？
- 即使 Redis 不可用，系统是否仍保留了主数据和恢复路径？
如果前四个问题多数是“是”，而第五个问题也能回答清楚，那么 Redis 往往值得引入。
如果你发现自己回答的是另一组问题，比如“要不要跨表事务”“要不要复杂筛选”“要不要唯一真相源”，那通常说明你该优先考虑数据库，而不是先上 Redis。
这个系列为什么拆成 13 篇
Redis 最容易学偏的地方，在于大家经常先背命令，再补边界。这样到了线上，问题会变成：
- 为什么命中了缓存，系统还是不稳
- 为什么看起来只是一个 Key-Value，却会遇到内存、淘汰、复制和高可用问题
- 为什么同样是 Redis，不同结构一换，性能和风险就完全变了
所以这个系列会按 13 个主题展开，而不是把所有内容塞进一篇超长总览里。
接下来的 13 篇主题
- 为什么系统需要 Redis
- 键、内存、单线程与性能边界
- 数据结构总览与选型判断
- Cache Aside、穿透、击穿与雪崩
- 计数器、排行榜、去重与会话
- Pub/Sub、Stream 与队列边界
- TTL、淘汰策略、碎片与大 Key
- RDB、AOF 与恢复目标
- 主从复制与 Sentinel 自动故障切换
- Cluster 的哈希槽、重定向与分片扩展
- StackExchange.Redis 连接、读写与序列化
- 缓存、批量、Pipeline 与性能优化
- 分布式锁、限流、幂等与生产排障
这三篇 overview 的作用，是先把总方向立住：
- 第一篇讲为什么需要 Redis，以及它该不该上场
- 第二篇讲 Redis 到底是什么样的系统模型
- 第三篇讲面对不同结构时，应该怎样建立判断地图
后面的文章再分别深入展开。
先有判断，再学细节
对多数工程团队来说，Redis 从来不是“会不会 SET 和 GET”的问题，而是：什么时候值得把它引入主链路，什么时候应该把它放在辅助层，什么时候又该停下来别继续往里塞。
如果第一步判断错了，后面无论是数据结构、淘汰策略还是高可用部署，都会变成在错误方向上继续优化。
本篇解决了什么：
- 说明了系统为什么会因为热点读、重复计算和短状态管理而引入 Redis
- 划清了 Redis 的适用边界：适合做低延迟访问层，不适合充当所有业务主存
- 给出了一组引入 Redis 前可直接自检的问题
- 交代了这个系列接下来 13 篇的展开路线