redis所有数据操作命令均由主线程串行执行；6.0的多线程仅用于网络i/o（read/write），不改变命令执行模型，get/set等仍原子性逐条执行，原子性与阻塞行为均由单线程保障。

所有数据操作命令都由主线程串行执行

Redis 6.0 的多线程仅作用于网络 I/O（read 和 write 系统调用），不改变命令执行模型。这意味着：任何涉及键值对读写、计算、结构遍历的操作，全部仍在主线程中逐条、原子地执行。

GET、SET、HGETALL、ZRANGE 等命令不会并行化

这些命令的执行路径始终是：I/O 线程完成协议解析 → 命令入队 → 主线程从队列取命令 → 执行 → 生成响应 → I/O 线程回写。即使开启 8 个 io-threads，SET key "value" 和 GET key 也绝不会被两个线程同时执行。

• GET/SET：内存查写，无锁，但串行
• HGETALL：遍历整个哈希表，耗时随元素数线性增长，期间阻塞其他命令
• ZRANGE（含 WITHSCORES）：有序集合范围查询，O(log N + M) 时间，仍占主线程
• LRANGE list 0 -1：列表全量拉取，大列表会显著拖慢队列消费速度

事务、Lua 脚本、EXPIRE 类命令同样无法绕过主线程

Redis 的原子性保障完全依赖单线程调度。以下操作看似“复合”，实则仍是主线程内闭环执行：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• MULTI/EXEC 块：所有 queued 命令在 EXEC 时由主线程一口气执行完毕
• EVAL 脚本：整个 Lua 运行环境在主线程中独占执行，脚本内调用的 redis.call("GET",...) 不触发线程切换
• EXPIRE/PEXPIRE：键过期逻辑与数据访问耦合，必须和 GET 同步判断，不能异步
• INCR、DECRBY：数值运算+存储，全程无锁但强串行

容易误以为“多线程加速”的地方其实是假象

看到 QPS 提升就认为命令变快了？不是。真正受益的是连接密集、请求包小、响应快的场景——比如大量 PING 或短 GET。但只要出现以下任一情况，主线程瓶颈立刻暴露：

• 单次命令执行时间 > 1ms（如 SCAN 全库、SINTER 大集合交集）
• 客户端使用长 pipeline（例如一次发 1000 条命令），命令队列堆积导致延迟毛刺
• 开启 io-threads-do-reads yes 后，I/O 线程解析更快，反而让命令队列更早饱和
• 后台线程（如 lazyfree）正在异步删大 key，虽不抢主线程 CPU，但会加剧内存带宽竞争

最常被忽略的一点：io-threads 数量不能超过 CPU 核心数减一（预留主线程），且 > 8 后收益急剧衰减；盲目设为 16 可能因线程争抢 cache line 反而降低吞吐。