引言
在高并发、高性能系统设计中，Redis 几乎是绕不开的基础组件。
本文将围绕几个实际业务问题，从底层原理 + 场景对比的角度，系统讲清 Redis 的核心价值。
一、为什么要使用 Redis
简要回答
因为 Redis 具备高性能、高并发、低延迟的特点，适合承担热点数据访问压力，保护后端数据库。
1.1 真实业务访问路径
在没有 Redis的情况下：
用户请求 → 应用服务 → MySQL（磁盘 IO） → 返回结果MySQL 需要从磁盘读取数据（即使有 Buffer Pool，也有限）
并发一高，容易：
- 连接数耗尽
- CPU 飙升
- 响应时间急剧上升
1.2 引入 Redis 后的典型模式
用户请求 ↓ 应用服务 ↓ 先查 Redis ↓ 命中 直接返回 ↓ 未命中 查询 MySQL → 写入 Redis → 返回这就是经典的Cache Aside（旁路缓存）模式。
Redis 的核心角色：
- 承接绝大多数读请求
- 减少 MySQL 的访问频率
- 将数据库从“高并发访问层”中解放出来
二、为什么 Redis 比 MySQL 快
这是一个高频问题，但很多回答都停留在“因为 Redis 在内存中”。
实际上，性能差距来自多个维度的叠加。
2.1 存储介质不同：内存 vs 磁盘
| 维度 | Redis | MySQL |
|---|---|---|
| 存储介质 | 内存 | 磁盘（为主） |
| IO 延迟 | 纳秒 / 微秒级 | 毫秒级 |
| 访问路径 | 极短 | 复杂 |
即使 MySQL 有 Buffer Pool，本质仍是为磁盘服务的系统。
2.2 数据结构不同：KV vs 表结构
Redis
- Key-Value 模型
- 数据结构简单（String、Hash、ZSet…）
- 无需解析 SQL、执行优化
MySQL
- 表结构 + 行记录
- SQL 解析
- 执行计划
- 索引选择
Redis 更像“内存数据结构引擎”，MySQL 是“通用关系型数据库”。
2.3 查询复杂度不同
Redis：
哈希表查找 →O(1)
MySQL：
B+Tree 索引 →O(log n)
还伴随回表、页读取
2.4 线程模型差异
Redis
- 核心命令执行：单线程
- 无锁竞争
- 无线程切换开销
MySQL
- 多线程
- 需要锁（行锁、表锁、元数据锁）
- 上下文切换成本高
Redis 的“单线程”，反而是性能稳定和可预期的关键原因之一。
三、本地缓存（JVM Cache） vs Redis 缓存
这是架构设计中非常关键的一道分界线。
3.1 本地缓存（如 Caffeine、Guava Cache）
特点
- 在 JVM 内存中
- 访问速度极快
- 无网络开销
问题
- 只能单机使用
- 多实例数据不一致
- 容易 OOM
- 重启即丢
3.2 Redis 缓存
特点
- 独立进程
- 集群共享
- 支持持久化
- 可扩展
3.3 典型使用建议
| 场景 | 建议 |
|---|---|
| 单体应用、低并发 | 本地缓存 |
| 分布式系统 | Redis |
| 极热点数据 | 本地缓存 + Redis（两级缓存） |
四、高并发场景下：Redis vs MySQL 的承载能力
这是理解 Redis 价值的关键问题。
4.1 单节点 MySQL 能承受多少并发？
在不做特殊优化的情况下：
QPS：几千级
并发连接数：几百～一千
超过后：
- 慢查询激增
- 锁竞争严重
- 服务雪崩
4.2 单节点 Redis 能承受多少并发？
在常见配置下：
QPS：10 万～20 万
延迟：亚毫秒级
性能非常稳定
4.3 高并发系统的经典架构形态
用户 ↓ 应用服务 ↓ Redis ← 承载 90%+ 读请求 ↓ MySQL ← 只处理写 + 少量读Redis 的使命不是“替代 MySQL”，而是：
把 MySQL 从并发地狱中拯救出来。
五、Redis 的真实定位总结
Redis 不是：
- 万能数据库
- 可以随便存一切数据
Redis 是：
- 高性能缓存
- 分布式系统的“缓冲层”
- 流量削峰、热点保护的核心组件
总结
Redis 的快，来自：
- 内存存储
- 简单数据结构
- O(1) 查询
- 单线程无锁模型
Redis 与 MySQL 是互补关系
正确使用 Redis，才能真正支撑高并发系统
