1. 面试题目
面试官 ：你对 Redis 的线程模型熟悉吗？
候选人 ：熟悉，是单线程的。
面试官 ：好的，Redis 实例默认分 16 个库，这个你知道吧？
候选人 ：知道的。
面试官 ：好的，现在我有这样一个场景，服务 A 连接了 Redis 的 0 库，服务 B 连接了 Redis 的 1 库，这个时候服务 A 和 服务 B 同时执行了多个 Redis 命令，那么服务端是串行执行服务 A 和服务 B 的命令，还是会按照数据库进行隔离开，给每个数据库单独开一个线程执行？
候选人 ：嗯......应该是同一个线程，但是 0 库和 1 库是分开的，理论上也可以用两个线程，怎么感觉有点矛盾呢？
面试官 ：但服务 A 和服务 B 连接的是 0 库和 1 库，是两个不同的库，为什么不用两个线程呢？
候选人：我感觉有点不对，但是又说不上来哪里不对，确实有点怪，我还真不知道。
.......
2. 其他候选人
候选人A： 应该是两个线程，0 库和 1 库完全都是分开的，用两个线程没有毛病
候选人B： 这个平时还没有注意
候选人C： 这个我的下来再看看
候选人D： 是单线程，但是你这么分析，感觉用多线程好像更加合理一些
........
3. 到底是几个线程
这里需要注意： Redis的16个数据库（0-15）只是一个逻辑上的命名空间，它们全部存在于同一个Redis服务器进程中,。
在物理层面，它们共享同一内存空间及命令执行线程，理解这一点后，判断线程数量就更容易。
3.1. 核心结论
服务端是串行执行命令的。无论有多少个客户端、连接的是哪个库，所有命令都会进入同一个队列，由 Redis 唯一的主工作线程按顺序执行。
根本原因 ：Redis 的"单线程"指的是其命令执行模块。这一设计是 Redis 实现高性能、简单性和稳定性的核心基础。
3.2. 为什么不能为每个数据库开线程？技术上可行吗
技术上当然"可以"设计一个多线程系统，但这违背了 Redis 的设计哲学和初衷：
原因一：违背单线程简单性原则
Redis 的高性能部分来自于"无锁"设计。一旦引入多线程处理命令，就需要考虑：
- 数据竞争（比如两个 db 同时操作同一个 shared resource）
- 锁机制（如全局 dict 锁、过期 key 清理锁等）
- 上下文切换开销
- 内存模型复杂化
这会大大增加系统复杂度，反而可能降低性能。
原因二：数据库之间并非完全独立
虽然 key 空间隔离，但很多全局状态是共享的：
- 全局过期字典（
expires）：记录哪些 key 有过期时间 - Pub/Sub 频道（跨数据库可见）
- Lua 脚本执行环境（可能访问多个 db）
- 内存淘汰策略（LRU/LFU 是全局统计）
- 客户端连接管理、慢查询日志等
如果多个线程同时运行，这些共享资源就必须加锁，反而得不偿失。
原因三：性能瓶颈不在"数据库数量"，而在 I/O 和内存访问
Redis 的性能瓶颈通常是：
- 网络带宽
- 内存速度
- 复杂命令的 O(n) 时间复杂度
而不是"数据库是否并行"。用多线程解决"跨库并发"问题，收益极小，成本极高。
3.3. 执行流程
- 服务A（连0库）和服务B（连1库）分别与Redis服务器建立连接。
- 它们的请求命令会通过网络到达Redis的服务端。
- Redis的I/O 多路复用器（如epoll）会高效地监听到这些请求，并将这些来自不同套接字的命令有序地放入一个队列中。
- Redis 唯一的主工作线程会从这个队列中按 FIFO（先进先出）的顺序取出命令，然后逐一执行。
- 执行命令时，线程会根据命令中指定的数据库索引（例如
SELECT 0或SELECT 1）来切换到对应的逻辑库上操作数据。切换数据库的操作只是一个简单的指针赋值，开销极小
4. 为什么不给每个库分配一个线程？
- 避免资源竞争和锁开销： 这是最主要的原因。如果每个库一个线程，那么这些线程必然需要并发访问Redis的核心内存数据结构（如全局的键空间字典、过期字典等）。为了数据一致性，就必须引入复杂的锁机制（如互斥锁）。加锁、释放锁、线程等待和上下文切换会带来巨大的性能开销，这与Redis追求极速的设计目标背道而驰。单线程完美规避了所有这些问题。
- 保证操作的原子性： 单线程模型天然保证了任何命令的执行都是原子性的。一个命令要么完全执行成功，要么完全没执行，不会出现执行到一半被另一个线程的命令打断的情况。这对于一些需要原子性的场景非常友好，无需额外的事务控制 。
- 性能瓶颈不在CPU： 对于Redis这种内存型数据库，它的性能瓶颈通常是网络I/O和内存访问速度，而不是CPU。使用单线程处理命令已经足以压榨出网络和内存的极限性能。引入多线程带来的复杂度提升，其收益远远比不上它带来的损耗 。
- 简单性： 单线程模型的代码实现、调试和维护都比多线程简单无数倍。系统更加可预测，不存在死锁等问题 。
补充说明（非常重要）：
虽然命令执行是单线程的，但现代版本的 Redis（6.0+）也引入了多线程，但它是用于处理网络I/O的。即：使用多个I/O线程来并行读取socket请求、解析命令和写回响应，从而减轻主工作线程的负担。但是，最终所有命令的执行仍然是由那个唯一的主工作线程来串行完成的。这进一步印证了命令执行模块保持单线程的核心地位
5. Redis 的"数据库"只是逻辑隔离，不是物理
Redis 默认支持 16 个数据库（可通过配置修改），但这些数据库本质上是：
同一个 Redis 实例中的不同 key 命名空间（namespace）
它们共享：
- 同一个内存空间（虽然 key 不会冲突）
- 同一个事件循环
- 同一个主线程
- 同一个持久化流程（RDB/AOF）
- 同一个配置和监控系统
候选人感到"矛盾"的原因在于混淆了逻辑隔离 与物理/执行隔离的概念。Redis 的数据库只是 key 的命名空间，并非独立的进程或线程。
Redis 架构本质的理解："单线程 + 内存 + 简单数据结构"是其高性能的关键，而非依赖多线程并发。