ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

Redis的网络IO核心是IO多路复用模型，并根据版本迭代做了单线程/多线程的优化分工，整体设计兼顾了高并发、低延迟和实现简洁性，也是Redis能支撑海量连接的关键所在。

一、核心定位：IO多路复用是底层根基

IO多路复用的核心逻辑是：用单个线程/少量线程监控多个网络套接字（Socket）的读写状态，只有当某个套接字就绪（可读/可写）时，才进行实际的IO操作，避免阻塞等待单个连接，大幅提升CPU利用率。

Redis没有采用多线程阻塞IO、异步IO等方案，而是基于IO多路复用做定制化优化，核心原因是规避多线程锁竞争、减少上下文切换，保证命令执行的原子性和低延迟。

二、分版本IO模型细节（关键差异）

1. Redis 6.0 之前：单线程 + IO多路复用（经典模式）

• 全流程单线程：网络连接监听、IO读写、命令解析、命令执行、数据返回全部由单个主线程完成，不存在多线程竞争问题。
• 多路复用器兜底：主线程通过IO多路复用器监听所有客户端连接，轮询就绪套接字，批量处理IO事件，单个线程就能支撑数万并发连接。
• 误区纠正：这里的“单线程”仅指核心工作线程，Redis后台仍有子线程处理持久化、异步删除等耗时任务，不影响网络IO主线程。

2. Redis 6.0 及以后：多线程IO + 单线程命令执行（优化模式）

为解决高并发下网络IO读写的性能瓶颈，Redis 6.0引入多线程IO，但严格限定了多线程的使用范围：

• 多线程仅负责网络IO：客户端数据读取、协议解析、结果回写等IO操作，交由多个子线程并行处理，分摊主线程压力。
• 命令执行依旧单线程：真正的Redis命令（增删改查、事务、Lua脚本）仍由主线程串行执行，保证原子性，避免数据错乱。
• 多线程IO默认关闭，需通过配置io-threads、io-threads-do-reads手动开启，适合高并发、大流量场景。

三、底层IO多路复用器的选型（自适应系统）

Redis不会固定使用某一种复用器，而是编译时自动适配操作系统，选择性能最优的方案，优先级如下：

1. epoll：Linux系统首选，支持边缘触发/水平触发，无最大连接数限制，性能极高。
2. kqueue：FreeBSD、MacOS系统首选，性能与epoll接近，适配类Unix系统。
3. select/poll：兜底方案，兼容性强但性能较差（有连接数上限、轮询效率低），仅用于不支持epoll/kqueue的老旧系统。

四、模型优势总结

✅ 无锁竞争：命令单线程执行，杜绝数据并发安全问题；✅ 高并发支撑：IO多路复用让单个线程 handling 数万连接；✅ 低延迟：避免线程上下文切换，IO操作仅在就绪时执行；✅ 易维护：核心逻辑简洁，排查问题更高效。

简单来说：Redis网络IO的灵魂是IO多路复用，6.0前纯单线程落地，6.0后多线程仅优化IO读写，命令核心始终单线程。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花