当前位置：首页 > 问答 > 正文

Redis网络模型怎么实现的，技术细节和运行机制聊聊

太叔访天
问答
2025-12-28 01:43:33
2

关于Redis网络模型如何实现,我们可以把它想象成一个非常高效且专注的餐厅服务模式，这个模型的核心叫做“Reactor模式”，Redis主要使用了单线程版本的Reactor来处理网络请求。

核心思想：为什么是单线程？

很多人一听到单线程可能会觉得性能不行,但Redis偏偏用单线程就实现了极高的并发性能，这背后的道理就像一家只有一个服务员的精品咖啡店，这个服务员（Redis的主线程）非常专业，他的工作流程被设计得极其高效：

避免不必要的开销：多线程虽然能同时做多件事，但线程之间的切换（上下文切换）和协调（锁竞争）会消耗大量的CPU资源，就像餐厅里多个服务员如果协调不好，反而会撞在一起或者争抢同一个订单，Redis的单线程模型彻底避免了这些开销，把所有CPU时间都用在“干活”上。
数据操作的原子性：所有客户端的请求在这个单线程中都是按顺序一个一个执行的，这意味着任何一个命令的执行过程都是不会被其他命令打断的，这天然地避免了复杂的锁机制，保证了数据操作的原子性，简化了实现逻辑。

技术细节：餐厅服务员的完美一天

Redis网络模型怎么实现的，技术细节和运行机制聊聊

Redis的网络模型,主要依赖于操作系统提供的I/O多路复用技术，这个技术名词听起来复杂，但可以理解为餐厅里一个神奇的“订单呼叫器”。

传统的阻塞I/O（蹩脚的服务员）：想象一个没有呼叫器的餐厅，服务员必须站在每个客人旁边，一直等到客人点完单，然后跑去厨房，再等着厨师做完菜，最后才能上菜，在这个过程中，服务员完全被一个客人“阻塞”住了，其他客人只能干等着，这就是传统阻塞模型的低效。
I/O多路复用（高效的呼叫器系统）：Redis的服务员则聪明得多，他不再傻站在某个客人身边，餐厅里安装了一个“万能呼叫器”（I/O多路复用程序，如epoll、kqueue等），这个呼叫器可以监控所有桌位（网络连接）的状态。
- 客人举手点餐 -> 呼叫器亮起“点餐”灯。
- 厨房菜做好了 -> 呼叫器亮起“取餐”灯。

服务员的工作流程变成了一个高效的循环,根据《Redis设计与实现》这本书中的描述，这个循环大致如下：

监听呼叫器：服务员（主线程）什么都不干，就盯着那个“万能呼叫器”，他问呼叫器：“现在有哪些桌位有事情需要我处理？（哪些Socket产生了网络事件）”
处理就绪事件：
- 如果呼叫器显示有新的客人进门（有新的连接请求），服务员就去接待一下，安排好座位（接受连接，创建客户端数据结构），并把这位客人的桌位号注册到呼叫器上，告诉呼叫器：“帮我监控这个桌位，如果他要点餐或者离开就通知我。”
- 如果呼叫器显示有客人举手点餐（客户端发送了命令请求），服务员就过去拿起客人的菜单（从网络套接字中读取数据），但他自己不做菜，他把菜单（命令）按照顺序放在一个任务清单上。
- 如果呼叫器显示厨房的菜做好了（客户端套接字可写，即可以向客户端发送数据），服务员就去查看任务清单的执行结果，然后把做好的菜（命令的返回数据）端给对应的客人。
执行核心任务：在把所有需要“跑腿”的IO事件（接客、拿菜单、上菜）都处理好之后，服务员终于要处理核心业务了，他按照任务清单（命令队列）上的顺序，一个一个地执行命令（比如SET, GET等），因为所有命令都在内存中执行，速度极快。
返回结果：命令执行完毕后，结果并不会立刻发送，服务员会把结果先记下来（放入一个输出缓冲区），等到下一次循环，呼叫器通知他某个客户端的连接可以写入数据时，他再把这些结果发送出去。

运行机制与关键点

事件的分类：Redis将事件分成了两大类：文件事件（也就是网络IO事件）和时间事件（比如定时执行RDB持久化），上面描述的主要是文件事件的处理，在事件循环中，它会优先处理所有已就绪的文件事件，然后再去处理所有到期的时间事件。
高性能的基石：整个模型的高效在于，那个单线程几乎永远不会闲着，它要么在快速地处理IO（借助多路复用器，以非阻塞的方式批量处理），要么在高速地执行内存数据操作，它把耗时的IO等待时间完全“外包”给了操作系统的多路复用机制，自己只负责CPU密集的计算部分。
并非完全的单线程：需要注意的是，从Redis 4.0版本开始，在一些非常耗时的操作上，如异步删除大Key、持久化的某些阶段（如AOF重写），Redis会使用后台线程来处理，以避免它们阻塞主线程，所以准确地说，Redis是 “网络IO和数据操作由单线程处理，部分重型任务由多线程处理” 的混合模型，但这并没有改变其处理客户端命令请求的核心网络模型。