为什么在高并发系统中离不开 Redis？——核心场景与原理深度解析

引言

在高并发、高性能系统设计中，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 磁盘

即使 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 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，才能真正支撑高并发系统