redis 6.0 的 string 类型读写命令执行仍为单线程，提速仅来自网络 i/o 环节：多线程并行处理请求读取（需显式开启 io-threads-do-reads）和响应写出，尤其在大 value 场景下效果显著；线程数推荐设为 min(4, cpu核心数×0.7)，超配反致性能下降。
Redis 6.0 的 String 类型读写本身不因多线程而变快——命令执行（GET/SET）仍是主线程单线程完成；真正提速的是网络 I/O 环节：当大量客户端并发发来小请求或返回大 value 时，读取请求数据、写出响应数据这两个步骤被分摊到多个线程并行处理，从而显著提升吞吐量。
io-threads 和 io-threads-do-reads 必须同时启用
只设 io-threads 4 不生效。Redis 默认关闭读线程（io-threads-do-reads no），必须显式开启才能让 I/O 线程参与请求读取。写响应默认始终由 I/O 线程处理（无需额外开关），但读不启用，整个 pipeline 就卡在第一步。
-
io-threads值必须 ≥ 2 才会真正创建子线程（设为 1 等价于禁用） -
io-threads-do-reads yes是关键开关，漏配会导致配置“看似生效”实则无加速 - 修改后需
redis-cli config rewrite或重启，config set不支持热更新这两个参数
线程数不是越多越好，CPU 核心数是硬约束
常见误操作是把 io-threads 设成 8 或 16 —— 在 4 核机器上这反而引发频繁线程竞争和上下文切换，top 里能看到 %sy（系统态 CPU）飙升，但 QPS 不升反降。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐值 =
min(4, CPU核心数 × 0.7)，4 核机器设 2～3，8 核设 4～5 - 超过 8 个 I/O 线程在绝大多数场景下收益趋近于零，且增加内存占用（每个线程独占缓冲区）
- 可通过
INFO threads查看io_threads_num和io_threads_active确认是否真正激活
String 大 value 场景下，I/O 线程收益最明显
普通 SET key "hello" 这类小请求，单线程读写开销几乎可忽略；但当你批量 GET 一个 1MB 的 String，或用 MSET 写入数百 KB 数据时，主线程原本要同步 memcpy 数百次，现在这些操作被 4 个线程分摊，延迟毛刺大幅减少。
- 典型高收益场景：日志缓存（value > 100KB）、HTML 片段缓存、序列化对象直存
- 注意：value 越大，I/O 线程节省的 CPU 时间越多，但主线程解析命令+查 hash 表仍不变
- 若业务以高频小 key 为主（如 token 验证），启用 I/O 线程后吞吐提升可能仅 10%～15%，别预期翻倍
别忽略 jemalloc 和 lazyfree 的协同影响
I/O 线程只管搬数据，但大 SET 后内存分配、大 DEL 后内存回收，依然压在主线程。如果没调优内存分配器或没开 lazyfree，I/O 加速会被后续操作拖垮。
- 确认使用
jemalloc（非 libc malloc），并在redis.conf中启用activedefrag yes - 对可能删除大 key 的场景，务必开启
lazyfree-lazy-user-del yes，避免DEL阻塞主线程 -
INFO memory中关注allocator_active和allocator_resident差值，过大说明内存碎片严重，I/O 线程也救不了
真正容易被忽略的点是：I/O 线程只加速“数据搬运”，不加速“内存操作”。如果你的瓶颈其实在 HGETALL 返回几万字段，或 SCAN 遍历大 hash，那调 io-threads 没用——该优化数据结构或加索引，而不是加线程。
