Redis线程模型(转载)

本文深入解析Redis如何利用单线程模型实现高并发及高性能。通过IO多路复用机制,Redis能同时监听并处理多个socket事件,有效避免多线程上下文切换开销,确保纯内存操作下的高效响应。文章详细介绍了文件事件处理器的工作流程,包括连接应答、命令请求和回复处理,揭示了Redis单线程模型背后的机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

摘要: 单线程支撑高并发高性能,转载自 石杉码农学院

1)文件事件处理器

redis基于reactor模式开发了网络事件处理器,这个处理器叫做文件事件处理器,file event handler。这个文件事件处理器,是单线程的,redis才叫做单线程的模型,采用IO多路复用机制同时监听多个socket,根据socket上的事件来选择对应的事件处理器来处理这个事件。

如果被监听的socket准备好执行accept、read、write、close等操作的时候,跟操作对应的文件事件就会产生,这个时候文件事件处理器就会调用之前关联好的事件处理器来处理这个事件。

文件事件处理器是单线程模式运行的,但是通过IO多路复用机制监听多个socket,可以实现高性能的网络通信模型,又可以跟内部其他单线程的模块进行对接,保证了redis内部的线程模型的简单性。

文件事件处理器的结构包含4个部分:多个socket,IO多路复用程序,文件事件分派器,事件处理器(命令请求处理器、命令回复处理器、连接应答处理器,等等)。

多个socket可能并发的产生不同的操作,每个操作对应不同的文件事件,但是IO多路复用程序会监听多个socket,但是会将socket放入一个队列中排队,每次从队列中取出一个socket给事件分派器,事件分派器把socket给对应的事件处理器。

然后一个socket的事件处理完之后,IO多路复用程序才会将队列中的下一个socket给事件分派器。文件事件分派器会根据每个socket当前产生的事件,来选择对应的事件处理器来处理。

2)文件事件

当socket变得可读时(比如客户端对redis执行write操作,或者close操作),或者有新的可以应答的sccket出现时(客户端对redis执行connect操作),socket就会产生一个AE_READABLE事件。

当socket变得可写的时候(客户端对redis执行read操作),socket会产生一个AE_WRITABLE事件。

IO多路复用程序可以同时监听AE_REABLE和AE_WRITABLE两种事件,要是一个socket同时产生了AE_READABLE和AE_WRITABLE两种事件,那么文件事件分派器优先处理AE_REABLE事件,然后才是AE_WRITABLE事件。

3)文件事件处理器

如果是客户端要连接redis,那么会为socket关联连接应答处理器
如果是客户端要写数据到redis,那么会为socket关联命令请求处理器
如果是客户端要从redis读数据,那么会为socket关联命令回复处理器

4)客户端与redis通信的一次流程

在redis启动初始化的时候,redis会将连接应答处理器跟AE_READABLE事件关联起来,接着如果一个客户端跟redis发起连接,此时会产生一个AE_READABLE事件,然后由连接应答处理器来处理跟客户端建立连接,创建客户端对应的socket,同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来。

当客户端向redis发起请求的时候(不管是读请求还是写请求,都一样),首先就会在socket产生一个AE_READABLE事件,然后由对应的命令请求处理器来处理。这个命令请求处理器就会从socket中读取请求相关数据,然后进行执行和处理。

接着redis这边准备好了给客户端的响应数据之后,就会将socket的AE_WRITABLE事件跟命令回复处理器关联起来,当客户端这边准备好读取响应数据时,就会在socket上产生一个AE_WRITABLE事件,会由对应的命令回复处理器来处理,就是将准备好的响应数据写入socket,供客户端来读取。

命令回复处理器写完之后,就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系。

5)总结
为啥redis单线程模型也能效率这么高?
1)纯内存操作
2)核心是基于非阻塞的IO多路复用机制
3)单线程反而避免了多线程的频繁上下文切换问题

在这里插入图片描述

### Redis 线程模型的工作原理 #### 单线程模型Redis 6.0 之前) 在 Redis 6.0 版本发布前,其采用的是完全基于单线程的处理模型。这意味着所有的客户端请求都由同一个主线程负责接收、解析以及响应[^1]。尽管如此,由于 Redis 结合了高效的内存管理和 I/O 多路复用技术,即使是在高并发环境下也能保持良好的性能表现。 具体来说,Redis 的单线程并非单纯地按顺序逐一执行每个请求,而是通过事件驱动的方式运行。在这种模式下,Redis 利用了操作系统提供的 I/O 多路复用功能(如 `epoll` 或 `kqueue`),从而可以同时监听多个文件描述符上的事件并作出快速反应[^3]。 #### 多线程模型(自 Redis 6.0 起) 然而,随着现代计算机网络硬件的发展速度加快,原有的单线程架构逐渐暴露出一些局限性——尤其是当面对极高吞吐量的数据传输需求时,单一工作线程可能无法及时完成所有必要的网络读写操作。因此,在 Redis 6.0 中引入了一种新的多线程机制来优化这部分流程[^4]。 新加入的多线程特性主要用于分担原本属于主线程的部分职责,即 **网络 IO 数据的读取与写入** 和 **协议解析** 这两方面内容。这些任务被分配给若干个辅助线程去独立完成;而核心逻辑部分,比如实际命令的具体执行过程,则依旧保留于原来的那个唯一存在的主线程之中不变。 这样的设计既解决了因频繁进行低效阻塞型 IO 导致的整体效率下降问题,又很好地继承了过去版本里简单明了易于维护的优点,同时也规避掉了可能出现的各种复杂的同步锁竞争状况等问题[^2]。 以下是简化版伪代展示如何区分不同类型的作业交给不同的组件处理: ```python def handle_client_request(client_socket): data = read_from_network_thread_pool(client_socket) # 使用多线程池读取数据 command, args = parse_protocol(data) # 解析协议仍可放在主线上或子线程视情况定 result = execute_command_in_single_main_thread(command, *args) # 所有命令最终交予单一线程执行 write_to_network_thread_pool(result, client_socket) # 将结果回传利用多线程写入 ``` 以上就是关于 Redis 不同阶段所采取的不同线程策略及其背后的设计考量概述。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值