最近，一位朋友参加小米技术面试时，被问到一个经典问题：“Redis 为什么能支持 10 万以上的 QPS？”他下意识地回答“因为它是内存数据库”，结果面试官立刻追问：“Memcached 也是内存数据库，为什么 Redis 能处理更复杂的数据结构，性能反而更强？”他一时语塞，最终面试未能通过。
这个案例揭示了一个关键点：在技术面试中，仅仅记住结论是远远不够的，面试官真正考察的是你对技术底层原理的深入理解。今天，我们就来系统性地拆解这个问题，彻底搞懂 Redis 高性能背后的四大核心架构支柱。
在深入分析之前，我们先明确“10万+ QPS”的具体性能表现。根据最新的基准测试数据（在标准笔记本环境下），Redis 的单核心性能大致如下：
- GET 操作：约 103,504 QPS
- SET 操作：约 100,894 QPS
- INCR 操作：约 99,662 QPS
如果启用 Pipeline 进行批量命令处理，INCR 操作的 QPS 甚至可以达到百万级别。如此高的性能，绝非简单的“内存速度快”可以解释。
下面这张架构总览图，清晰地展示了支撑 Redis 超高并发的四大核心设计：
接下来，我们将对这四大支柱逐一进行深度解析。
支柱一：内存存储，性能基石
Redis 将所有数据存放在内存中，这是其实现高性能的物理基础。一次内存访问的延迟通常在 0.1 微秒级别，而一次磁盘的随机 I/O 则需要约 10 毫秒。两者之间存在高达 10 万倍（五个数量级）的性能差距，这是最根本的性能鸿沟。
举例来说：从 1000 万用户中查询某个 ID 的信息。在 MySQL 中，即使有 B+ 树索引优化，也至少需要 2~3 次磁盘 I/O，耗时约 20~30 毫秒。而 Redis 直接在内存中进行哈希查找，耗时仅约 0.1 毫秒。这已经不是“快一点”，而是代际的性能碾压。
支柱二：精妙的数据结构设计
如果说内存是舞台，那么数据结构就是舞台上经过精心编排的舞蹈。Redis 提供的五种核心数据结构（String, Hash, List, Set, Sorted Set），每一种都不是对传统数据结构的简单封装，而是针对特定使用场景进行了极致的深度优化。
简单动态字符串（SDS）
C 语言的原生字符串存在两个致命缺陷：获取长度需要遍历（O(N)时间复杂度），且修改时极易引发缓冲区溢出。Redis 自行设计了 SDS 结构来解决这些问题：
struct sdshdr {
int len; // 已使用长度
int free; // 未使用长度
char buf[]; // 字节数组
};其设计精妙之处在于：
- O(1) 时间复杂度获取长度：直接读取
len字段，无需遍历字符串。 - 杜绝缓冲区溢出：执行修改操作前会检查剩余空间，不足则自动扩容。
- 空间预分配策略：扩展时会额外分配空闲空间，减少后续修改时内存重分配的频率，提升性能。
压缩列表（ziplist）
当哈希表或列表的元素数量较少、且元素值较小时，Redis 会启用压缩列表作为底层实现。它将所有元素紧凑地存储在一块连续的内存中，完全避免了指针带来的内存开销，并且能更好地利用 CPU 缓存行，访问效率极高。
通常，当哈希表或列表的元素个数小于 512，且每个元素值的长度小于 64 字节时，Redis 会自动采用 ziplist 编码。
跳表（Skip List）
这是有序集合（ZSET）的核心底层实现之一。跳表通过构建多级索引，将查找、插入、删除操作的平均时间复杂度降低到 O(log N)。虽然理论复杂度与平衡树相同，但其实现远比平衡树简单，且更易于进行并发控制。
查找时从最高层索引开始，可以大跨度地跳跃前进，效率非常高。
渐进式 rehash
这是 Redis 哈希表扩容时的“智慧”策略。传统哈希表扩容需要一次性迁移所有数据，可能导致服务短暂卡顿。Redis 采用了渐进式 rehash：它会同时维护新旧两个哈希表，将迁移工作平摊到后续的每次增、删、改、查操作中，逐步完成数据迁移，从而避免了集中式迁移带来的性能抖动。
支柱三：单线程模型与 I/O 多路复用
很多人疑惑，为什么 Redis 核心处理命令只用单线程，却能支撑高并发？这背后有三个关键原因：
- CPU 通常不是瓶颈：对于内存级别的数据操作，速度极快，CPU 的运算能力往往过剩，性能瓶颈通常在于网络 I/O。
- 避免锁竞争：单线程模型天然避免了多线程环境下的锁竞争和频繁的上下文切换开销，使得代码路径更简单、性能更可预测。
- I/O 多路复用技术：这是实现高并发的核心技术。通过
epoll（Linux）、kqueue（BSD）等机制，一个线程可以同时监控成千上万个网络连接，只有当连接真正有读写事件就绪时，才进行相应的处理，完美解决了 C10K 乃至 C100K 问题。
简而言之，Redis 利用多路复用器处理海量的网络连接，用单线程处理核心的业务逻辑，兼得了高并发与架构的简单性。
支柱四：从单线程到多核利用的演进
Redis 6.0 是一个重要的性能分水岭。在此之前，网络 I/O 的读写和协议解析也是单线程处理，在极端高流量场景下可能成为瓶颈。6.0 版本引入了多线程 I/O（请注意，这并非多线程执行命令）。
新的多线程 I/O 架构工作流程非常清晰：
- I/O 读取：多个 I/O 线程并行读取客户端请求，并解析命令协议。
- 命令执行：解析后的命令仍然交给唯一的主线程按顺序执行，这保证了操作的原子性和无锁。
- I/O 写入：主线程执行完命令后，将结果交给多个 I/O 线程并行写回给客户端。
这样一来，最耗时的网络 I/O 部分被并行化了，充分利用了多核 CPU 的优势，而核心的数据操作逻辑依然保持单线程的简单与正确性。
其他性能优化最佳实践
除了上述核心架构设计，一些最佳实践也能将 Redis 的性能推向极致：
- Pipeline 批量操作：将多个命令打包一次性发送，极大减少网络往返延迟（RTT）。在需要连续执行多个命令的场景下效果显著。
- 避免大 Key（Big Key）：单个 Key 对应的 Value 过大（例如超过 10KB）的查询或删除操作可能会阻塞服务。可以使用
redis-cli --bigkeys命令定期扫描排查。 - 合理配置持久化策略：在纯缓存场景或进行性能压测时，可以暂时关闭 RDB 快照和 AOF 日志，避免持久化操作带来的额外 I/O 开销。
总结
回到最初的问题，Redis 之所以能轻松支撑 10 万+ QPS，甚至达到百万级吞吐，是四大支柱协同发力的结果：
- 内存存储：从根本上规避了磁盘 I/O 的性能瓶颈。
- 极致的数据结构设计：SDS、ziplist、跳表、渐进式 rehash 等，在内存效率与 CPU 缓存友好性上做到了极致优化。
- 单线程模型与 I/O 多路复用：以简洁的架构避免了锁竞争，并高效管理海量并发连接。
- 多线程 I/O：在保持核心逻辑单线程的前提下，利用多核提升网络吞吐能力。
深入理解技术，贵在探究本质。知其然，更要知其所以然。希望本次对 Redis 高性能底层逻辑的全面梳理，能让你在下次面对类似的高频面试题时，不仅能够回答“是什么”，更能清晰、有条理地阐述“为什么”。
