Redis 为什么这么快？它的线程模型是怎样的？

详细解析#

快在哪里#

线程模型#

Redis 6.0 之前，网络读写、协议解析和命令执行都在一个主线程里完成，结构是一个事件循环（和 Node.js 的事件循环 思路类似）：

主线程事件循环：
  等待事件（epoll_wait）
    ├─ 有新连接：accept
    ├─ 连接可读：读数据 → 解析命令 → 执行命令 → 结果写入输出缓冲区
    ├─ 连接可写：把输出缓冲区的数据发给客户端
    └─ 定时任务：清理过期 key 等

"单线程"指的是执行命令的只有一个线程，Redis 进程里还有其他线程和子进程：

• 后台线程：关闭文件、AOF 的 fsync、异步释放内存（UNLINK、FLUSHALL ASYNC）
• 子进程：生成 RDB 快照、重写 AOF 时 fork 出来，见 RDB 和 AOF

Redis 6.0 的多线程#

并发连接很多时，瓶颈会出现在网络读写的系统调用和协议解析上。6.0 把这部分交给了 I/O 线程：

主线程：收集可读的连接，分给各个 I/O 线程
I/O 线程（并行）：读数据、解析命令
主线程：等所有 I/O 线程解析完，按顺序逐个执行命令
I/O 线程（并行）：把结果写回客户端

命令执行仍是单线程的，所以数据结构不用加锁，原有的原子性保证不变。这个功能默认关闭，需要配置 io-threads（比如设为 4）开启。6.x、7.x 里开启后默认只有写回客户端走多线程，读和解析也要走多线程，还需要打开 io-threads-do-reads；Redis 8.0 重写了 I/O 线程的实现，读和写总是都交给 I/O 线程，这个配置不再起作用。

单线程的代价#

一条命令执行 100 毫秒，这 100 毫秒里所有客户端的请求都在排队。常见的慢操作：

• KEYS *：遍历所有 key，key 多时会阻塞很久
• 对大 Key 做全量操作：HGETALL、SMEMBERS、LRANGE key 0 -1，以及用 DEL 删除一个很大的集合，见 大 Key 和热 Key
• 执行时间很长的 Lua 脚本
• 同步执行的 FLUSHALL、FLUSHDB

对策：用 SCAN 代替 KEYS，用 HSCAN、SSCAN、ZSCAN 分批遍历集合，用 UNLINK 代替 DEL 删除大 Key；用 SLOWLOG GET 查看慢命令（默认记录执行超过 10 毫秒的命令）；生产环境可以用 ACL 或 rename-command 禁用 KEYS 这类危险命令。

代码示例#

用 SCAN 分批遍历匹配的 key（ioredis）：

async function scanKeys(redis, pattern) {
  const keys = new Set() // SCAN 可能返回重复的 key，用 Set 去重
  let cursor = '0'
  do {
    // 每次只遍历一小部分，命令很快返回，不会长时间阻塞其他请求
    const [next, batch] = await redis.scan(cursor, 'MATCH', pattern, 'COUNT', 200)
    batch.forEach((k) => keys.add(k))
    cursor = next
  } while (cursor !== '0')
  return [...keys]
}

面试官可能追问#

易错点#

• Redis 的"单线程"指命令执行是单线程，进程本身有多个线程，还会 fork 子进程
• 6.0 的多线程默认是关闭的，而且只用于网络 I/O，不会并行执行命令
• Redis 快的前提是命令本身快，O(N) 的命令在数据量大时同样会拖垮整个实例