Redis 单线程模型为什么这么快？彻底搞懂核心原理
一、前言
很多同学都有一个固有认知：多线程一定比单线程快。
但 Redis 恰恰反常识：核心命令执行靠的是单线程，却能轻松支撑十万、百万级 QPS（服务器每秒能处理多少请求），性能远超很多多线程服务。
二、Redis 真的是单线程吗？
结论：不是全程单线程，只是命令执行单线程。
主线程（单线程）：负责接收请求、解析命令、执行 CRUD 操作（核心）
后台子线程：负责 RDB/AOF 持久化、内存回收、文件关闭等异步任务（主线程存在，后台线程才能运行）
Redis 6.0 新增 IO 多线程 ：仅优化网络读写、协议解析，命令执行依然是单线程串行执行，保证线程安全。
主线程和后台子线程之间怎么协作:
1，进程启动，最先跑起来的就是前台主线程，主线程完成基础初始化工作之后，主动发起创建操作，生成多条后台子线程；主线程相当于管理者；后台线程是它招募的辅助工人；如果主线程终止，整个进程结束，所有后台线程随之一起销毁。
补充：在操作系统底层，同一个进程里的所有线程地位是平等的，不存在严格意义上 "父线程、子线程"。 我们所说 "主线程创建后台线程"，是业务逻辑层面的描述：由处理命令的前台线程负责发起创建、管理后台线程。
三、Redis 单线程高性能的四大核心原因
1. 纯内存操作，没有磁盘 IO 瓶颈
MySQL 慢，是因为大量时间消耗在磁盘 IO、寻址、刷盘 ，所以需要多线程并发等待，提升吞吐量。（MySQL 大部分耗时消耗在磁盘寻道、IO 读写。线程发起 IO 请求后会阻塞等待磁盘数据，等待磁盘放返回数据这段时间 CPU 空闲。 采用多线程，当一部分线程阻塞等待磁盘 IO 时，操作系统可以调度其他线程处理新请求，充分利用 CPU 资源，以此提升系统吞吐量。）
而 Redis 的数据全部存储在内存中：内存读写速度是磁盘的上千倍，几乎没有 IO 阻塞等待，瓶颈不在 IO，而在 CPU 执行效率，这是 Redis 高性能的基础前提。
2. IO 多路复用：单线程管理数万连接
Redis 基于 Linux epoll 实现 IO 多路复用。
通俗理解：
一个线程，不阻塞、不等待，同时监听成千上万个客户端 Socket。
哪个客户端有请求，就处理哪个，不需要为每一个连接创建单独线程。
完美解决了单线程无法高并发的问题，实现了单线程高吞吐。
相反如果每来一个客户端都创建一个单独的线程，随着客户端的增多，线程数量增多，上下文切换开销巨大（需要保存当前线程的状态，并加载另一个线程的上下文）。另一方面对于单个线程来说，如果客户端没有请求，服务端这边就会发行阻塞，进而无法处理其他客户端的请求。
上下文：线程运行时，CPU 寄存器、程序计数器、栈、程序运行状态等信息，统称为线程上下文
3. 彻底规避多线程的性能损耗（最关键）
多线程看似并发快，实则有巨大开销：
1，线程上下文切换：频繁切换线程，消耗大量 CPU
2，锁竞争、死锁：多线程操作共享资源必须加锁
3，线程安全问题：代码复杂、维护成本高
Redis 单线程串行执行命令：
无需加锁、无需切换线程、没有竞争问题，CPU 全部用来执行业务逻辑，效率拉满。
4. 底层极致优化的数据结构
Redis 不是简单的 Map，底层封装了多种高度优化的数据结构：
-
SDS 动态字符串
-
压缩列表、跳表、哈希表、整数集合
绝大多数读写操作时间复杂度为 O(1) / O(logn)，执行速度极快，单线程完全扛得住高并发。
四、单线程模型的致命缺点
1. 慢命令会阻塞整个 Redis
所有命令串行执行，一旦出现耗时命令，主线程被卡死，后续所有请求排队阻塞，Redis 整体卡顿、超时、吞吐量暴跌。生产绝对禁止使用阻塞式慢命令。
2. 无法利用多核 CPU
单线程只能跑在一个 CPU 核心上，多核机器会出现 CPU 闲置，无法发挥整机性能。
解决方案：多部署 Redis 实例、搭建集群，充分利用多核。
五、Redis6.0 IO 多线程到底优化了什么？
很多人误解：Redis6 变成多线程执行命令了，但实际上只是分工发生了变化
-
多线程：负责网络读取、协议解析、结果写出
-
主线程：依然串行执行所有命令
目的：分担网络 IO 压力，提升吞吐，不改变单线程执行的核心模型，依然线程安全。
六、总结
-
Redis 快的核心：纯内存操作 + IO 多路复用 + 无锁单线程 + 高效数据结构。
-
单线程规避了多线程上下文切换、锁竞争开销，CPU 利用率更高。
-
单线程最大问题：慢命令阻塞主线程，生产必须杜绝耗时操作。
-
Redis6 多线程仅优化网络 IO，命令执行依旧单线程串行，保证线程安全。