2. Redis 内部架构速览：单线程模型、IO多路复用、事件循环如何影响查询延迟

要理解 Redis 慢查询的根因，首先必须掌握其内部架构的核心设计。Redis 的“快”并非偶然，而是建立在单线程模型、IO 多路复用与高效事件循环三大基石之上。然而，这些设计在带来极致性能的同时，也埋下了延迟敏感性的伏笔。本节将逐一拆解这三个组件，并揭示它们与查询延迟之间的直接关联。

2.1 单线程模型：核心执行路径

Redis 的主要命令处理（如 GET、SET、LPUSH）是在一个主线程中串行执行的。这意味着所有客户端请求在到达命令处理器时，必须排队等待。这种设计消除了锁竞争和上下文切换的开销，是 Redis 高性能的根源之一。

2.2 IO 多路复用：非阻塞网络层

Redis 使用 IO 多路复用技术（如 epoll、kqueue）来高效管理大量客户端连接。它允许单线程同时监控多个 socket 的读写事件，避免了为每个连接创建线程或进程的开销。当没有事件发生时，线程可以阻塞在 epoll_wait 上，释放 CPU。

// 伪代码：Redis 事件循环核心
while (1) {
    // 1. 阻塞等待事件就绪（IO 多路复用）
    num_events = epoll_wait(epfd, events, MAX_EVENTS, -1);

    // 2. 遍历就绪事件
    for (i = 0; i < num_events; i++) {
        // 3. 处理读事件（接收客户端命令）
        if (events[i].events & EPOLLIN) {
            readQueryFromClient(events[i].data.fd);
        }
        // 4. 处理写事件（返回结果给客户端）
        if (events[i].events & EPOLLOUT) {
            sendReplyToClient(events[i].data.fd);
        }
    }
    // 5. 执行其他周期性任务（如过期 Key 清理）
    serverCron();
}

2.3 事件循环：调度的核心

事件循环是 Redis 的“心脏”，它将单线程模型和 IO 多路复用粘合在一起。每次循环迭代包括：等待事件、处理事件、执行时间任务。事件循环的“公平性”和“时效性”直接决定了查询延迟的稳定性。

2.4 三者如何共同影响查询延迟

理解了三者的角色，就可以清晰地看到一条延迟影响链：

1. IO 多路复用 负责高效地发现“谁有数据要读/写”，它本身几乎不产生延迟。
2. 事件循环 负责调度，它从就绪队列中取出事件，交给主线程处理。如果队列为空，循环会阻塞等待。
3. 单线程模型 是真正的执行者。一旦某个命令（如 LRANGE key 0 -1 操作一个百万成员的列表）开始执行，事件循环必须等待它完成，才能处理下一个事件。

2.5 关键结论：慢查询的架构根源