Redis 的高性能引擎 Reactor 详解与基于 Go 手写 Redis

前言

我们常常听到一个说法："Redis 是单线程的"。这总会让人产生一个疑问：一个单线程的程序，如何能处理成千上万的并发连接，实现每秒数十万的请求操作？难道它不会成为性能瓶颈吗？

这个说法其实只对了一半。Redis 的核心命令处理和数据操作确实是单线程的 ，但其高效的网络 I/O 处理却依赖于另一种强大的设计模式------Reactor 模式。正是这两者的精妙结合，造就了 Redis 的高性能神话。本文将深入 Redis 的源码层面，为你揭开 Reactor 模式的神秘面纱。

一、Redis单线程辨析

"Redis 是单线程的" 这个标签既正确又具有误导性。它正确是因为，从客户端的 SET、GET 等命令的执行，到内存中数据结构的增删改查，所有这些操作都在一个主线程中顺序执行，这使得 Redis 避免了多线程环境复杂的锁竞争问题，实现了简单而高效的数据操作。

而其误导性在于，这个说法容易让人产生一个过于简化的理解：认为整个 Redis 服务端只有一个线程在处理所有事情，包括网络读写、命令解析、数据操作等，并误以为它是通过"忙轮询"这种低效的方式来工作的。

实际上，Redis 的高性能秘诀在于其精巧的架构设计。它采用 Reactor 模式 ，由一个主线程承担最核心的工作 ，但这个主线程并不笨拙地等待。它利用操作系统提供的高效 I/O 多路复用技术（如 Linux 的 epoll、MacOS的kqueque），像一个超级调度员 一样同时监听数万个网络连接。这样一来，一个主线程就足以高效地处理所有网络 I/O 和命令执行，这正是 Reactor 模式的威力。

此外，在现代 Redis 版本中，为了进一步提升性能，还会在后台运行一些额外的线程来处理诸如数据持久化、异步删除等不太紧急的任务，但这并不改变其命令处理核心是单线程的本质。

二、什么是 Reactor 模式？

Reactor 模式，中文常译为"反应器模式"或"分发者模式"，是一种处理并发服务请求的事件驱动（Event-Driven）设计模式。

它的核心哲学是："不要用你的代码去等待事件，而是让系统在事件就绪时通知你。"（Don't call us, we'll call you）。

一个生动的比喻

想象一家餐厅：

• 传统阻塞模式 (BIO)：一个服务员服务一桌客人。客人点菜时，服务员必须一直站在桌旁等待，直到客人决定好。这期间他不能为其他桌服务。这种模式资源利用率极低。
• Reactor 模式 ：一个服务员（Reactor ）负责接待所有客人。他不停地在餐厅里巡逻（事件循环 ）。当有新客人来时（新连接事件 ），他安排入座。当某桌客人举手示意点菜时（读事件 ，数据可读），他过去记录点单，然后把单子交给后厨（处理函数 ）。当菜做好了放在出餐口（写事件，数据可写），他再把菜端给客人。这个服务员永远不会因为"等待"而空闲，效率极高。

核心组件

Reactor 模式主要由以下几个组件协作而成：

• Handle（句柄）： 表示一个资源，通常是网络连接（Socket）。
• Synchronous Event Demultiplexer（同步事件多路复用器） ： 也就是 epoll、kqueue 等系统调用。它的作用是阻塞等待，直到一个或多个 Handle 上有事件发生。
• Initiation Dispatcher（初始分发器） ： 这是模式的核心，即事件循环。它负责注册和移除事件处理器，并调用事件多路复用器来等待事件，然后将事件分派给对应的回调函数。
• Event Handler（事件处理器）： 定义处理事件接口的回调函数。
• Concrete Event Handler（具体事件处理器）： 实现事件处理接口，包含处理特定事件的业务逻辑。

三、Redis 中的 Reactor 模式实现

Redis 在自己的网络事件库 ae.c (Asynchronous Events) 中完美实现了 Reactor 模式。其核心架构可以通过下图一目了然：

flowchart TD subgraph MainReactor["Redis 主线程 (单线程 Reactor)"] AELoop[aeEventLoop
事件循环] AEApi[aeApiPoll
封装epoll/kqueue] end Client1[客户端 1] -->|网络连接| ListenSocket[监听 Socket] Client2[客户端 2] -->|网络连接| ListenSocket ClientN[客户端 N] -->|网络连接| ListenSocket ListenSocket -->|注册读事件| AEApi AEApi -->|阻塞等待
返回就绪事件列表| AELoop AELoop -->|分发新连接事件| AcceptHandler[acceptTcpHandler
连接应答处理器] AELoop -->|分发数据可读事件| ReadHandler[readQueryFromClient
命令请求处理器] AELoop -->|分发数据可写事件| WriteHandler[sendReplyToClient
命令回复处理器] AcceptHandler -->|"1. accept() 连接
2. 注册客户端读事件"| AELoop ReadHandler -->|"1. read() 数据
2. 解析命令
3. 将命令排队"| RedisCore[单线程命令处理核心] RedisCore --> |"4. 将回复存入缓冲区"| WriteBuffer[客户端输出缓冲区] ReadHandler -->|"5. 注册客户端写事件"| AELoop WriteBuffer --> |待发送的数据| WriteHandler WriteHandler -->|"1. write() 发送数据
2. 若未发完, 再次注册写事件"| AELoop

下面我们来拆解图中的每一个核心部件。

1. 事件多路复用器 (aeApiPoll)

Redis 为不同的操作系统封装了其最高效的多路复用机制：

• Linux → epoll
• macOS/BSD → kqueue
• Solaris → evport
• 其他 → select (性能最差，作为保底方案)

在 ae_epoll.c, ae_kqueue.c 等文件中，Redis 为这些不同的实现提供了统一的 API。核心函数 aeApiPoll 就是对 epoll_wait 或 kevent 的封装。它的作用就是高效地、阻塞地监视所有被注册的 Socket，直到它们中有事件发生（或超时）。

2. 事件循环 (aeMain)

事件循环是 Reactor 模式的核心，它在 aeMain 函数中实现，这是一个简化的无限循环：

// 伪代码
void aeMain(aeEventLoop *eventLoop) {
    eventLoop->stop = 0;
    while (!eventLoop->stop) {
        // 1. 处理时间事件（如过期Key清理）
        // 2. 处理文件事件（网络I/O）
        aeProcessEvents(eventLoop, AE_ALL_EVENTS);
    }
}

而 aeProcessEvents 函数是关键中的关键：

1. 调用 aeApiPoll 函数，阻塞等待任何被监听的 Socket 上有事件发生。
2. aeApiPoll 返回后，函数会得到一个就绪事件列表。
3. 遍历这个就绪列表，根据事件类型（读/写），调用预先绑定在相应 Socket 上的回调函数（rfileProc 或 wfileProc）。

3. 、事件处理器 (Event Handlers)

事件处理器是真正干活的地方，Redis 主要定义了三个核心处理器：

• 连接应答处理器 (acceptTcpHandler)：

  • 绑定在 ：监听 Socket（Server Socket）的可读事件上。
  • 职责 ：当监听 Socket 有可读事件时（意味着有新的客户端连接请求），此函数被调用。它执行 accept() 系统调用接受连接，创建客户端数据结构，并将新客户端的 Socket 注册到事件循环中，监听其可读事件 ，并绑定下一个处理器：readQueryFromClient。

• 命令请求处理器 (readQueryFromClient)：

  • 绑定在 ：所有客户端 Socket 的可读事件上。
  • 职责 ：当客户端 Socket 有可读事件时（意味着客户端发送了命令数据），此函数被调用。它负责：
    1. read() 读取客户端发送的数据。
    2. 解析数据，遵循 Redis 序列化协议（RESP）。
    3. 调用 processCommand() 函数执行命令（注意：执行命令是在单线程中完成的！）。
    4. 命令执行后，会将回复数据存入客户端的输出缓冲区。
    5. 最后，注册该客户端 Socket 的可写事件，以便将回复发送回去。

• 命令回复处理器 (sendReplyToClient)：

  • 绑定在 ：客户端 Socket 的可写事件上（由上一个处理器动态注册）。
  • 职责 ：当客户端 Socket 有可写事件时（意味着内核的发送缓冲区有空闲空间），此函数被调用。它负责将输出缓冲区中的数据通过 write() 系统调用发送给客户端。如果一次没有发送完（比如数据量很大），它会保留剩余数据，并等待下一次可写事件再次被调用，直到所有数据发送完毕。

通过这三个处理器的精密协作，Redis 成功地将网络 I/O 处理与命令执行解耦，并用异步事件驱动的方式串联起来。

四、为什么选择单线程 Reactor？权衡与哲学

Redis 的核心选择是：使用单线程处理命令，但使用 Reactor 模式处理网络 I/O。这是一个经过深思熟虑的权衡。

优点：

1. 避免锁开销：单线程操作所有数据，天然线程安全，完全不需要昂贵的锁机制（互斥锁、同步块等），极大地简化了实现并提升了性能。
2. 简单高效：代码复杂度低，没有线程上下文切换和竞争带来的额外开销。
3. 保证原子性：每个命令的执行都是原子的，不会被打断，这对开发者来说是一个非常简单清晰的模型。

缺点/权衡：

1. CPU 成为瓶颈 ：如果某个命令执行过慢（如复杂度为 O(N) 的 KEYS * 命令），会阻塞整个事件循环，导致所有后续请求都被延迟。
2. 无法充分利用多核：单个主线程只能运行在一个 CPU 核心上。

Redis 6.0 的多线程 I/O

为了克服上述第二个缺点，Redis 6.0 引入了多线程 I/O。但必须清晰地理解：

• 多线程只用于处理网络 I/O（读取请求和写回响应）。
• 命令的解析和执行依然是单线程的。

具体来说，主线程在通过 aeApiPoll 获取到就绪事件后，会将读取和解析命令、以及发送回复的任务，交给多个 I/O 线程去并行处理，而它自己始终是命令执行的唯一线程。这有效地利用了多核 CPU 来缓解网络 I/O 瓶颈，同时依然保留了单线程命令执行的所有优点。

五、Go 语言实现一个基于Reactor模式的简易版Redis

源码地址

Go 语言实现一个基于Reactor模式的简易版Redis

使用说明

1. 克隆代码（目前只支持MacOs系统）

git clone https://github.com/shgang97/redis-go.git

2. 编译启动redis-go服务器

cd redis-go
go run main.go

3. 重新打开一个终端，连接上redis-go服务器

# 使用telnet连接
telnet 127.0.0.1 6379

4. 使用 redis-go

# 发送Redis命令

ping 
# 添加 k-v
set k1 hello
get k1
# 删除 k1
del k1
# 再次获取返回-1
get k1
# 退出
quit

源码解读

1. 事件循环 (Event Loop) ：在 server.go 的 eventLoop 方法中，不断调用 unix.Kevent 等待事件发生。这是 Reactor 模式的核心。

2. 事件注册 ：服务器启动时，监听 socket 被注册到 kqueue 关注读事件（新连接）。当新连接接受后，客户端 socket 也被注册到 kqueue 关注读事件和写事件。

3. 回调处理 ：当事件发生时，事件循环根据事件类型调用相应的回调函数（OnAccept、OnRead、OnWrite），这些回调函数在 handler.go 中实现。

4. 数据流：

   • OnAccept：接受新连接，创建客户端对象，并注册到 kqueue 关注读事件。
   • OnRead：读取客户端数据，解析命令（使用 RESP 协议），处理命令（如 SET、GET），并调度写事件（通过 ScheduleWrite 方法）。
   • OnWrite：将响应数据写入客户端 socket。

5. 数据库 ：使用 database.Database （一个 sync.Map）存储键值对数据，支持并发访问。

六、总结

Redis 的高性能并非魔法，而是其精妙架构设计的必然结果。通过 Reactor 模式 ，它成功地用单个线程协调管理了数万个网络连接上的 I/O 事件，将 CPU 从耗时的 I/O 等待中解放出来，让其全力投入到最核心的命令执行和内存操作中。

其设计精髓在于：将高并发的网络 I/O 事件转换为一个个有序的事件回调，由一个单线程的事件循环串行处理，从而实现了无锁化的命令处理。

理解 Reactor 模式，不仅让我们能更深入地理解 Redis，也为我们自己设计高性能、高并发的网络服务提供了绝佳的范本。