必须同时启用 io-threads 和 io-threads-do-reads，否则 i/o 线程不参与读请求处理；io-threads ≥ 2 才生效，需 config rewrite 或重启；推荐值为 min(4, cpu核心数×0.7)，numa 架构下必须用 server_cpulist 绑定同 node 核心。
io-threads 和 io-threads-do-reads 必须成对启用
只设 io-threads 4 但没开 io-threads-do-reads yes，配置等于白配。Redis 默认关闭读线程，写响应虽默认由 I/O 线程处理，但请求读取卡在主线程，整个 pipeline 堵死第一步。
常见错误现象：INFO threads 显示 io_threads_num: 4 但 io_threads_active: 0，说明线程未真正参与工作。
-
io-threads必须 ≥ 2 才会创建子线程（设为 1 等价于禁用） - 修改后必须执行
redis-cli config rewrite或重启服务，config set不支持热更新这两个参数 - 验证是否生效：压测时观察
top -H中 redis-server 的线程数，或直接查INFO threads
CPU 核心数决定 io-threads 上限，不是越多越好
线程数超配会引发频繁上下文切换和锁竞争，%sy（系统态 CPU）飙升，QPS 反而下降。4 核机器设 io-threads 8 是典型误操作。
推荐值 = min(4, CPU核心数 × 0.7)，例如：
- 4 核机器 → 设 2～3
- 8 核机器 → 设 4～5
- 16 核以上机器 → 仍建议 ≤ 6，收益趋近于零且增加内存占用（每个 I/O 线程独占缓冲区）
注意：该公式针对通用网络密集型场景；若 Redis 运行在 NUMA 架构上（numactl -H 可确认），还需配合 CPU 绑定，否则跨 node 访存延迟可能抵消线程增益。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
server_cpulist 必须显式配置，否则 I/O 线程随机调度
即使开了多线程，若不绑定 CPU，主线程和 I/O 线程可能被内核调度到不同 NUMA node，导致访问远端内存延迟翻倍（如 node distances 显示 10 vs 21）。
配置示例（以 40 核双 node 机器为例）：
-
server_cpulist 0-7:2→ 主线程 + I/O 线程绑定到 node 0 的偶数核（0,2,4,6） -
bio_cpulist 1,3→ 后台 bio 线程绑定到 node 0 的奇数核（1,3） -
aof-rewrite-cpulist 8-9→ AOF rewrite 进程绑定到 node 0 的固定核
关键点：server_cpulist 控制的是主线程和所有 I/O 线程的 CPU 亲和性，不是单指某个线程；漏配会导致线程在多个 node 间跳跃，L1/L2 cache 命中率骤降。
并发击穿场景下，线程配置要匹配真实负载特征
“并发击穿”不是单纯 QPS 高，而是突发大量小请求（如缓存雪崩后瞬时回源）或集中读写大 value（如批量 GET 1MB String）。这两类场景对线程配置的敏感度完全不同。
- 小请求洪峰：更依赖 I/O 线程吞吐，
io-threads可按上限设（如 4 核设 3），但必须配server_cpulist锁定本地 node - 大 value 场景：主线程 memcpy 开销变重，I/O 线程分摊效果明显，此时
io-threads-do-reads yes是刚需，且线程数建议 ≥ 3 - 混合负载：优先保障大 value 场景，用
redis-benchmark -t get,set -r 10000 -d 1048576模拟 1MB value 压测，观察延迟毛刺是否收敛
最容易被忽略的一点：NUMA 架构下，server_cpulist 若跨 node（如写成 0,1,2,3,4,5,6,7），反而比不绑还慢——因为前 4 个核在 node 0，后 4 个在 node 1，线程池无法共享本地内存。
