Redis 是单线程还是多线程，集群模式是否相同？

核心回答

要先说明“单线程”指哪一部分。对 Redis Open Source 常见的键值读写命令，一个实例主要由主线程顺序执行；整个 Redis 进程并不只有一个线程。集群则由多个独立实例分片，各节点可以并行工作。

• 命令执行：主线程负责操作键空间和数据结构，普通命令不会因为开启 I/O 线程，就变成多条命令同时修改同一个实例的数据。
• 网络 I/O：Redis 6.0 开始引入多线程 I/O，把部分收发工作交给 I/O 线程；具体分工和配置随版本变化。例如 Redis 8.4 的配置说明包含读、写和协议解析，不能直接套用旧版本“只负责发送响应”的说法。
• 后台任务：AOF 的部分刷盘工作、异步释放对象等可以交给后台线程；后台生成 RDB、重写 AOF 通常还涉及 fork 出的子进程，线程和进程要分开。
• Redis Cluster：不同主节点分别负责一部分哈希槽，各实例仍采用自己的线程模型。集群提升的是多个实例处理不同分片的能力，并没有把一个节点的命令执行自动改成多线程。

所以，“单节点命令主要串行”和“整个集群能并行处理请求”可以同时成立。

为什么单线程还能处理很多连接？

连接多，不等于必须为每条连接创建一个线程。Redis 通过事件循环和 I/O 多路复用，监听多个连接，在连接可读、可写时安排处理，避免为了等待某个连接而一直阻塞。

再加上常见操作在内存中完成、数据结构适合相应操作，单次执行通常较短；主线程也减少了并发访问核心数据结构时的锁竞争。这些是设计取舍，不能推出“Redis 的 CPU 永远不会成为瓶颈”。大集合遍历、复杂集合运算、长脚本都可能长时间占用主线程，让同一实例的其他请求排队。

I/O 线程主要帮助网络处理成为瓶颈的场景。若耗时集中在命令计算，增加 I/O 线程解决不了根因；若慢在网络往返，批量操作、合理使用 Pipeline 也可能更有效。线程数要结合实际版本、CPU、网络和负载评估，没有固定的性能倍数。

集群是否能解决一个热点键的问题？

例如商品信息分散到主节点 A、B、C，客户端根据槽位把请求发往相应节点，三个节点可以分别执行自己的命令，利用多个 CPU 核或多台机器。

但在集群稳定时，一个键所属的槽仍由一个主节点负责。如果绝大多数请求都访问同一个热点键，仅增加主节点，并不会把这个键的写请求自动分给多个节点。需要根据业务考虑本地缓存、读副本、热点拆分或调整数据模型；读副本还要接受复制延迟，拆分则可能改变聚合与一致性处理。

Redis Cluster 的多键操作通常要求键位于同一槽，也不能因为“集群有多个线程”就把跨节点操作当成一次原子操作。

常见追问

命令串行执行，业务就不会有并发问题了吗？

不会。两个客户端分别执行“读取余额→计算→写回”，中间仍可能穿插其他客户端的命令。单条命令的原子执行，不等于多次请求组成的业务流程自动原子。可以优先使用原子命令，必要时用 Lua、事务配合 WATCH 等机制表达完整条件；它们也有各自的适用范围。

异步删除是不是主线程完全不参与？

不是。键从可访问的键空间中移除，与释放它占用的内存是两件事。异步释放把适合移交的内存回收工作交给后台，主线程仍要完成命令处理和必要的结构操作。

参考资料