为什么 Redis 设计为单线程？6.0 版本为何引入多线程？

【核心定义】
Redis 的核心网络模型和键值操作采用单线程设计，主要是为了避免多线程的并发竞争问题，简化实现并充分发挥内存操作的性能优势；6.0 版本引入多线程主要是为了提升网络 I/O 的吞吐量，应对高并发场景下的性能瓶颈。

【关键要点】

单线程的优势
- 避免锁竞争：单线程模型天然避免了多线程环境下的锁竞争和上下文切换开销，简化了数据结构的实现（如字典、跳跃表等）。
- 内存操作高效：Redis 的数据全部存储在内存中，操作速度极快，单线程已能充分利用 CPU 缓存和流水线效率。
- 原子性保证：所有命令在单线程中顺序执行，天然支持原子性，无需额外同步机制。
单线程的瓶颈
- 网络 I/O 成为瓶颈：随着网络带宽提升和并发连接数增加，单线程处理网络读写（特别是大键值或批量操作）可能成为性能瓶颈。
- 多核利用不足：现代服务器多为多核 CPU，单线程无法充分利用多核资源。
6.0 多线程的引入
- 并行化网络 I/O：6.0 版本将网络读/写、协议解析等耗时操作分配给多个 I/O 线程并行处理，但命令执行仍由主线程单线程执行，保持原子性。
- 配置可控：通过 io-threads 参数控制 I/O 线程数（通常建议为 CPU 核数的 1/2 到 2/3），避免过度线程切换。

【深度推导/细节】
单线程性能逻辑：

Redis 基于 Reactor 事件驱动模型（如 Linux 的 epoll），单线程通过事件循环处理大量连接，在内存操作场景下，瓶颈往往在内存访问速度而非 CPU 计算。
但当客户端并发量极高（如 10 万+连接）或需要处理大量数据（如 10MB 以上的大键）时，网络读写和协议解析可能占用主线程过多时间，导致延迟上升。

6.0 多线程设计细节：

【关联/对比】

与 Memcached 对比：Memcached 采用多线程模型，通过全局锁保护数据结构，在高并发下锁竞争可能成为瓶颈；Redis 单线程避免了这一问题，但 6.0 后通过 I/O 多线程弥补了网络短板。
与数据库对比：关系型数据库（如 MySQL）需要处理复杂事务和磁盘 I/O，多线程模型更合适；Redis 定位于内存高速缓存/存储，单线程简化了设计。

『面试官追问』

Redis 单线程为什么还能支持高并发？
- 基于事件驱动的非阻塞 I/O，通过 epoll 管理大量连接，CPU 时间主要用于内存操作，而非线程调度。
多线程后如何保证线程安全？
- 仅网络 I/O 并行，命令执行仍由主线程串行处理，数据操作无需加锁。
为什么不将命令执行也多线程化？
- 会引入复杂的锁机制（如分段锁），破坏 Redis 的原子性语义，且内存操作本身极快，收益有限。
6.0 多线程默认开启吗？如何配置？
- 默认关闭，需配置 io-threads 4 和 io-threads-do-reads yes 开启。

【直击痛点】

【版本差异】

# 为什么 Redis 设计为单线程？6.0 版本为何引入多线程？