Redis篇8——Redis深度剖析：揭秘 Redis 高性能

提到 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）给你发了个号码牌。
状态：
1. 你不用站在门口傻等，你可以去美甲、擦鞋、玩手机（非阻塞）。
2. 但是，你必须时刻关注门口的大屏幕（Selector/Epoll）。
3. 一旦大屏幕显示"108号，请用餐"，你得自己走进去（主线程自己去读取数据）。
关键点：
- 大屏幕就是多路复用器（Epoll）。它负责监控所有人。
- 你自己走进去说明读写数据的动作依然是你自己做的（同步）。

总结：Redis 使用的 I/O 多路复用（Epoll），本质上就是 NIO。它解决了"傻等"的问题，让一个线程（服务员）能通过大屏幕管理成千上万个食客。

3. AIO (Asynchronous I/O) ------ 包厢外卖/电话通知模式

这是真正的异步模式。

场景：你是 VIP，直接给餐厅留个电话，然后回家躺着。
状态：
1. 你根本不用管大屏幕，也不用在现场。
2. 餐厅做好饭，打包好，直接让骑手送到你家门口（操作系统把数据读好，放到你指定的内存地址）。
3. 然后给你打电话："饭在门口了，出来吃"（回调通知）。
区别：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 的底层逻辑。