1 / 16
为什么后端一定会用到 Redis
当我们讨论后端系统为何「一定会用到 Redis」时，本质上是在回答一个更根本的问题：传统的关系型数据库在高并发场景下为何会成为瓶颈，以及内存与磁盘之间的本质差异如何决定了现代后端架构的形态。 理解了这一点，你就会明白 Redis 并非可有可无的「加速器」，而是填补了从磁盘到 CPU 之间那道巨大鸿沟的必然选择。
数据库为什么扛不住高并发
关系型数据库的设计初衷是保证数据的持久化与一致性，其存储介质是磁盘。当请求量较小时，数据库可以通过缓冲池将热点数据加载到内存，从而在相当长的一段时间内维持可接受的响应延迟。然而一旦并发请求数上升，每个请求都可能触发对磁盘的访问，而磁盘的随机读写延迟通常在毫秒级，与内存的纳秒级访问相比相差数个数量级。此时线程会因等待磁盘 I/O 而阻塞，连接池被占满，新的请求只能排队或超时，系统从「可用」迅速滑向「不可用」。
更深一层的原因在于，数据库的 ACID 保证和复杂查询（如连接、聚合、事务）都建立在「数据在磁盘上、按页读写」这一假设之上。高并发意味着大量会话同时竞争同一批数据页或同一把锁，锁等待和 I/O 等待叠加在一起，使得延迟呈指数级放大。因此，从架构视角看，让数据库「直接扛」高并发读写，本质上是在用最慢的组件去承接最大的流量，这注定会成为整个系统的短板。
与此密切相关的是，业务层往往存在明显的访问倾斜：少数热点数据（如热门商品、首页配置、某明星用户的动态）被绝大多数请求反复访问。若这些请求每次都落到数据库上，同一份数据会被重复从磁盘加载、重复加锁、重复计算，造成巨大的资源浪费。因此，要扛住高并发，必须有一层「离 CPU 更近」的存储，能够以极低延迟响应这些重复访问，从而把数据库从「每请求都查」的困境中解放出来。这正是内存型存储登场的背景。
内存与磁盘的本质差异
内存与磁盘的差异，远不止「一个快一个慢」这么简单；它反映的是计算机体系结构里最根本的一条鸿沟：易失性与非易失性、随机访问与顺序/块访问、纳秒级与毫秒级延迟。内存是 CPU 可直接寻址的存储，一次读写通常在百纳秒量级完成，且延迟稳定；磁盘则依赖磁头寻道、盘片旋转和块传输，单次随机 I/O 的延迟往往在几毫秒，且受队列深度和调度策略影响，波动很大。这种数量级上的差距，使得「把热点数据放在内存里」成为提升系统吞吐与稳定性的不二法则。
从数据结构的视角看，内存支持真正的随机访问和细粒度更新，因此可以高效实现哈希表、跳表、链表等复杂结构，并在这些结构上做 O(1) 或 O(log n) 的操作；而磁盘数据库通常以「页」为单位读写，即使只改一个字段，也可能要整页落盘并维护 WAL，成本远高于内存中的一次指针修改。因此，当业务需要「高并发、低延迟、丰富数据结构」时，内存天然是更合适的舞台；而磁盘更适合承担「持久化、大容量、强一致性」的职责。二者在系统里各司其职，才能既扛住流量，又保住数据。
理解这一差异之后，我们就能看到：后端系统要同时满足「高并发、低延迟」和「数据可持久、可恢复」，就不可能只依赖单一存储层。必然会有「热数据在内存、全量或冷数据在磁盘」的分层设计。而 Redis 正是站在「内存」这一侧、面向高并发与丰富数据结构的代表；它不替代数据库，而是与数据库配合，用内存换时间，用结构换复杂度。
Redis 在后端系统中的位置
Redis 在后端架构中的角色，可以概括为「应用与数据库之间的网络内存层」。请求从客户端到达应用服务器后，应用会优先查询 Redis：若命中，则直接返回，不再访问数据库；若未命中，则回源到数据库，并在合适的时机将结果写入 Redis，供后续请求使用。这样，大量重复的读请求被 Redis 消化掉，数据库只需处理未命中的请求和写请求，压力与延迟都得到显著缓解。从拓扑上看，Redis 与业务应用同处「计算与内存」这一侧，而 MySQL、PostgreSQL 等则处在「持久化与磁盘」那一侧，二者通过明确的读写策略协同工作。
在多级缓存体系中，Redis 通常扮演「服务端分布式缓存」这一层。浏览器或客户端可能有本地缓存，应用进程内也可能有本地缓存（如 JVM 堆内缓存），而 Redis 提供的是跨进程、跨机器的共享缓存，使得多实例、多机房的后端能够共享同一份热点数据，同时保持较低的访问延迟（通常在同一机房内可做到亚毫秒级）。因此，在微服务架构下，Redis 既可能被每个服务独立使用（如各自缓存本服务的数据），也可能作为跨服务的共享存储（如分布式 Session、全局计数器、消息队列），其位置始终是「紧贴业务、背靠数据库」的中间层。
从「为什么后端一定会用到 Redis」这个问题回溯：数据库在高并发下受限于磁盘 I/O 与锁竞争，而内存与磁盘在延迟和访问模式上存在本质差异；因此，引入一层以内存为核心、支持丰富数据结构、并能够以网络服务形式被多实例共享的组件，就成为必然。Redis 正是这一角色的典型实现。在后续学习中，我们会深入它的设计哲学、数据结构与典型应用场景；届时你会更清晰地看到，它如何用「内存换时间、用结构换复杂度」，成为现代后端架构中不可或缺的一环。