Redis为什么这么快？

https://chat.deepseek.com/share/pf1o2xjsueob99dlfp

面试记录 2026-09-20

题目：Redis为什么这么快？

难度：medium

标签：db/redis/core, redis/architecture, general/knowledge

评分：⭐⭐⭐☆☆（3/5）

我的回答

Redis 快跟慢本身是一个相对概念。Redis 所谓的快是跟谁对比？它对比的条件一般是跟过往的数据库，磁盘性的交互的，正常的、常规的数据库，MySQL、Oracle 这些去比，所以它快。它快的原因核心在于几个点吧。首先是存储介质跟计算介质获取方数据方式。存储介质，它的所有数据是在缓存中的，直接从缓存中拿，要比数据库去从磁盘中去获取要快得多。当然，数据库 MySQL 它也有缓存读，但是这是另外一个事。另外额外的，它快的原因就是它的数据获取方式。它自定义了大量自己很多自己使用方便的数据库结构，数据结构。这些数据结构方便它获取数据。而另外它核心的获取数据方式是 Key-Value，通过类，通过哈希的方式直接定位到缓存中的对应数据位置，所以它获取的数据基本上是特别特别快的。

点评

优点：

• 开篇点出"快是相对概念"，体现思考深度
• 抓住两个核心：全内存存储 + Hash O(1) 查找
• 主动对比 MySQL buffer pool，意识正确

不足：

• 遗漏最关键的架构点：单线程 + I/O 多路复用（epoll/kqueue）
• 未提网络层：自定义 RESP 协议简洁高效
• 未提内存结构优化：SDS、ziplist/listpack 等紧凑结构
• 表述零散，缺少结构化层次

补充：

1. 架构层：单线程避免锁竞争；epoll I/O 多路复用；6.0 后多线程处理网络 I/O
2. 数据层：SDS O(1) 取长度；小数据用 ziplist/listpack 紧凑
3. 系统层：jemalloc；fork COW 不阻塞主线程
4. 对比视角：MySQL 慢在磁盘 I/O + 锁竞争 + SQL 解析 + 事务/日志

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对 Redis 高性能的架构层、数据结构层、系统层三维度理解，能否跳出"内存 vs 磁盘"这种表层对比。

知识点拆解：

1. 架构层：单线程 + I/O 多路复用

• Redis 主线程单线程处理所有命令，避免锁竞争和上下文切换
• 依赖 epoll（Linux）/ kqueue（macOS）实现 I/O 多路复用
• 6.0 引入多线程处理网络 I/O，命令执行仍单线程

1. 数据层：全部驻留内存 + 高效数据结构

• 数据全内存，避免磁盘 I/O
• Hash 底层是哈希表 O(1)；小 hash 用 listpack
• SDS O(1) 取长度、二进制安全、避免大量 realloc

1. 系统层：内存分配器 + 无锁单线程

• jemalloc 替代 ptmalloc，减少碎片
• RDB 用 fork + COW，主线程几乎不阻塞
• 无并发 → 无锁 → 无 CAS 开销

1. 网络层：RESP 协议简洁

• 基于 TCP 的二进制协议，解析简单
• 支持 Pipeline / 二进制传输

对比 MySQL 的"慢"来自哪里：磁盘 I/O、多线程锁竞争、SQL 解析、事务日志落盘。

第二部分：考察方向与延伸递进

考察方向：

• 深度：单线程模型能否水平扩展？6.0 多线程边界
• 广度：与 Memcached / KV 存储性能模型对比
• 应用：大 key、慢命令导致单线程阻塞如何排查与规避

延伸递进面试题：

1. 单线程的 Redis 6.0 为什么引入多线程？

• 解答要点：命令执行仍单线程，多线程只做 socket read/write 和协议解析

1. Redis 什么场景下会变慢甚至阻塞？

• 解答要点：大 key（DEL 大 hash）、KEYS、SORT、SMEMBERS、慢 Lua、fork 卡顿

1. Redis 比 Memcached 快 / 慢在什么地方？

• 解答要点：Redis 多数据结构、持久化、Lua、Pub/Sub 带来更多开销

1. 单线程模型如何保证高并发下不 OOM？

• 解答要点：内存淘汰策略、maxmemory、Cluster 分片

1. 如果 Redis CPU 单核打满，你怎么优化？

• 解答要点：慢查询日志 → 拆分大 key → Cluster 分片 → 6.0 多线程参数

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，Redis 快我觉得首先要区分清楚是"快在哪一层"，我一般从三个维度讲。

架构层，Redis 默认是单线程模型处理所有命令，这样避免了多线程的锁竞争和上下文切换。同时它依赖 epoll 做 I/O 多路复用，一个线程能同时 hold 住上万连接。这也是 Redis 6.0 之前 CPU 单核就是瓶颈的原因，6.0 之后把 socket 读写和协议解析放到多线程，但命令执行依然保持单线程。

数据层，数据全部驻留内存，天然就比磁盘 I/O 的 MySQL 快。而且数据结构是自研的，Hash 底层用哈希表 O(1) 查找；字符串用 SDS，O(1) 取长度；小规模的 list/hash/zset 用 listpack 紧凑存储。

系统层，内存分配用的是 jemalloc，减少碎片；RDB 持久化用 fork 加 COW 写时复制，主线程几乎不阻塞。

相比之下 MySQL 慢的原因是多维的：主要是磁盘 I/O，再加上多线程并发带来锁竞争、SQL 解析优化、事务日志落盘，不只是内存 vs 磁盘的差别。

工程上我实际踩过两个坑：一是 DEL 一个大 hash 卡住单线程，最后换成 UNLINK；二是 Cluster 分片之前没做数据倾斜分析，单节点 QPS 打满。所以理解 Redis 快，本质是理解它做的一整套"少锁、少系统调用、少内存分配、少磁盘操作"的取舍。