一、引言1.1 运行程序的性能瓶颈的判断思路是什么在讲解 Redis IO 多路复用之前小编先问大家一个题外话题就是你会怎么判断一个应用程序哪方面会拖后腿可以从哪些方面来分析首先从一个软件运行开始就意味着操作系统需要分配相关资源给它。一个运行的应用程序有三个方面的核心资源。CPU内存IO。为什么会是这三个方面。CPU资源代表着计算能力是程序执行的核心动力。CPU负责执行指令、完成算法计算以及各种逻辑运算。无论是简单的条件判断还是复杂的数据处理本质上都是CPU在进行指令级别的执行。CPU性能的高低直接决定了单位时间内程序能够处理多少任务。内存资源代表着数据的存储与访问能力是CPU工作的“数据载体”。程序运行过程中所需的变量、对象、中间结果以及缓存数据都会存放在内存中。CPU无法直接高效地从磁盘获取数据必须依赖内存作为中转。IO资源代表着数据的输入与输出能力是程序与外部世界交互的通道。包括磁盘读写、网络通信、设备交互等。IO操作通常是整个系统中最慢的部分因为它涉及硬件设备或网络传输。程序需要从磁盘加载数据、通过网络获取请求或返回结果这些都属于IO范畴。IO性能直接影响系统的响应速度和吞吐能力。【总结】一句话程序运行 计算CPU 数据内存 数据流动IO所以任何性能瓶颈本质上不是算得慢就是拿数据慢或者搬数据慢我们可以看一下速度之间的对比CPU 访问 1 秒组件等价时间L1 Cache3 秒内存5 分钟SSD(固态硬盘)3 天HDD(机械硬盘)几个月【总结】CPU ≫ 内存 ≫ IO磁盘 / 网络【总结】 软件系统瓶颈 磁盘 IO1.2 Redis 明明把内存当数据库使用为什么还要优化IO?Redis 直接把 内存 当作数据库除去了本地磁盘IO慢的问题。先不考虑持久化落盘。为什么因为触发次数少只要不是不合理的触发几乎不会有太大的影响为什么还要优化IO【总结】 Redis软件系统瓶颈 内存 CPU 网络 IO我先把问题提出来最后在分析 IO 为什么还要优化先把 CPU内存这两个核心资源给分析完在分析IO的问题。【问题一】Redis 对 CPU 的性能依赖大吗CPU 会不会成为瓶颈从设计上看Redis 对 CPU 的依赖并不是其主要瓶颈来源但在特定场景下仍然可能受到 CPU 限制。首先Redis 采用单线程模型执行命令这带来两个显著特点一是避免了多线程上下文切换带来的额外开销二是天然具备命令执行的原子性。因此Redis 不需要为线程切换频繁、锁竞争等问题消耗 CPU 资源这一点相比多线程系统是明显优势。其次从计算角度来看Redis 的大部分操作属于轻量级计算例如键查找哈希表、简单的数据结构操作等单次命令的 CPU 消耗较低。但在以下场景中CPU 仍可能成为瓶颈大 Key 或高复杂度操作如 O(n) 命令Lua 脚本执行数据结构转换或编码压缩持久化过程中的计算如 RDB 压缩、AOF 重写内存碎片整理active defrag不过需要注意的是这些操作大多是阶段性或后台触发的并非主路径高频操作。因此总体来说Redis 的 CPU 压力通常可控但在高复杂度命令或大数据量场景下仍需关注。总结Redis 通过单线程模型减少了 CPU 在调度上的浪费但在复杂命令或数据规模较大时CPU 仍可能成为性能瓶颈。【问题二】Redis 对内存的性能依赖大吗内存会不会成为瓶颈内存是 Redis 最核心的资源之一可以说 Redis 的性能高度依赖内存。Redis 将内存作为主存储介质而不是磁盘这使得数据访问延迟从毫秒级降低到纳秒级是其高性能的根本原因之一。但这也意味着内存容量直接决定数据规模上限内存访问效率直接影响整体性能内存管理策略碎片、分配、淘汰至关重要从性能角度看内存“通常不会拖后腿”原因在于其访问速度远高于 IO。但在以下情况下内存反而会成为瓶颈内存不足触发淘汰策略LRU/LFU内存碎片严重导致有效利用率下降BigKey 导致操作阻塞fork用于 RDB/AOF时内存页表复制开销大此外Redis 的数据安全依赖持久化机制RDB/AOF但持久化并不改变其“以内存为主”的本质。总结内存是 Redis 的性能基础正常情况下不会成为短板但在容量、碎片和数据结构不合理时会直接影响系统稳定性与性能。【问题三】Redis 对网络 IO 的性能依赖大吗网络 IO 会不会成为瓶颈在 Redis 架构中网络 IO 往往是最容易成为瓶颈的部分之一。Redis 作为一个内存数据库本质是一个高性能的网络服务其 IO 主要体现在客户端与服务端之间的连接建立与维护请求命令的发送与解析响应数据的返回随着系统并发量的提升问题会逐渐显现第一大量客户端连接会带来高并发 socket 管理压力。例如上万连接同时存在如果采用传统阻塞或轮询方式会导致 CPU 大量浪费在“无效等待”上。第二请求量越大网络传输带宽 RTT就越容易成为限制因素。即使 Redis 内部处理很快网络也可能成为瓶颈。第三数据规模增大后持久化RDB/AOF带来的磁盘 IO 也会间接影响整体性能尤其是在高写入场景下。为了解决这些问题Redis 采用了 IO 多路复用如 epoll机制使单线程可以同时监听大量连接只处理“就绪事件”避免空轮询从而大幅提升 CPU 利用率。总结Redis 的高性能建立在“内存 单线程”的基础上但真正限制吞吐能力的往往是网络 IO 和连接管理能力。因此在高并发场景下网络 IO 更容易成为系统瓶颈。所以Redis 在高并发系统设计中如何高效处理大量客户端连接是服务端架构的核心问题之一。作为一个以内存操作著称的高性能数据库Redis 能够轻松支撑数万甚至数十万并发连接其背后的关键技术之一就是IO 多路复用I/O Multiplexing。很多人存在一个误区认为 Redis 6 才引入 IO 多路复用。实际上Redis 从早期版本就已经使用 IO 多路复用机制Redis 6 的优化是在此基础上引入了多线程 IO。本文将从问题出发深入分析 Redis 为什么需要 IO 多路复用以及它是如何工作的。二、没有 IO 多路复用会发生什么在传统网络编程模型中方式如下一是阻塞 IOBIO—— 一连接一线程。每个客户端连接对应一个线程维持连接着。问题也是随之明显的。问题一线程数量随连接数量线性增长。问题二内存占用高线程栈空间毕竟线程越来越多。问题三CPU 切换线程时上下文开销巨大socket之间不断轮询导致线程之间也不断切换问题四难以支撑高并发1万连接 ≈ 1万个线程二是轮询模型。单线程不断遍历所有连接。问题也是随之明显。问题一大量“无效检查”很多连接没有数据问题二CPU 空转严重 (很多线程没有命令执行切换到这条线程也没有命令执行)问题三时间复杂度 O(n)低效浪费 CPU 资源重点Redis 从诞生开始就使用 IO 多路复用并没有经历“先轮询、再升级”的阶段。上面的图仅仅只是为了方便理解。❌ Redis从来没有用“简单轮询”来处理连接✅ Redis一开始就是基于 IO 多路复用select/poll/epoll设计的三、什么是 IO 多路复用在高并发服务器设计中一个核心问题是如何用更少的资源处理更多的客户端连接 传统模型往往在连接数增加时迅速崩溃而 IO 多路复用技术的出现使得单线程也能高效处理成千上万的连接。同样的成千上万的客户端连接可能真正有数据只有几百个传统方案 阻塞IO 轮询。造成大量无效扫描线程数量爆炸上下文切换频繁CPU空转严重等等。而 IO 多路复用解决的是如何无效等待核心思想就是让操作系统帮我们监听所有连接只返回“有事件”的连接。也就是说将socket 连接数量都“委托”给操作系统来管理。Redis 不管理维护 Socket 连接这样一来就没有这方面的压力了。那么问题来了那是怎么个委托法IO 多路复用才能让 Redis 并没有体会有压力毕竟就算是委托给操作系统难道操作系统就不用判断处理哪条客户端连接有命令需要处理还有就是又是怎么避免大量无效扫描CPU 空转严重等问题。带着问题我们一步一步去学习与探索四IO 多路复用的三种方式在传统阻塞I/O模型中每个连接需要独立分配一个线程或进程来处理。当连接数达到千级甚至万级时系统资源线程栈、内存、上下文切换开销会迅速成为瓶颈。例如一个线程默认栈空间约8MB(虚拟内存)1万连接就需要消耗约80GB内存。这个是按照最悲观的态度来计算的。实际上线程刚被创建的时候仅仅只有几KB后面随着调度使用会慢慢增长最大内存空间到8MB。实际物理内存占用 8MB。真实情况一个线程可能就是 100KB ~ 500KB。那么 100KB × 10000 ≈ 1GB 500KB × 10000 ≈ 5GB 真实内存 1GB ~ 5GB而不是 80GB尽管是 1~ 5GB可能有钱人觉得不就是5个G的内存我有钱内存就一个字给我扩充就完了。但问题依旧存在。首当其冲的就是上下文切换才是最致命的。# 1万线程 → CPU 疯狂切换 # 成本 # 保存/恢复寄存器 # cache 失效 # 调度开销第二个问题就是调度压力Linux 调度器需要管理 1万个 runnable 线程时间复杂度上升。第三个问题就是文件描述符 内核资源开销也不小每个连接一个 socket其内核结构体开销也不小。所以即便如此1 万个线程仍可能消耗数 GB 内存。同时更严重的问题在于频繁的线程上下文切换和调度开销这会显著降低系统性能。线程栈 8MB 是“上限”不是“实际占用”真正拖垮系统的是线程数量带来的调度和切换成本。因此“一连接一线程”模型在高并发场景下难以扩展这正是 IO 多路复用技术出现的根本原因。IO 多路复用通过单一线程监控多个文件描述符实现了“一个线程处理万级连接”的能力。三种机制的演进时间线如下select1983年BSD系统首次引入通过位图管理fd集合poll1997年System V系统改进使用动态数组替代固定位图epoll2002年Linux 2.5.44内核引入基于事件驱动的回调机制select最古老的多路复用机制select是最早出现的IO多路复用机制。其核心函数原型如下int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);select使用三个位掩码fd_set类型来分别表示读、写、异常的文件描述符集合。fd_set本质上是一个位图bitset——使用位图中对应的位来表示要监视的文件描述符。# select的工作流程如下 # 1. 用户将需要监控的fd集合位图传入内核 # 2. 内核遍历所有fd检查其状态 # 3. 当有fd就绪或超时时select返回 # 4. 内核修改位图——只保留就绪的fd未就绪的被清除 # 5. 用户需要再次遍历整个位图找出哪些fd真正就绪了 # 需要注意的是readfds、writefds和exceptfds都是输入输出型参数 # 输入时告诉内核要关心哪些fd # 输出时内核告诉用户哪些fd已经就绪。简单的理解就是redis 将需要维护的客户端的Socket连接线程都委托给 select 多路复用的方式维护。select 会将超时未就绪状态的线程都给移除掉剩下的都是状态正常或者有数据的线程。但是我们可以感觉到确实和轮询相比排除一些超时或未就绪状态的线程。减少一部分工作量但不多。并且 select 也有很严重的缺陷限制。问题一--O(n)线性扫描每次调用select内核都需要遍历所有被监控的fd来检查状态时间复杂度为O(n)。当连接数达到10万时单次select调用耗时可达毫秒级问题二--大量内存拷贝每次调用select都需要将fd_set从用户态的空间拷贝到内核态的空间返回时再从内核态拷贝回用户态的空间。高并发场景下这种拷贝消耗的资源是惊人的。问题三--文件描述符数量限制select使用fd_set位图管理fd默认最多支持1024个文件描述符由FD_SETSIZE宏定义限制。虽然可以通过修改宏重新编译内核来提升但治标不治本。# 适用场景 # 连接数较少1000的轻量级应用 # 需要兼容多种Unix-like系统的跨平台场景 # 实时性要求极高的场景select的timeout精度为微秒而poll和epoll为毫秒 # 简单应用或学习目的还不如不用现在的电脑1000 的连接量还是随便接得住的。毕竟这个是1983年时代的产物。poll: 突破数量限制的改进版poll是对select的改进其核心函数原型如下int poll(struct pollfd *fds, nfds_t nfds, int timeout); struct pollfd { int fd; // 文件描述符 short events; // 监控的事件输入 short revents; // 返回的事件输出 };poll使用一个pollfd结构体数组来代替select的位图每个结构体包含文件描述符和对应的事件掩码。这种方式突破了select的1024个fd数量限制理论上只受系统内存和文件描述符上限的约束。缺陷所在尽管poll解决了fd数量限制但其本质问题依然存在1O(n)线性扫描poll仍然需要遍历整个pollfd数组来检查每个fd的状态时间复杂度仍为O(n)。10万连接时单次poll调用仍需约1.8ms。2大量内存拷贝每次调用poll都需要将整个pollfd数组从用户空间拷贝到内核空间。无论fd是否就绪全部都要拷贝一遍。3重复初始化每次调用poll都需要重新设置events字段。4内存开销pollfd数组占用连续内存大连接数时容易产生内存碎片适用场景 连接数在1K-10K之间的中等规模应用 需要同时监控读写事件的场景 平台支持poll且对实时性要求不高的场景 对内存占用不敏感的环境对实时性响应要求不高的可以接受使用 poll。但redis 肯定不适用。epoll革命性的事件驱动机制epoll是Linux特有的I/O多路复用机制它从根本上一举解决了select和poll的性能瓶颈。epoll的核心设计包含三个关键组件1红黑树Red-Black Tree内核使用红黑树高效管理所有被监控的fd增删改操作的时间复杂度为O(log n)。用户通过epoll_ctl增删fd无需像select/poll那样每次传入整个集合。2就绪列表Ready List内核维护一个双向链表只存储已经就绪的活跃fd。3回调机制当fd状态发生变化时内核通过回调函数自动将其加入就绪列表。【epoll 的本质】epoll 事件驱动 内核维护就绪队列 用户只处理活跃连接epoll 为什么比 select / poll 快模型工作方式select/poll每次遍历所有 fdepoll只返回“有事件的 fd”❗ epoll 把“遍历”这件事从“每次循环做”变成了“只有事件发生时做”Redis 在 Linux 上采用的就是 epoll 的方式。这样的话就相当于操作系统的 epoll 多路复用是 Redis 的“叫号系统”只有“被叫到号”事件监听被触发Redis 才会处理。这样 Redis 就只会处理有数据的线程。因为有数据才会触发事件监听事件监听触发之后就会被 redis 接收到。之后就交给主线程执行命令即可。标准的epoll 流程┌──────────────┐ │ 客户端连接 │ └──────┬───────┘ ↓ socket fd 创建 ↓ epoll_ctl 注册事件 ↓ ┌──────────────────┐ │ 事件循环ae │ │ epoll_wait │ └──────┬───────────┘ ↓ 有事件返回 fd ↓ 调用对应 handler ↓ ┌───────────────┬──────────────┐ ↓ ↓ ↓ 读事件 写事件 定时事件 处理命令 返回结果 过期key等Redis 在 Linux 上基于 epoll 实现 I/O 多路复用通过单线程事件驱动模型实现了对万级连接的高效处理是其高性能的核心基础之一。五Redis 的 AE模块AE 模块全称 Abstract Event事件抽象层它本质是 Redis 自己实现的一套# 跨平台 I/O 多路复用封装 事件驱动框架 # 也就是说 AE Redis 的“事件引擎” 基于不同的操作系统采用不同的多路复用方案比如系统使用Linuxepoll ✅macOSkqueue老系统selectAE 模块的设计精髓非常重要✅1. 抽象层设计跨平台Redis 没直接写 epoll 而是aeApiPoll() aeApiAddEvent()不同系统实现不同版本 这就是“面向接口编程”在 C 语言的体现✅2. Reactor 模式核心思想Redis AE 本质就是Reactor 模式流程事件注册 → 事件监听 → 事件分发 → 事件处理✅3. 单线程 多路复用 Redis 没有线程池多线程 IO而是一个线程 epoll 管理万级连接Redis 6 之后引入多线程 epoll 管理万级连接 Redis AE ≠ epoll Redis AE epoll 事件调度 时间事件 抽象层一张结构图帮你彻底理解┌──────────────┐ │ Redis AE │ │ (事件框架 │ └──────┬───────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌────▼────┐ ┌─────▼────┐ ┌─────▼────┐ │ epoll │ │ kqueue │ │ select │ │ Linux │ │ macOS │ │ fallback │ └─────────┘ └──────────┘ └──────────┘六、延伸思考面试加分点1Redis 是使用单线程还是多线程如果不是单线程那为什么不用多线程执行命令首先需要明确在 Redis 6.0 之前Redis 是完全单线程的但从 Redis 6.0 开始Redis 引入了多线程不过仅仅是用于“网络 I/O 和协议解析”核心的“命令执行”依然是单线程的。为什么核心的命令执行要坚持单线程主要有以下几个原因CPU 不是瓶颈内存和网络才是Redis 是基于纯内存的操作内存的读写速度极快纳秒级。在大多数场景下CPU 处理命令的速度远快于网络传输和内存访问的速度。多线程并不能突破内存带宽和网络带宽的物理极限。避免上下文切换开销Redis 的命令执行时间通常在微秒甚至亚微秒级别。如果使用多线程线程上下文切换的开销可能会比命令执行本身的时间还要长得不偿失。避免锁竞争和死锁多线程共享内存数据必然需要加锁。锁的竞争、死锁的排查会极大降低性能并让代码变得极其复杂。单线程天然避免了这些问题。保证原子性单线程串行执行命令天然保证了每个命令执行的原子性不需要像关系型数据库那样引入复杂的 MVCC多版本并发控制或锁机制。简化设计与维护单线程模型让 Redis 的代码非常简洁易于开发、调试和维护。补充Redis 6.0 的多线程做了什么Redis 6.0 发现随着网卡带宽的提升如万兆网卡单线程处理网络 I/O接收数据、解析 RESP 协议、发送数据成为了瓶颈。因此它引入了多个 I/O 线程来并行处理网络读写和协议解析但在将解析好的命令交给核心执行引擎时依然通过全局锁保证单线程串行执行2epoll 和 select/poll 的区别这三者都是 I/O 多路复用机制但epoll是 Linux 下对select/poll的全面升级核心区别如下特性select / pollepoll数据结构基于数组/链表。基于红黑树存储监听的 fd和双向链表存储就绪的 fd。最大连接数select 有硬性限制通常 1024由FD_SETSIZE决定poll 无硬性限制但受限于系统内存。没有硬性上限上限是系统最大文件描述符数量通常 10W受限于系统内存。fd 遍历方式线性遍历 O(N)。每次调用都需要遍历整个 fd 集合检查哪个 fd 就绪。当连接数多但活跃连接少时效率极低。回调机制 O(1)。只有活跃的 fd 才会触发回调将其加入就绪链表。epoll_wait只返回就绪的 fd无需遍历。内存拷贝每次调用都需要将整个 fd 集合从用户态拷贝到内核态。监听集合通过mmap让内核和用户空间共享内存避免了全量拷贝仅就绪 fd 需要拷贝到用户态。触发模式仅支持水平触发LT。支持水平触发LT和边缘触发ET。ET 模式下只有状态发生变化时才通知效率更高。总结在海量连接但活跃连接较少的场景下如 Web 服务器epoll的性能呈线性甚至指数级碾压select/poll。3Redis 事件循环如何实现Redis 没有使用 libevent 等第三方事件库而是自己实现了一个轻量级的事件处理库叫做ae (Async Event)。它基于Reactor 模式核心实现逻辑如下核心结构aeEventLoop 事件循环的核心是一个结构体里面主要维护两类事件文件事件File Events处理网络 I/O如客户端连接、读写数据。时间事件Time Events处理定时任务如serverCron用于定期清理过期键、持久化 RDB/AOF、内存淘汰等。底层 I/O 多路复用封装 ae 库在底层封装了 epoll、kqueue、evport、select 等 API。在 Linux 环境下Redis 会优先编译并使用epoll。事件循环主函数aeMain Redis 启动后会进入一个无限循环aeMain其核心逻辑是调用aeProcessEvents第一步处理文件事件。调用底层的epoll_wait获取就绪的 fd。如果有读事件就绪调用读事件处理器如readQueryFromClient接收并解析命令如果有写事件就绪调用写事件处理器如sendReplyToClient返回结果。第二步处理时间事件。遍历时间事件链表检查是否有到期的定时任务。如果有则执行对应的处理函数如执行一次serverCron。第三步计算下一次阻塞时间。根据最近的一个时间事件计算epoll_wait需要阻塞的超时时间然后进入下一次循环。4为什么 Redis 性能仍然很高即使核心命令执行是单线程Redis 依然能轻松达到 10万 QPS其高性能的秘诀在于“把每一滴性能都榨干”纯内存操作这是最根本的原因。所有数据都在内存中避免了磁盘 I/O 的机械延迟。内存的响应时间是纳秒级而磁盘是毫秒级相差十万倍。高效的数据结构Redis 没有使用通用的数据结构而是针对各种场景设计了专属结构。例如使用SDS简单动态字符串替代 C 语言原生字符串获取长度 O(1)且杜绝缓冲区溢出。针对小数据量使用ziplist、quicklist、intset、hashtable等紧凑结构极大节省内存并提高 CPU 缓存命中率。I/O 多路复用机制使用epoll机制单线程可以同时监听和处理数以万计的并发连接实现了非阻塞的高效网络 I/O。单线程避免了开销如前所述单线程避免了多线程的上下文切换和锁竞争让 CPU 100% 专注于执行命令。轻量级的事件循环自己实现的 ae 事件库去除了第三方库的冗余代码极其轻量高效。底层 C 语言优化Redis 使用 C 语言编写贴近硬件避免了不必要的内存拷贝并且对内存对齐、CPU 缓存行等底层细节做了大量优化。简单的协议与批量操作使用RESP 协议解析极其简单高效。支持Pipeline管道和Lua 脚本允许客户端批量发送命令或在服务端原子执行一段逻辑大幅减少了网络 RTT往返时间带来的延迟。