3. Redis 连接原理：单线程模型、IO多路复用、客户端与服务端连接建立过程
理解 Redis 的连接原理，是掌握连接池水位管理的前提。本章深入剖析 Redis 单线程模型为何能支撑高并发、IO 多路复用的具体实现，以及客户端与服务端从 TCP 握手到认证完成的完整链路。
3.1 单线程模型：为什么一个线程能扛住 10 万+ QPS？
Redis 的核心处理逻辑（命令读取、解析、执行、响应）运行在一个主线程中。这种设计并非性能瓶颈，反而在高并发场景下带来了显著优势：
- 无锁竞争：所有操作串行执行，天然避免锁开销和上下文切换。
- 纯内存访问：数据全部在内存中，读写延迟通常在微秒级。
- 非阻塞 IO：通过 IO 多路复用处理海量连接，主线程只处理就绪事件。
- 避免 CPU 争抢：单线程避免了多核 CPU 的缓存失效和线程切换损耗。
关键指标：Redis 官方基准测试显示，单实例在 1Gbps 网络下，GET/SET 操作可达 10万+ QPS。瓶颈通常不在 CPU，而在网络带宽和内存带宽。
3.2 IO 多路复用：单线程如何管理成千上万个连接？
Redis 使用 IO 多路复用（select / epoll / kqueue）同时监听多个 socket 文件描述符。主线程只处理那些“已就绪”的 socket，避免了阻塞等待。
| 复用机制 | 平台 | 特点 | Redis 默认选择 |
|---|---|---|---|
| epoll | Linux | 事件驱动，O(1) 复杂度，支持百万级 fd | 首选 |
| kqueue | macOS / FreeBSD | 类似 epoll，高效事件通知 | 备选 |
| select | 通用 POSIX | O(n) 轮询，fd 上限 1024 | 兜底 |
Redis 的 aeEventLoop 事件循环核心流程：
- 调用
aeApiPoll（底层封装 epoll_wait）等待事件就绪。 - 遍历就绪事件列表，调用对应的文件事件处理器（如 readQueryFromClient）。
- 执行命令，写响应到输出缓冲区。
- 注册写事件，将响应数据发送回客户端。
实战理解：IO 多路复用让 Redis 主线程“一夫当关”，同时监听数千个客户端连接。连接本身不消耗 CPU，只有真正有数据到达时才触发处理。这也是连接池可以维持大量空闲连接的理论基础。
3.3 客户端与服务端连接建立过程
一个 Redis 连接的完整生命周期包含以下步骤：
| 阶段 | 动作 | 涉及组件 | 耗时参考 |
|---|---|---|---|
| 1. TCP 三次握手 | 客户端 connect → 服务端 accept | 内核 TCP 栈 | 0.1~1ms（同机房） |
| 2. 创建文件事件 | aeCreateFileEvent 注册读事件 | aeEventLoop | < 0.01ms |
| 3. 读取命令 | readQueryFromClient 读取 socket 缓冲区 | 网络 IO | 取决于数据量 |
| 4. 命令解析 | processInlineBuffer / processMultibulkBuffer | 主线程 | < 0.01ms |
| 5. 命令执行 | call → lookupCommand → execCommand | 主线程 | 0.001~0.1ms |
| 6. 响应写入 | addReply → writeToClient（注册写事件） | 主线程 + 内核 | < 0.01ms |
| 7. 连接关闭 | freeClient → 删除文件事件 → 关闭 socket | 主线程 | < 0.01ms |
避坑提示：每次新建连接都要经历完整的 TCP 三次握手 + Redis 命令交互。在 QPS 上万的高并发场景下，频繁创建/销毁连接会显著增加延迟和系统开销。这也是连接池存在的核心价值——复用已建立的连接，避免重复握手。
3.4 连接池与单线程模型的适配
理解连接原理后，连接池的设计要点就清晰了：
- 连接复用：避免每次请求都经历 TCP 三次握手和 Redis 连接创建/销毁。
- 水位控制：连接数过多会占用服务端内存（每个连接约 4KB 输出缓冲区 + client 结构体），过少则导致请求排队。
- 空闲检测：Redis 默认
timeout配置（如 300 秒）会关闭空闲连接，连接池需配合心跳保活。 - 异常处理：网络闪断或 Redis 重启会导致连接失效，连接池需具备自动重连和健康检查机制。
核心结论：Redis 单线程 + IO 多路复用模型，使得连接池可以维持数百甚至数千个空闲连接而几乎不消耗 CPU。连接池的水位管理，本质是在“避免频繁建连”和“控制服务端资源占用”之间找到平衡点。