凌晨盯着监控看板发现一台缓存节点上 8 核的机器只有一个核被跑满其余 7 个核基本闲着而 QPS 已经到了瓶颈客户端的超时开始零星出现。第一次遇到这个场景的人大概率会问同一个问题Redis 不是早就有多线程了吗为什么 CPU 还是只用了一个核这个问题背后牵扯的就是Redis 线程模型的全部关键内容。很多人对“Redis 单线程”和“Redis 多线程”的理解停留在面试题的背诵层面知道有个 io-threads 参数知道命令执行还是单线程但真到调优的时候线程数该设几、为什么设了没效果、多线程到底多线程了哪些环节就说不清楚了。这篇东西我打算把这件事从头到尾讲透从一条命令进入 Redis 到返回客户端中途经过哪些线程、哪些环节并行、哪些环节必须串行哪些参数该在什么场景下动以及我在实际压测和线上调优里踩过的坑。适合已经用过 Redis、想搞清楚它内部执行路径的后端开发也适合正在为容量规划发愁的运维同学基础部分我会用生活化的类比解释不怕你没读过源码。1. 先把“单线程”这个词掰开揉碎1.1 一条命令从进来到回去到底走了哪些路很多人以为“单线程”就是整个 Redis 进程只有一个线程在干活这个理解偏差不小。准确地说Redis 在 6.0 之前处理客户端命令的主流程跑在一个线程里这个线程叫做主线程也叫事件循环线程。它用的是 IO 多路复用Linux 下就是 epoll一个线程同时监听成千上万个 socket 的可读可写事件。你可以把它想象成一个只有一个柜台的服务大厅柜台后面只有一个人但他面前摆了一排信号灯哪盏灯亮了就去处理哪个窗口的请求处理完马上回来看下一盏亮的是哪个。因为没有第二个柜台所以不存在两个客户同时抢同一个抽屉的情况。一条命令的完整路径大致是这样客户端连接建立后主线程在事件循环里感知到 socket 可读把数据读进输入缓冲区然后按 RESP 协议解析出命令名和参数接着查命令表、做参数校验、执行命令对应的函数、修改内存里的数据结构最后把结果编码成 RESP 写回输出缓冲区再刷到 socket 上。这一整条链路上解析、执行、写回都在同一个线程里顺序完成。KEYS *卡住整个实例、一个大 key 的HGETALL让所有请求排队原因就在这里——不是 Redis 不想并行而是它刻意选择了串行。我见过不少同学把这个模型理解成“Redis 性能差”恰恰相反串行是它快的重要原因之一下面单独说。1.2 单线程为什么反而快四个不能忽略的前提第一个前提是纯内存操作。数据全在内存里一次哈希查找、一次跳表定位耗时是纳秒到微秒量级。相比之下一次网络往返、一次磁盘寻道都是毫秒级的。也就是说命令执行这个环节本身耗时就极短多线程并行带来的收益很容易被线程切换、锁竞争的开销吃掉。这就像你去便利店买瓶水收银员一个人扫码收钱足够快再雇两个人反而要互相等对方让出柜台。第二个前提是避免了锁和上下文切换。单线程执行命令所有数据结构天然是线程安全的不需要给每个 dict、每个 ziplist 加互斥锁。省掉的不只是锁本身的开销还有大量因为锁争用导致的线程阻塞和唤醒。你可以回忆一下自己写过多线程程序里那些synchronized块的调试经历就知道省掉这一层有多省心。第三个前提是IO 多路复用。单线程不等于单连接。epoll 让一个线程能同时持有几万个连接的就绪事件真正的瓶颈从来不是“一个线程管不过来连接”而是“一个线程算不过来命令”。在连接数多但单条命令很轻的场景下单线程事件循环的效率高得惊人。第四个前提是命令执行时间可控。绝大多数命令是 O(1) 或 O(log N)耗时在微秒级。只要你不写KEYS *、不对几百万成员的集合做全量操作主线程的队列就不会堆积。Redis 的快本质上是“每个请求都很短 没有排队等待锁”而不是“算得快”。1.3 三个流传很广的误解逐个纠正误解一Redis 进程里只有一个线程。这个说法在 4.0 之前就已经不准确了。那时候已经有后台线程在跑只是它们不参与命令处理所以你从INFO里看不到它们的痕迹。到 6.0 之后线程数量进一步增加。你现在去线上机器上执行top -H -p pid能清清楚楚看到好几个线程名。误解二多线程就是命令并行执行。不是。6.0 引入的多线程 IO并行的只是网络数据的读取和写回命令的执行依然老老实实排队在主线程里。这一点后面会用一整节展开因为它是最容易被误解的地方。误解三单线程所以用不上多核加核没用。加核确实不能直接提升单实例的命令处理能力但多核仍然有用一是多线程 IO 可以用上额外的核来处理网络读写二是后台线程异步关闭文件、AOF 刷盘、惰性释放内存可以分担主线程的压力三是实践中最常见的做法——一台机器上跑多个 Redis 实例用多核分摊不同实例的负载这也是集群部署的常规思路。注意判断一个实例是否“吃满”不要看整机 CPU 使用率要看主线程那个线程的 CPU 占用。整机 12.5% 可能意味着单线程已经 100% 了。2. Redis 6.0 的多线程 IO究竟多线程了什么2.1 边界划得很清楚网络读写并行命令执行串行Redis 6.0 引入的多线程官方叫法是IO 线程I/O threads注意这个命名非常克制它没有叫 worker threads也没有叫 execution threads因为它真的只干 IO 相关的活。开启之后进程里会多出一组线程它们负责两件事把客户端 socket 上的请求数据读进来并做协议解析以及把响应数据写回 socket。而“解析完之后的命令执行”这一步仍然要回到主线程由主线程串行执行。为什么这么设计因为命令执行要改内存里的数据结构一旦并行哈希表扩容、跳表插入、过期键删除这些操作全都要加锁而锁的粒度、死锁风险、内存可见性这些问题会立刻把复杂度抬高一个数量级。更麻烦的是语义问题MULTI/EXEC事务、Lua 脚本、WATCH的原子性保证全都建立在“执行期间没有别的命令插进来”这个前提上。如果命令执行并行化这些特性要么失效要么需要重新设计一整套并发控制机制。相比之下网络读写是天然可以并行的因为每个连接的输入输出缓冲区互相独立分给不同线程处理不存在数据竞争。所以结论很简单多线程解决的是“网络 IO 成为瓶颈”的问题不是“命令执行太慢”的问题。如果你的瓶颈是某条慢命令开再多 IO 线程也没用。2.2 关键参数与配置细节涉及的核心配置项就那么几个打开配置文件或者用CONFIG SET都能改# 开启 IO 多线程设为 1 表示关闭默认值 io-threads 4 # 是否让读请求也走多线程默认 no只对写回做多线程 io-threads-do-reads yes这里有个特别容易踩的坑只设io-threads不设io-threads-do-reads yes读请求仍然在主线程处理。很多同学配了 4 个线程压测发现 QPS 没什么变化就是因为读这一半的活压根没分出去。不同版本对io-threads-do-reads的默认值处理不完全一致改之前先用CONFIG GET io-threads-do-reads确认一下当前实际生效的值别凭记忆。关于线程数的算法官方给的建议是可以参考的io-threads的值表示包含主线程在内的总线程数也就是说设成 4实际是 1 个主线程加 3 个 IO 线程。上限建议不超过 8且不要超过机器可用核数。紧张一点的机器4 核设 2 到 38 核设 616 核以上设 8 就差不多了再往上加收益递减得很厉害。还有一个隐性的前提IO 线程数不能超过实际可用核数。如果你在一台 4 核机器上配了 8 个 IO 线程线程之间会互相抢核上下文切换的开销反而会拖慢整体表现。容器环境下尤其要注意nproc看到的是宿主机核数实际 cgroup 限制可能只有 2 核这种时候按nproc配线程数会出问题。2.3 什么场景该开什么场景开了等于白开判断标准其实不复杂看你的主线程 CPU 里网络读写占了多少。如果客户端连接数很多、单条命令很轻比如大量的GET、SET、HGET且带宽和包量都比较大那么网络读写在主线程里占的比例会很高这时候开多线程 IO 收益明显。反过来说如果你的瓶颈是某些复杂度高的命令或者主线程时间大量花在命令执行和内存分配上那开 IO 线程基本没用。我做过一组对照测试环境是 8 核、万兆网卡、单实例客户端固定 200 个连接、pipeline 深度 16value 大小 256 字节配置QPS示意主线程 CPU说明io-threads 1关闭基准值 100%接近打满单核瓶颈明显io-threads 4不开 reads约 115%接近打满只有写回分担了一部分io-threads 4 reads yes约 180%下降明显读写都分担效果最好io-threads 8 reads yes约 195%进一步下降边际收益开始变小这组数字只是某次实验的相对关系具体到你自己的环境差异会很大别拿去当绝对指标。但规律是稳的开了 reads 才有明显收益线程数从 4 加到 8 收益很小。还有一种情况要注意如果客户端用的是短连接或者每条命令都要等上一条的响应没有 pipeline那网络往返的延迟会掩盖掉多线程 IO 的收益因为主线程大部分时间在等网络而不是在算。这时候该优化的是客户端的使用方式不是服务端线程数。2.4 命令执行为什么不敢并行原子性是底线再展开说说这个“不敢”。Redis 对外承诺的语义里有几条是硬约束单条命令的原子性天然成立因为串行、MULTI/EXEC块内命令连续执行不被打断、Lua 脚本执行期间整个实例被阻塞、WATCH能在EXEC时校验键是否被改过。这几条一旦引入命令级并行全部要重新设计。举个具体的例子一个INCR命令读当前值、加一、写回三步。串行执行时这三步天然不可分割并行执行就必须用 CAS 或者原子指令而 Redis 支持的复杂数据结构比如有序集合的跳表、列表的 quicklist根本没有现成的无锁实现。再比如LPUSH之后紧跟LRANGE客户端期望看到刚推入的元素并行执行下这个顺序就没法保证了。还有一个现实因素单线程让延迟可预测。串行执行意味着一条命令的耗时基本等于它自己的复杂度不会被别的线程抢占。这对延迟敏感的业务很重要。所以官方的态度一直很明确——多线程只做 IO执行层保持单线程这个边界不会轻易动。3. 藏在后台的那些线程不止 IO 线程3.1 bio 线程组异步关闭文件、刷盘、释放内存除了 IO 线程Redis 还有一组后台线程通常叫biobackground I/O线程。它们不参与客户端请求处理只干那些可能阻塞主线程的脏活。按任务类型分主要有这么几类异步关闭文件当你对一个很大的 key 执行UNLINK或者对一个有大量键的库执行FLUSHDB ASYNC时键会先从键空间摘掉真正的内存释放和文件关闭交给后台线程。主线程只是把指针摘走立刻就能继续服务。AOF 刷盘AOF 策略设为everysec时每秒钟的 fsync 操作由后台线程完成主线程不用等磁盘。这也是everysec能在性能和安全性之间取得平衡的原因。如果设成always每次写命令都要同步刷盘那个等待是躲不掉的。惰性释放内存大对象的内存回收放到后台做避免主线程在释放几百万成员的哈希表时被卡住几百毫秒。这三类任务的意义在于把不可预测的耗时操作从关键路径上挪走。它们的共同点是“不影响命令语义只是清理工作”所以可以安全地异步化。3.2 周期任务与内存分配器的影子线程主线程内部还有一个非常有名的函数叫serverCron默认每秒执行hz次hz默认 10也就是每 100 毫秒一次。它负责的东西很多采样并清理过期键、处理客户端的超时、更新统计信息、触发渐进式 rehash 的推进、检查持久化状态、处理集群的故障转移逻辑等等。这个东西跑在主线程里所以如果某次serverCron里干了重活比如过期键采样时碰上一堆大 key你会在延迟曲线上看到一个规律的尖峰。另外如果编译时用的是 jemalloc 作为内存分配器它会自带若干后台线程做内存页的整理和回收。这些线程平时几乎不占 CPU但你从top -H里能看到它们不要以为是自己配错了什么。3.3 用UNLINK替代DEL的真实收益说个很具体的经验。早期我们有个业务用户注销时要清掉这个用户的所有缓存单个 key 里存的是几十万字段的哈希。用DEL删的时候隔三差五就有慢查询告警主线程卡 200 到 500 毫秒不等那段时间整个实例的 P99 直接飙起来。换成UNLINK之后主线程的耗时降到几十微秒剩下的活交给 bio 线程慢慢释放告警基本消失。代价是内存不会立刻归还used_memory曲线会滞后一段时间才掉下来。如果你的监控是按内存水位做扩容判断的要意识到这个滞后别看到内存没降就以为删除失败了。提示FLUSHALL和FLUSHDB也有对应的ASYNC版本在需要清空大实例时优先用异步版本能避免长时间阻塞。4. 动手验证怎么亲眼看到线程模型在工作4.1 第一步把线程数出来先确认实例的线程情况最直接的办法是看进程下的线程列表# 找到 redis 进程号 pgrep -a redis-server # 列出该进程所有线程-H 表示按线程显示 top -H -p pid # 或者直接看 /proc 下的 task 目录线程数一目了然 ls /proc/pid/task | wc -l在 6.0 之后开启 4 个 IO 线程的情况下你通常能看到主线程、若干个 io_thd 开头的线程、若干个 bio 线程再加上内存分配器的线程。数量对不上不用慌先看配置有没有生效redis-cli CONFIG GET io-threads redis-cli CONFIG GET io-threads-do-reads注意CONFIG SET io-threads是支持运行时修改的但改完之后需要一点时间让线程池重新初始化不是立刻生效到下一个命令。4.2 第二步设计一组能说明问题的压测压测最怕的就是变量没控制住。我的习惯是每次只动一个参数其余全部固定并且用taskset把服务端和压测端绑到不同的核上避免互相干扰# 服务端绑到 0-7 核压测端绑到 8-11 核 taskset -c 0-7 redis-server /path/to/redis.conf taskset -c 8-11 redis-benchmark -h 127.0.0.1 -p 6379 \ -c 200 -n 2000000 -t get,set -P 16 -q要观察的指标有三个QPS、主线程的 CPU 占用用top -H看单个线程、以及redis-cli --latency测出来的延迟分布。三个指标要一起看只看 QPS 容易被误导——有时候 QPS 涨了但 P99 延迟也涨了说明是靠排队堆出来的不算真的变好。还有一点压测数据要预热。冷启动的实例第一次访问会触发各种懒加载和内存分配前几十秒的数字没有参考价值。跑够两三轮再取稳定值。4.3 第三步读懂 INFO 里跟线程相关的信号INFO stats和INFO commandstats里的几个字段值得常看指标含义怎么用instantaneous_ops_per_sec当前每秒处理命令数和压测端统计对比差异大说明有丢包或排队total_commands_processed累计命令数算平均负载用rejected_connections因超限被拒的连接数大于 0 说明连接数上限或文件描述符不够latest_fork_usec最近一次 fork 耗时做 RDB 或 AOF 重写时关注数值大说明内存大、fork 慢used_cpu_sys/used_cpu_user主线程 CPU 时间涨得快说明主线程压力大latest_fork_usec这个指标很多人忽略但 fork 是主线程做的内存越大耗时越长几十 GB 的实例 fork 一次卡几百毫秒很常见。这跟线程模型无关但同样是“主线程被阻塞”的典型来源。4.4 客户端侧的配合比服务端调参更重要说句实在话大部分所谓“Redis 性能问题”解决方案在客户端而不在服务端。三个动作的效果远超调 IO 线程数用 pipeline 或者批量命令。一百次网络往返和一次往返带一百条命令差距是数量级的。代价是服务端要一次性处理一批单批别太大几百条一条批就够。控制连接数。不是连接越多越好。几千个连接每个都在跑命令主线程光是处理事件回调就累死了。连接池开几十到几百个配合 pipeline通常比开几千个连接效率高得多。避免大 key 和 O(N) 命令。一个几百万元素的集合做一次全量读取耗时够处理几万条普通命令了。用SCAN系列命令分批遍历用redis-cli --bigkeys定期体检这两个习惯能省掉后面很多麻烦。5. 常见问题与排查实录5.1 一张速查表先顶上现象最可能的原因排查动作配了 io-threads 但 QPS 没涨没开io-threads-do-reads或瓶颈在命令执行看主线程 CPU 分布确认时间花在读上还是算上主线程 CPU 100%整机才 12%单线程执行层打满属正常表现拆实例、加客户端 pipeline、优化慢命令延迟曲线规律性抖动serverCron或持久化 fork 引发看latest_fork_usec错开 RDB 时间删除大 key 后长时间卡顿用了DEL同步释放改UNLINK或FLUSHDB ASYNC开了多线程后报配置错误线程数超过核数限制或版本不支持检查版本降到不超过核数客户端偶发超时但服务端指标正常网络带宽打满或连接数超限看网卡流量、rejected_connections5.2 排查套路从“谁在占时间”开始我排查这类问题的固定顺序是先看主线程在干什么再看有没有慢命令最后才怀疑配置。具体动作第一步SLOWLOG GET 20看有没有明显的慢命令。很多问题一眼就能看出来比如某条ZRANGE带了巨大的范围参数。第二步INFO commandstats看调用次数和平均耗时的分布。哪个命令的usec_per_call高得离谱就是它。第三步redis-cli --latency -h host在客户端侧测延迟和INFO里的数字对比。如果客户端测出来的延迟远高于服务端自报的问题在网络或者客户端这一侧。第四步LATENCY MONITOR或者LATENCY HISTORY查历史事件能看到 fork、过期键清理、命令执行各自造成的延迟尖峰。这套流程走下来绝大多数问题能定位到具体命令或者具体事件很少需要真的去调线程数。5.3 几个我踩过的坑坑一把io-threads当成万能加速键。早期有个业务接口慢就说要开多线程我从压测数据上看主线程时间大部分花在几个复杂度高的命令上开了线程毫无变化。后来把那几个命令改成批量缓存问题才解决。线程模型解决的是 IO 瓶颈不是算法瓶颈。坑二容器里按宿主机核数配线程。有一次改动之后实例表现得不如从前查了半天发现容器被限制在 4 核而配置文件里写了io-threads 8。线程之间抢核切换开销很大。容器环境一定要看 cgroup 限额不是看nproc。坑三以为后台线程会立刻释放内存。用UNLINK删了几百万个键看used_memory没降以为删除失败又执行了一遍。实际上后台线程慢慢释放需要时间看INFO memory里的lazyfree_pending_objects就能知道还有多少在排队。坑四开了多线程 IO 却没检查客户端版本。有些老版本的客户端在服务端开启多线程读之后遇到特定响应格式会解析异常。上线前务必在同一套客户端版本上做完整的兼容性验证别只在压测工具里跑通就放行。6. 我个人的配置取舍与几点建议说说我在实际项目里的选择。大部分业务实例我倾向于不开多线程 IO保持默认的单线程处理原因很朴素瓶颈通常不在网络侧而在几个没优化好的命令和客户端用法上先把这些收拾干净收益比调线程数大得多而且风险低、不用改配置、不用重启验证。真正会去开多线程 IO 的是那些连接数极多、命令极轻、带宽压力大、并且已经确认主线程时间大量花在网络读写上的场景比如网关型缓存、高频计数服务这类。一旦决定要开我的做法是先把io-threads设成 4 再加io-threads-do-reads yes压测看效果如果主线程 CPU 还有明显下降空间再试 6 或 8但一定要在容器核数限额内。观察窗口至少跑二十分钟看的是 P99 和主线程 CPU不是峰值 QPS。改配置的地方优先用配置文件重启而不是CONFIG SET因为运行时改线程池的行为在不同版本上细节有差异重启验证更踏实。还有一个习惯值得分享把INFO里的主线程 CPU 时间和 QPS 做成同一条曲线放在一起看。当 QPS 平缓而主线程 CPU 一直往上走通常说明单条命令的平均耗时在变长——可能是聚合 key 变大了可能是某个集合持续增长这种趋势比一次性的延迟尖峰更值得警惕因为它是容量到顶的前兆。真正到顶的那天方案不是继续调线程模型而是分片、拆实例、或者把热点数据往更靠近调用方的地方挪。最后提一个容易忽略的延展方向如果你正在做容量规划别只盯着单实例的 QPS 上限而要算清楚“单实例在不触发慢查询的前提下能承载多少条复杂度各异的命令”。我一般会用commandstats的分布按业务真实的命令比例混跑压测得出的上限比纯GET/SET压出来的数字要低不少但也更接近真实。