在后端面试中有一个经典的“灵魂拷问”“Redis 是单线程的为什么还能这么快”很多人第一反应是“因为它是内存数据库”。但这只说对了一半。如果仅仅因为内存快那多线程的内存数据库岂不是要起飞为什么 Redis 偏偏选择单线程还能达到 10万 QPS每秒查询数的恐怖吞吐量今天我们就来彻底扒开 Redis 的设计哲学看看这“单线程”背后到底藏着什么黑魔法。一、 先纠正一个误区Redis 真的是纯单线程吗在讨论性能之前必须先澄清一个事实Redis 并不是严格的“纯单线程”。我们常说的“单线程”指的是 Redis 的核心命令执行模块处理客户端发来的 get、set 等读写请求是单线程的。但在 Redis 内部其实还有其他的线程在默默工作· 后台线程用于处理持久化如我们之前聊过的 bgsave、bgrewriteaof、异步释放大内存等。· I/O 多线程Redis 6.0用于处理网络数据的读取和协议解析但命令的执行依然是单线程。所以Redis 的单线程准确地说是“单线程处理命令多线程辅助 I/O”。二、 为什么单线程还能这么快四大核心原因纯内存操作降维打击这是最根本的原因。Redis 将所有数据存放在内存中绝大部分操作都是纯内存操作。· 内存的读写速度是纳秒级ns而磁盘的读写是毫秒级ms。· 内存的速度比磁盘快了 10万倍 以上。Redis 避免了磁盘 I/O 的瓶颈这就像别人还在泥沼里走路你已经开上了高铁。I/O 多路复用Epoll单线程扛起十万并发这是 Redis 高并发的基础。传统的网络编程如 Java 的 BIO是一个连接对应一个线程。1000 个客户端连接就需要 1000 个线程。线程的上下文切换和内存开销会直接压垮 CPU。Redis 采用了 I/O 多路复用Linux 下的 Epoll 模型。· 它将所有的客户端连接Socket注册到一个事件监听器Epoll 实例中。· 主线程就在那里“等”。当某个 Socket 有数据可读或可写时Epoll 会通知主线程。· 主线程只处理“就绪”的 Socket处理完继续等。· 效果一个线程就能同时监控成千上万个连接。没有创建线程的开销没有上下文切换的消耗。单线程的“无锁”优势避开了并发陷阱在传统的多线程服务器中为了保证数据的一致性必须引入锁如互斥锁、读写锁。· 加锁、解锁本身就是一种开销。· 更可怕的是如果锁没用好会导致死锁、线程阻塞甚至 CPU 飙升。· 而 Redis 的单线程模型意味着所有命令都是串行执行的。不需要任何锁机制天然保证了原子性。这不仅降低了代码的复杂度还避免了线程切换带来的 CPU 消耗。极致的底层数据结构Redis 的快还归功于它精心设计的底层数据结构· String使用 SDS简单动态字符串避免了 C 语言字符串的频繁内存分配和长度计算。· Hash使用渐进式 Rehash避免扩容时阻塞服务。· ZSet使用跳表SkipList在保证 O(log N) 查询效率的同时实现比红黑树更简单的范围查询。· List使用 QuickList双向链表 压缩列表兼顾了内存和性能。· 此外Redis 对内存分配器如 jemalloc也做了深度优化减少了内存碎片。三、 单线程的“代价”有哪些坑不能踩既然单线程这么好那为什么 Redis 6.0 还要引入 I/O 多线程因为单线程有一个致命的弱点一旦某个命令耗时过长整个 Redis 都会被阻塞。这就是著名的“一核有难多核围观”。在生产环境中我们必须避免以下操作大 Key 操作例如 hgetall 一个包含几万个字段的 Hash或者 smembers 一个巨大的 Set。这会导致主线程长时间计算和网络传输。危险的命令KEYS *全量扫描、FLUSHALL清空数据库。复杂的 Lua 脚本如果 Lua 脚本逻辑复杂且耗时长同样会阻塞主线程。大量数据的持久化如果 AOF 重写或 RDB 快照期间发生大量的写操作内存的写时复制COW会占用大量内存甚至导致主线程阻塞。实战建议使用 redis-cli --bigkeys 排查大 Key用 SCAN 命令代替 KEYS *将耗时的 Lua 脚本拆解或者放到单独的 Redis 节点执行。四、 既然单线程这么强为什么还要引入多线程随着硬件的发展网络带宽如 10G 网卡越来越大Redis 的性能瓶颈逐渐从 CPU 执行命令 转移到了 网络 I/O 的读写和协议解析 上。在 Redis 6.0 之前主线程需要亲自把网络包从 Socket 读出来、解析协议、执行命令、再把结果写回 Socket。这个过程在流量巨大时会占据主线程大量的时间。Redis 6.0 的 I/O 多线程 就是来解决这个问题的· 主线程依然负责执行命令保持单线程的原子性。· I/O 线程负责从 Socket 读取数据、解析协议以及把结果写回 Socket。这样主线程的 CPU 时间全部用来执行核心命令吞吐量再次得到质的飞跃。五、 总结Redis 之所以快是因为它把“单线程”的优势发挥到了极致纯内存操作规避了磁盘 I/OI/O 多路复用解决了并发连接单线程无锁避免了上下文切换精妙的数据结构保证了执行效率。它向我们证明了一个道理并发能力并不绝对依赖于多线程而是在于如何用最少的资源处理最多的 I/O 事件。理解 Redis 的单线程模型不仅能帮你在面试中对答如流更能让你在实际开发中主动避开那些可能导致 Redis 阻塞的“雷区”。技术之路知其然更要知其所以然。希望这篇博客能帮你彻底搞懂 Redis 的高性能密码 Redis明明只是单线程，为什么这么快？
在后端面试中有一个经典的“灵魂拷问”“Redis 是单线程的为什么还能这么快”很多人第一反应是“因为它是内存数据库”。但这只说对了一半。如果仅仅因为内存快那多线程的内存数据库岂不是要起飞为什么 Redis 偏偏选择单线程还能达到 10万 QPS每秒查询数的恐怖吞吐量今天我们就来彻底扒开 Redis 的设计哲学看看这“单线程”背后到底藏着什么黑魔法。一、 先纠正一个误区Redis 真的是纯单线程吗在讨论性能之前必须先澄清一个事实Redis 并不是严格的“纯单线程”。我们常说的“单线程”指的是 Redis 的核心命令执行模块处理客户端发来的 get、set 等读写请求是单线程的。但在 Redis 内部其实还有其他的线程在默默工作· 后台线程用于处理持久化如我们之前聊过的 bgsave、bgrewriteaof、异步释放大内存等。· I/O 多线程Redis 6.0用于处理网络数据的读取和协议解析但命令的执行依然是单线程。所以Redis 的单线程准确地说是“单线程处理命令多线程辅助 I/O”。二、 为什么单线程还能这么快四大核心原因纯内存操作降维打击这是最根本的原因。Redis 将所有数据存放在内存中绝大部分操作都是纯内存操作。· 内存的读写速度是纳秒级ns而磁盘的读写是毫秒级ms。· 内存的速度比磁盘快了 10万倍 以上。Redis 避免了磁盘 I/O 的瓶颈这就像别人还在泥沼里走路你已经开上了高铁。I/O 多路复用Epoll单线程扛起十万并发这是 Redis 高并发的基础。传统的网络编程如 Java 的 BIO是一个连接对应一个线程。1000 个客户端连接就需要 1000 个线程。线程的上下文切换和内存开销会直接压垮 CPU。Redis 采用了 I/O 多路复用Linux 下的 Epoll 模型。· 它将所有的客户端连接Socket注册到一个事件监听器Epoll 实例中。· 主线程就在那里“等”。当某个 Socket 有数据可读或可写时Epoll 会通知主线程。· 主线程只处理“就绪”的 Socket处理完继续等。· 效果一个线程就能同时监控成千上万个连接。没有创建线程的开销没有上下文切换的消耗。单线程的“无锁”优势避开了并发陷阱在传统的多线程服务器中为了保证数据的一致性必须引入锁如互斥锁、读写锁。· 加锁、解锁本身就是一种开销。· 更可怕的是如果锁没用好会导致死锁、线程阻塞甚至 CPU 飙升。· 而 Redis 的单线程模型意味着所有命令都是串行执行的。不需要任何锁机制天然保证了原子性。这不仅降低了代码的复杂度还避免了线程切换带来的 CPU 消耗。极致的底层数据结构Redis 的快还归功于它精心设计的底层数据结构· String使用 SDS简单动态字符串避免了 C 语言字符串的频繁内存分配和长度计算。· Hash使用渐进式 Rehash避免扩容时阻塞服务。· ZSet使用跳表SkipList在保证 O(log N) 查询效率的同时实现比红黑树更简单的范围查询。· List使用 QuickList双向链表 压缩列表兼顾了内存和性能。· 此外Redis 对内存分配器如 jemalloc也做了深度优化减少了内存碎片。三、 单线程的“代价”有哪些坑不能踩既然单线程这么好那为什么 Redis 6.0 还要引入 I/O 多线程因为单线程有一个致命的弱点一旦某个命令耗时过长整个 Redis 都会被阻塞。这就是著名的“一核有难多核围观”。在生产环境中我们必须避免以下操作大 Key 操作例如 hgetall 一个包含几万个字段的 Hash或者 smembers 一个巨大的 Set。这会导致主线程长时间计算和网络传输。危险的命令KEYS *全量扫描、FLUSHALL清空数据库。复杂的 Lua 脚本如果 Lua 脚本逻辑复杂且耗时长同样会阻塞主线程。大量数据的持久化如果 AOF 重写或 RDB 快照期间发生大量的写操作内存的写时复制COW会占用大量内存甚至导致主线程阻塞。实战建议使用 redis-cli --bigkeys 排查大 Key用 SCAN 命令代替 KEYS *将耗时的 Lua 脚本拆解或者放到单独的 Redis 节点执行。四、 既然单线程这么强为什么还要引入多线程随着硬件的发展网络带宽如 10G 网卡越来越大Redis 的性能瓶颈逐渐从 CPU 执行命令 转移到了 网络 I/O 的读写和协议解析 上。在 Redis 6.0 之前主线程需要亲自把网络包从 Socket 读出来、解析协议、执行命令、再把结果写回 Socket。这个过程在流量巨大时会占据主线程大量的时间。Redis 6.0 的 I/O 多线程 就是来解决这个问题的· 主线程依然负责执行命令保持单线程的原子性。· I/O 线程负责从 Socket 读取数据、解析协议以及把结果写回 Socket。这样主线程的 CPU 时间全部用来执行核心命令吞吐量再次得到质的飞跃。五、 总结Redis 之所以快是因为它把“单线程”的优势发挥到了极致纯内存操作规避了磁盘 I/OI/O 多路复用解决了并发连接单线程无锁避免了上下文切换精妙的数据结构保证了执行效率。它向我们证明了一个道理并发能力并不绝对依赖于多线程而是在于如何用最少的资源处理最多的 I/O 事件。理解 Redis 的单线程模型不仅能帮你在面试中对答如流更能让你在实际开发中主动避开那些可能导致 Redis 阻塞的“雷区”。技术之路知其然更要知其所以然。希望这篇博客能帮你彻底搞懂 Redis 的高性能密码 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
