Redis 为什么快？

Redis 的快主要来自数据访问路径短、适合键值操作的数据结构，以及非阻塞网络处理，不能只归因于“单线程”。

热点数据在内存中访问。 常见读写不用每次从磁盘读数据页，也不用像关系查询那样完成连接、执行计划等处理；但持久化和内存压力仍会影响延迟。
按操作选择数据结构与编码。 按键查询、集合成员判断、排名等有对应实现，小集合还可以采用紧凑编码。不同命令的复杂度不同，并非所有操作都是 O(1)。
I/O 多路复用配合事件循环。 可以管理大量连接，按就绪事件处理，避免每个连接独占一个等待线程。常见数据命令主要串行执行，减少了多个执行线程同时修改核心数据结构所需的协调。
通信和批处理减少额外开销。 RESP 协议、连接复用、适当的批量命令与 Pipeline，有助于降低解析、建连、网络往返及系统调用的成本。

所以，Redis 适合大量短小的键值请求；“连接多、请求多”不意味着同一实例的命令都在多核上并行执行。实际速度仍取决于命令、数据量、网络和部署条件。

一个连接暂时没有数据时，服务端不必专门占用线程等待它。事件循环通过多路复用获知哪些连接可以读写，再推进这些连接的处理。只要单次命令足够短，串行执行也可以快速轮转处理很多请求。

“Redis 单线程”通常指核心命令执行方式，不能扩展为整个进程只有一个线程。以 Redis 8.6 的配置为例，启用 I/O 线程后可以分担网络读写和协议解析；此外还有后台任务处理部分文件操作、内存释放等工作。它们并不意味着所有普通数据命令都改为并行执行。

串行模型也有代价：耗时命令会延后其他请求。一次遍历大量元素、返回超大结果，或执行长时间 Lua 脚本，都可能让其他连接排队。I/O 多路复用解决的是连接等待效率，无法消除命令本身的计算成本。

例如需要读取多个互相独立的商品缓存，逐个发送、等待回复，会反复支付网络往返时间。使用合适的批量命令，或通过 Pipeline 连续发送一批命令后读取回复，可以减少这种等待，并摊薄网络系统调用成本。

Pipeline 不会自动让命令并行，也不提供事务隔离。批次过大还会增加回复缓冲、客户端内存占用和等待时间，因此应结合返回数据大小控制批次。如果后一步必须依赖前一步的结果计算，单纯 Pipeline 也不能省掉这次依赖。

先区分客户端等待与服务端执行：连接池排队、网络延迟、大响应传输，都会让一次调用变慢；再结合慢日志、延迟监控、CPU 和内存指标判断是否有高复杂度命令、热键、持久化 fork 或换页等问题。慢日志没有记录，也不等于客户端看到的延迟不存在。

MySQL 也有 Buffer Pool，因此不能把两者概括成“Redis 只用内存，MySQL 每次读磁盘”。两者的数据模型、查询能力、事务与持久化要求不同，性能比较需要明确同一业务操作与可靠性条件。

国内：JavaGuide：Redis 常见面试题：参考内存访问、数据结构、协议和事件循环的介绍，组织正文对 Redis 请求处理路径的解释，并区分核心执行、网络 I/O 与后台任务。
国内：doocs：Redis 单线程模型：通过连接、读取、处理和回复的事件处理过程，解释一个事件循环如何服务多个连接。
国内：小林 coding：Redis 常见面试题：用于解释单线程的适用范围、网络 I/O 与后台工作的分工，以及耗时操作对请求延迟的影响。
国外：Redis：Diagnosing latency issues：用于说明短命令与非阻塞网络模型的关系，以及网络往返、慢命令、fork 和换页造成延迟的条件。
国外：Redis：Redis pipelining：用于解释批处理怎样减少 RTT 和系统调用，并说明回复缓冲与读后再计算的限制。