redis 7.0.12+ 从节点 rdb 加载仍单线程，因默认未启用 rdb-loading-threaded yes；需显式开启且 io-threads≥2 才能启用多线程解析，仅作用于全量同步 loading:1 阶段。
Redis 7.0.12+ 从节点 RDB 加载仍单线程？检查 rdb-loading-threaded 是否启用
Redis 7 默认不开启 RDB 多线程解析，即使配置了 io-threads 4，rdb-loading-threaded 仍为 no。此时从节点全量同步时，主线程会独占解析整个 RDB 文件，CPU 持续跑满，加载耗时与文件大小强相关。
必须显式设置：rdb-loading-threaded yes。该选项无额外参数，也不依赖 io-threads 的具体数值——但前提是 io-threads ≥ 2，否则工作线程数为 0，实际仍退化为单线程。
- 仅对从节点全量同步阶段生效（即
INFO replication中loading:1期间） - 不影响主节点生成 RDB 或从节点的增量同步（psync）
- 配置后重启从节点，日志中应出现
Enabled threaded RDB loading with N workers
io-threads 设为 2 却没效果？确认工作线程是否真正激活
io-threads 的值不是“总线程数”，而是“IO 线程池总容量”。Redis 主线程始终承担事件分发和关键逻辑，真正用于并行工作的线程数 = io-threads - 1。设 io-threads 1 时，工作线程数为 0；设 io-threads 2，才获得 1 个可用工作线程——这是最低有效配置。
验证方式：
- 启动后执行
INFO threads，观察io_threads_active是否 > 0（同步过程中才可能非零） - 用
perf top -p $(pgrep redis)查看热点函数：若仍大量命中rdbLoadStringObject或raxInsert在main线程，说明未分流 - 不要只看
top的 CPU 总使用率——多核负载均衡后，单核峰值下降才是并行生效的直接证据
RDB 文件太大，光开多线程还不够？先砍掉加载负担
即使启用了多线程解析，如果从节点启动时仍要加载本地残留的 dump.rdb 或 appendonly.aof，主线程会在解析前就被卡死在磁盘读取阶段——这和同步时的 RDB 解析是两回事，前者完全绕过 rdb-loading-threaded 控制。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
纯从节点必须彻底禁用本地持久化：
-
save ""：清空所有自动快照规则 -
appendonly no：关闭 AOF（注意不是appendfsync no） -
auto-aof-rewrite-percentage 0：防止后台重写意外触发 AOF 启用 - 手动删除残留文件：
rm dump.rdb appendonly.aof temp-*.rdb（容器环境尤其易漏临时文件）
生效后，从节点启动不再加载任何本地文件，直接进入复制握手，loading:1 阶段仅出现在收到主节点 RDB 流之后——此时 rdb-loading-threaded 才真正起作用。
为什么有些 key 类型加速不明显？RDB 并行粒度受限于对象构造顺序
rdb-loading-threaded 按「对象」切分 RDB 数据流（如一个 HASH、一个 ZSET），但并非所有结构都能高效并行：
- 简单类型（
STRING、LIST小长度）分配快、依赖少，并行收益高 - 大
HASH或ZSET内部需重建跳表/字典，涉及内存分配竞争和 rehash 触发，部分步骤仍需主线程协调 - 若 RDB 中大量 key 共享同一 hash slot 或存在跨对象引用（如 module 自定义类型），线程间同步开销会上升
所以，即使启用成功，也不能期望加载时间线性下降——它缓解的是 CPU 密集瓶颈，而非磁盘 IO 或内存带宽瓶颈。当 total_size 超过 2GB 且服务器内存带宽不足时，vmstat 1 中的 si/so 若持续非零，说明 page fault 已成新瓶颈，此时调优重点该转向内存配置或数据分片。
