单线程模型是什么
Redis 处理命令的核心是单线程串行执行：一条慢命令会让后面排队的请求全部等待，所以吞吐瓶颈通常不在核心数量，而在命令结构与数据规模。Redis 6.0 引入的网络 IO 线程只分担套接字读写与协议解析，命令执行始终在同一个主线程上。
基本信息
| 执行模型 | 命令在主线程上串行执行 |
|---|---|
| 多线程范围 | io-threads 只用于网络读写与协议解析（6.0 起） |
| 后台线程 | 内存异步释放、AOF 刷盘、关闭文件句柄等由后台线程处理 |
| 判读信号 | 单个核心打满、其他核心空闲 |
| 观测手段 | INFO cpu 看主进程与子进程用量，SLOWLOG 看慢命令 |
典型使用场景
- 延迟排查：判断问题在命令执行层还是网络层
- CPU 判断：看单核是否饱和，而不是看整体利用率
- 配置取舍：理解网络 IO 线程能改善什么、不能改善什么
- 慢命令治理：串行模型下消灭慢命令的收益高于大多数调参
- 容量规划：单核能力是吞吐上限的一部分，扩容多靠分片
- 大键治理：整体操作大键的耗时直接占用主线程时间
观测与验证
观测与验证
redis-cli INFO cpu # 主进程与子进程 CPU 用量
redis-cli INFO commandstats # 找出耗时占比高的命令
redis-cli SLOWLOG GET 10 # 慢命令现场
redis-cli CONFIG GET io-threads # 网络 IO 线程数（6.0 起）
redis-cli CONFIG GET io-threads-do-reads # 是否让 IO 线程参与读解析
redis-cli --latency # 客户端侧持续测量延迟
redis-cli INFO clients | grep -E 'blocked_clients' # 阻塞连接同样占用主线程时间现象对照
| 现象 | 可能原因 | 验证方式 |
|---|---|---|
| 单核打满、整体 CPU 低 | 命令结构或数据规模问题 | INFO cpu 看主进程用量 |
| 延迟上升但 CPU 不高 | 阻塞等待或网络问题 | 对照 blocked_clients 与客户端测量 |
| 批量任务期间整体变慢 | 大键操作或批量命令 | SLOWLOG 与 commandstats 对照 |
| 加核数没有改善 | 单线程模型的固有上限 | 观察单核饱和是否依旧存在 |
网络 IO 线程改善的是高并发下的读写与解析开销，命令执行永远在主线程，指望它解决慢命令没有意义。
后台任务（RDB 保存、AOF 重写、异步释放）会消耗 CPU 与内存，但它们的干扰路径与命令执行不同，排查时要先分清对象。