Redis 是一个高性能的内存键值数据库，即使使用单线程架构，它也能在单机环境中支持大约 100,000 QPS 的查询性能。虽然多线程通常被认为能够更高效地处理并发请求，但 Redis 的设计哲学和实现方式表明单线程架构对它来说是更合适的选择。
数据存储在内存中
Redis 完全基于内存运行，数据存储在内存中，而不是传统数据库常用的磁盘中：
- 内存操作速度极快：绝大多数请求是纯内存操作（如读写哈希表或列表），比磁盘 I/O 快得多。
- 避免磁盘读写开销：与传统数据库需要通过磁盘读取数据再加载到内存相比，Redis 直接在内存中完成数据处理，显著减少延迟。
高效的数据结构
Redis 提供了五种主要的数据类型：String、List、Hash、Set 和 SortedSet。
- 每种数据类型背后都有高效的数据结构支持，例如哈希表、跳跃表等。
- 数据结构设计的目标是快速完成增删改查操作。
- 通过精心优化，Redis 数据结构可以快速处理高并发请求。
单线程架构
Redis 使用单线程架构处理网络请求和键值读写。单线程设计的优势包括：
- 避免上下文切换：多线程设计会涉及大量的线程上下文切换，增加 CPU 消耗，而单线程避免了这部分开销。
- 消除竞争条件：没有线程间竞争，避免了需要使用锁等机制来保证线程安全，也不会因为锁导致死锁或性能瓶颈。
- 简单性：单线程实现更加简单、易于维护，没有复杂的线程同步逻辑。
Redis 的单线程仅用于处理网络请求、数据读写等主要任务，但其他功能（如持久化、异步删除、数据同步）是通过额外线程完成的。
为什么 Redis 选择单线程架构？
Redis 官方指出，Redis 的瓶颈不在于 CPU，而是内存或网络带宽。在这种情况下，单线程架构简单且高效，无需复杂的多线程设计。
需要注意的限制：
- Redis 是内存数据库，设计目标是快速处理请求。因此，某些耗时较长的命令（如
hgetall、lrange、smembers等）可能会导致阻塞。谨慎使用这些命令以避免性能问题。
非阻塞 I/O
Redis 使用基于事件循环的非阻塞 I/O 模型（I/O 多路复用）：
- I/O 多路复用：通过
select、poll或epoll等技术同时监控多个网络连接，处理多个客户端请求。 - 高效利用单线程：在监听多个连接时，单线程仅处理有事件的连接，避免了无意义的资源浪费。
- Reactor 模式：Redis 的网络事件处理器基于 Reactor 模式，通过事件分发器高效地调度和处理客户端请求。
Redis 的网络事件处理流程：
- Redis 使用单线程接收请求（socket 读取）、解析命令、执行命令、返回结果（socket 写入）。
- 不同客户端的命令按照队列顺序依次处理，避免了并发问题。
Redis 6.0 的多线程改进
为什么 Redis 之前版本不支持多线程？
Redis 采用单线程架构是为了保持简单性和高效性：
- 多线程会带来程序执行顺序的不确定性，引入并发读写问题。
- 多线程需要锁机制，导致性能开销增加（如线程切换、加锁/解锁、甚至死锁）。
为什么 Redis 6.0 引入多线程？
Redis 的瓶颈逐渐转移到网络 I/O 模块，而不是内存操作。多线程用于优化：
- 网络 I/O 处理性能：接收、发送数据和协议解析这类耗时任务可以使用多线程加速。
- 最大化 CPU 利用率：通过多线程并行处理网络 I/O，减少阻塞带来的性能损失。
Redis 多线程如何启用？
Redis 默认禁用多线程，可通过配置文件开启：
io-threads-do-reads yes
io-threads <线程数量>- 推荐线程数为：4 核机器设置 2-3 线程，8 核机器设置 6 线程。
- 线程数不应超过 CPU 核心数，且尽量不超过 8。
多线程是否存在并发问题？
多线程模式仅优化网络数据的接收、发送和解析，而命令执行（内存操作）依然在单线程中顺序完成：
- 无并发问题：多线程不会影响命令的执行顺序，避免了线程安全问题。
- 优势：最大化利用网络 I/O 并行处理能力，同时保持单线程模型的简单性。
总结
Redis 使用单线程架构的高性能来源于以下几点：
- 数据存储在内存中，避免磁盘 I/O。
- 高效的数据结构设计优化了操作速度。
- 单线程架构避免了锁、上下文切换等性能开销。
- 非阻塞 I/O 模型高效处理并发请求。
Redis 6.0 引入多线程，通过多线程优化网络 I/O 性能，同时保持命令执行的单线程模型，进一步提升了系统的整体性能。
