1.1 Redis 核心架构与数据模型
Redis 之所以能在企业级热点削峰场景中保持亚毫秒级响应，其底层架构设计是关键。本章从单线程模型、内存数据结构与 IO 多路复用三个维度，拆解 Redis 高性能的根因。
1.1.1 单线程模型：无锁化的事件循环
Redis 的主要处理逻辑（命令解析、数据操作、响应发送）运行在单一线程中。这意味着所有客户端请求在核心路径上串行执行，天然避免了多线程下的锁竞争、上下文切换和 CPU 缓存失效开销。
核心优势：单线程 + 纯内存访问 = 无锁化 + 低延迟。在 CPU 未成为瓶颈时，单线程模型足以支撑 10万+ QPS。
单线程模型并非“单进程”。Redis 会通过 bio 后台线程处理耗时的文件关闭、AOF 刷盘、大 key 异步删除等操作，避免阻塞主线程。
| 特性 | 单线程模型 | 多线程模型（对比） |
|---|---|---|
| 锁竞争 | 无 | 存在，需加锁同步 |
| 上下文切换 | 无 | 频繁切换，开销大 |
| CPU 缓存命中率 | 高（数据局部性好） | 低（线程切换导致缓存失效） |
| 实现复杂度 | 低，易于维护 | 高，需处理竞态条件 |
| 瓶颈场景 | CPU 密集型操作（如慢查询） | IO 密集型或大量计算 |
避坑提示：单线程模型下，任何一个慢查询都会阻塞后续所有请求。企业调优的首要任务就是消除慢查询，避免“一颗老鼠屎坏了一锅粥”。
1.1.2 内存数据结构：从全局哈希表到编码优化
Redis 所有数据都存储在内存中，其核心是一个全局哈希表（dict）。每个键值对通过哈希算法定位到对应的哈希桶，实现 O(1) 平均访问复杂度。
为了在内存效率和操作速度之间取得平衡，Redis 对每种数据类型都设计了多种底层编码（encoding）。当数据量小或元素长度短时，使用更紧凑的编码；当数据量增长后，自动切换为更通用的结构。
| 数据类型 | 底层编码（小数据量） | 底层编码（大数据量） | 切换条件 |
|---|---|---|---|
| String | int / embstr | raw | 长度 > 44 字节 |
| List | ziplist | quicklist | 元素数 > 512 或单元素 > 64 字节 |
| Hash | ziplist | hashtable | 字段数 > 512 或字段值 > 64 字节 |
| Set | intset | hashtable | 元素数 > 512 或含非整数元素 |
| Sorted Set | ziplist | skiplist + hashtable | 元素数 > 128 或元素值 > 64 字节 |
调优要点：合理控制元素大小和数量，让数据尽量保持在紧凑编码（ziplist/intset）内，可显著降低内存占用并提升遍历效率。热点 key 尤其需要关注编码类型。
1.1.3 IO 多路复用原理：单线程如何服务万级连接
Redis 使用 IO 多路复用技术，让单线程同时监听多个 socket 上的可读/可写事件。操作系统内核提供 select/epoll（Linux）/kqueue（macOS）等系统调用，Redis 封装为统一的 aeEventLoop 事件驱动框架。
工作流程如下：
- 注册事件：主线程将每个客户端连接的 socket 注册到事件循环中，监听
AE_READABLE事件。 - 内核轮询：主线程调用
epoll_wait阻塞等待，内核返回就绪的文件描述符列表。 - 事件分发：Redis 遍历就绪列表，调用对应的事件处理器（如
readQueryFromClient）。 - 串行执行：处理器在单线程中执行命令，将结果写入输出缓冲区，并注册
AE_WRITABLE事件。 - 写回响应：当 socket 可写时，事件循环触发写处理器，将缓冲区数据发送给客户端。
性能关键：epoll 的时间复杂度为 O(1)，仅返回活跃连接，避免了
select 的 O(N) 遍历开销。这是 Redis 在万级并发下仍能保持低延迟的基石。
1.1.4 三者的协同关系
单线程模型、内存数据结构、IO 多路复用三者并非孤立，而是紧密配合：
- IO 多路复用解决网络 IO 等待问题，让单线程能高效管理大量客户端。
- 内存数据结构保证数据操作在纳秒级完成，避免单线程因计算耗时过长而阻塞。
- 单线程模型消除并发冲突，让 IO 和数据结构操作可以无缝衔接，无需加锁。
三者共同构成了 Redis “事件驱动 + 内存计算 + 无锁串行”的高性能三角，这也是企业热点削峰场景选择 Redis 作为缓存/限流核心的根本原因。