Redis 7.0.12+从节点加载大RDB时CPU飙升，根本原因是rdbLoadObject等解析函数仍在主线程串行执行；必须同时满足版本≥7.0.12、显式配置rdb-loading-threaded yes、io-threads≥2三个条件，多线程RDB加载才生效。
先看是不是RDB加载卡主线程
Redis 7.0集群从节点全量同步大RDB时CPU飙到100%，大概率不是网络或磁盘慢，而是rdbLoadObject这类解析函数仍在主线程串行执行。这个现象在7.0.12+版本里特别典型——功能存在，但默认不生效。
确认是否真启用了多线程RDB加载，得同时满足三个硬条件：
-
redis-server --version≥ 7.0.12；低于此版本压根没这个机制 -
rdb-loading-threaded yes必须显式配置（写进redis.conf并重启，或用CONFIG SET rdb-loading-threaded yes热生效） -
io-threads≥ 2；设成1时，实际工作线程数 =io-threads - 1= 0，会静默退化为单线程
验证方式很简单：全量同步期间执行INFO threads，如果io_threads_active为0，说明没跑起来；再用perf top -p $(pgrep redis)看热点是不是还集中在rdbLoadStringObject（主线程），而不是分散在多个线程里。
别被repl-diskless-sync误导
开了repl-diskless-sync yes却还是CPU拉满？这不是配置没生效，而是理解错了作用点。无盘同步只跳过了RDB落盘环节，数据流式接收完后，仍要走同一套单线程反序列化逻辑——CPU峰值就出在这儿，不是在网络接收阶段。
rdb-loading-threaded才是唯一影响该阶段并行度的开关，和repl-diskless-sync完全无关。如果你同步前已配好但没生效，首次全量仍会卡住主线程；建议在低峰期手动触发一次SLAVEOF NO ONE && SLAVEOF强制重同步验证。
查慢查询别漏掉集群拓扑映射
执行SLOWLOG GET 10只能看到当前节点的慢命令，返回字段里有耗时、命令和参数（如GET user:1001），但不带slot、不标节点。在集群里光看这个容易误判。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
要定位到具体是哪个key或slot拖慢了服务，必须手动做两步映射：
- 从慢日志里提取第一个key，比如
GET user:1001中的user:1001，用CLUSTER KEYSLOT user:1001算出slot编号 - 再用
CLUSTER GETKEYSINSLOT {slot} 1验证该slot是否真在这个节点上；如果不返回结果，说明key实际路由到了别的节点——可能是客户端没启用哈希标签（{}），或用了MGET跨slot操作触发了ASK重定向
特别注意EVAL/SCRIPT LOAD类命令：它们的慢耗时往往来自Lua脚本内部逻辑，SLOWLOG只显示执行起点，得进脚本里加redis.log()打点。
热键和胖键会悄悄吃掉CPU
用redis-cli --hotkeys -i 0.5在从库低峰期扫一遍，能快速揪出高频访问的key，比如user:session:abc123（1876次访问）。但要注意：--hotkeys依赖MONITOR，高流量主库上直接跑可能让服务雪上加霜。
更隐蔽的是“胖键”：一个HASH里塞了几千个字段，或一个STRING value超1MB。这类结构在反序列化、淘汰、过期检查时都会触发阻塞式操作。用MEMORY USAGE user:1001查内存占用，配合DEBUG OBJECT user:1001看编码细节（比如是否从ziplist升级到了hashtable），比单纯看CPU更准。
真正难处理的，是那些既热又胖的key——它可能同时触发高频读 + 单次长耗时，导致CPU曲线锯齿状抖动。这种场景下，光调参没用，得拆结构、加缓存层、或改用分片策略。
