提到 Redis，所有人的第一反应都是“快”。
作为基于内存的中间件，Redis 的 QPS 能轻松达到 10 万级别。但当你深入研究时，会发现两个看似矛盾的现象：
Redis 的核心命令处理是单线程的。
Redis 却能同时处理成千上万个客户端连接。
单线程怎么能同时搞定那么多连接？这就涉及到了 Redis 的杀手锏——I/O 多路复用。很多同学容易把它和 BIO、NIO、AIO 搞混，今天我们就用最接地气的“干饭模式”来彻底拆解这套高并发架构。
一、 Redis 为什么这么快？
在聊复杂的 IO 模型前，我们先复习一下 Redis 快的三大基石，这好比 F1 赛车的三大件：
纯内存操作（跑道好）： 数据都在内存里，读写是纳秒级的。相比磁盘（毫秒级），这简直是降维打击。
单线程模型（车手稳）： Redis 的核心业务（读写数据）由一个主线程完成。没有了多线程的上下文切换开销，也不用去考虑复杂的锁竞争，简单即是极速。
I/O 多路复用（调度强）： 这就是我们今天要重点讲的内容，它是 Redis 实现高并发吞吐的关键。
高效的数据结构
二、 到底什么是“I/O 多路复用”？
在讲 BIO/NIO/AIO 之前，我们必须先要把这个词搞清楚，否则后面全是浆糊。
多路：指的是多个网络连接（Socket）。
复用：指的是复用同一个线程。
一句话定义：I/O 多路复用是一种机制，允许一个线程同时监听多个连接的就绪状态（是不是可读了、是不是可写了）。
如果没有这个机制，一个线程只能盯着一个连接，那 Redis 就废了。有了这个机制，Redis 的主线程就像开了“上帝视角”，可以同时监控成千上万个客户端，谁有数据发过来，就处理谁。
三、 深度图解：BIO、NIO 与 AIO 的区别
那么这三者和IO多路复用什么关系呢？
简单来说，I/O 多路复用约等于NIO(更准确说是 NIO 的核心实现机制)
为了彻底搞懂多路复用在整个 IO 体系里的位置，我们把**“处理网络请求”比作“去餐厅吃饭”**。
1. BIO (Blocking I/O) —— 食堂排队打饭模式
这是最传统的阻塞模式。
场景：你去食堂打饭，必须在一个窗口前排队。
状态：轮到你之前，你必须傻站着（阻塞），不能玩手机，不能去厕所。如果前面那个人点菜磨磨唧唧（网络数据没传输完），你和后面的人都得干等着。
对应系统：一个线程处理一个连接。连接数一多，服务器就需要开启海量线程，内存直接爆掉。
2. NIO (Non-blocking I/O) —— 海底捞叫号模式
本质上还是要等。
这就是I/O 多路复用的核心体现。
场景：你去吃海底捞，前面有 100 个人。服务员（Redis）给你发了个号码牌。
状态：
你不用站在门口傻等，你可以去美甲、擦鞋、玩手机（非阻塞）。
但是，你必须时刻关注门口的大屏幕（Selector/Epoll）。
一旦大屏幕显示“108号，请用餐”，你得自己走进去（主线程自己去读取数据）。
关键点：
大屏幕就是多路复用器（Epoll）。它负责监控所有人。
你自己走进去说明读写数据的动作依然是你自己做的（同步）。
总结：Redis 使用的 I/O 多路复用（Epoll），本质上就是 NIO。它解决了“傻等”的问题，让一个线程（服务员）能通过大屏幕管理成千上万个食客。
3. AIO (Asynchronous I/O) —— 包厢外卖/电话通知模式
这是真正的异步模式。
场景：你是 VIP，直接给餐厅留个电话，然后回家躺着。
状态：
你根本不用管大屏幕，也不用在现场。
餐厅做好饭，打包好，直接让骑手送到你家门口（操作系统把数据读好，放到你指定的内存地址）。
然后给你打电话：“饭在门口了，出来吃”（回调通知）。
区别：NIO 是你要自己看屏幕、自己进去吃；AIO 是饭直接喂到嘴边。
四、 为什么 Redis 选 NIO (多路复用) 而不是 AIO？
既然 AIO 看起来更高级（饭喂到嘴边），为什么 Redis 还要用 NIO（海底捞模式）呢？
Linux 的 AIO 不成熟：在 Linux 系统下，真正的 AIO（基于内核）直到最近几年才通过
io_uring慢慢完善，以前的 AIO 很多是用线程池模拟的，性能反而不如精简的 Epoll。系统复杂度：Redis 的设计哲学是极致简单。NIO 模型配合单线程，逻辑非常清晰。而 AIO 需要处理复杂的回调逻辑，容易引入 bug。
性能足够：对于内存数据库来说，内存读写才是大头，网络 I/O 通过 Epoll 已经能压榨满网卡带宽了，换成 AIO 提升有限。
五、 Redis 线程模型的演进
最后，我们看看 Redis 是如何一步步榨干服务器性能的。
1. Redis v4.0 之前：纯粹的单线程
除了持久化生成 RDB/AOF 是子进程外，其他的核心工作全是一个线程在扛。
2. Redis v4.0：引入后台线程（Lazy Free）
解决了一个痛点：删除大 Key。以前删一个 10GB 的 Key，主线程要卡几秒。4.0 以后，主线程只负责把 Key 扔到“垃圾桶”（unlink），然后由后台线程慢慢清理内存。
3. Redis v6.0：多线程 I/O（Threaded I/O）
解决了新时代的瓶颈：网络带宽。 现在的 CPU 太快了，Redis 的主线程计算不是瓶颈，瓶颈变成了**“从网卡把数据读出来”和“把结果写回网卡”这两个动作。 于是v6.0 引入了多线程来处理网络数据的读写（即海底捞模式中，多雇几个人专门帮忙看大屏幕和领人进门**），但**核心的命令执行（干饭）**依然是主线程单独完成。
六、 总结
Redis 的高性能并非玄学，而是清晰的架构选择：
IO 模型：选择了NIO (I/O 多路复用/Epoll)—— 就像海底捞的大屏幕，一个线程监控所有连接，拒绝阻塞傻等。
线程模型：核心逻辑坚持单线程—— 就像王牌车手，避免了多线程的上下文切换和锁竞争。
辅助手段：利用多线程处理耗时的网络 IO 和内存回收 —— 把脏活累活外包，让主线程专注核心业务。
理解了这些，你就真正看懂了 Redis 的底层逻辑。
