1 延迟基线:先弄清"天花板"
1.1 内在延迟(intrinsic latency)
同一台机器上任何进程均无法突破的调度极限,可用 redis-cli --intrinsic-latency 测试:
bash
redis-cli --intrinsic-latency 100 # 100 秒采样
- 物理机:常见 50 µs -- 200 µs。
- 虚拟机 / 容器:受宿主机、超分、邻居噪声影响,可高达 10 ms 以上。
- 基线即上限:应用层任何优化都无法优于此。
1.2 网络通信延迟
场景 | 单次 RTT |
---|---|
本机 Unix Socket | ~30 µs |
千兆局域网 | ~200 µs |
跨可用区 / 公网 | 1 ms -- 几十 ms |
2 高频排障清单(5 分钟速查版)
步骤 | 命令 / 操作 | 重点 |
---|---|---|
① 慢日志 | SLOWLOG get 10 |
是否有 > 1 ms 的命令? |
② 延迟监控 | LATENCY DOCTOR |
哪些 event 触发?持续多久? |
③ 内核配置 | 关闭 Transparent Huge Pages echo never > /sys/.../transparent_hugepage/enabled |
|
④ AOF 策略 | appendfsync everysec 是否足够 |
避免 always 带来的 fsync 堵塞 |
⑤ 虚拟化平台 | EC2 请选择 HVM m6i/m5/m6g 以上 | 旧版 Xen fork 太慢 |
⑥ --intrinsic-latency |
> 5 ms?考虑宿主机抖动 / 噪声邻居 | |
⑦ 复核 maxmemory | 是否触发 swap / oom_killer |
3 延迟来源全景图
graph TD
subgraph 内部
A[慢命令
O(N)] --> L1 B[fork
BGSAVE/AOF] --> L2 C[AOF 写盘
fsync] --> L2 D[大批量 expire
主动清理] --> L3 end subgraph 系统 E[内核调度
抢占] --> L0 F[THP / COW] --> L2 G[Swap I/O] --> L3 end subgraph 外部 H[网络 RTT] --> L0 I[客户端
序列化/阻塞] --> L0 end
O(N)] --> L1 B[fork
BGSAVE/AOF] --> L2 C[AOF 写盘
fsync] --> L2 D[大批量 expire
主动清理] --> L3 end subgraph 系统 E[内核调度
抢占] --> L0 F[THP / COW] --> L2 G[Swap I/O] --> L3 end subgraph 外部 H[网络 RTT] --> L0 I[客户端
序列化/阻塞] --> L0 end
- L0:亚毫秒抖动 --- 常规基线。
- L1:单条慢命令堵塞事件循环。
- L2 :Redis 主线程被 fork / fsync / COW 暂停。
- L3:内核级 I/O、Swap 或批量过期导致秒级停顿。
4 监测与定位
4.1 Slow Log -- 捕获单条慢命令
bash
CONFIG SET slowlog-log-slower-than 1000 # ≥1ms 记录
SLOWLOG GET 20
- 重复出现
SORT
,ZUNION
,KEYS
等 O(N) 命令应警惕。 - 查询、比对业务代码,必要时用 Lua / Stream 重构。
4.2 Latency Monitor -- 事件级分析
bash
CONFIG SET latency-monitor-threshold 200
LATENCY DOCTOR # 概览
LATENCY GRAPH fork # 查看 fork 延迟趋势
- 关注常见 event:
command
,fork
,aof-fsync
,expire-cycle
。
4.3 系统级工具
工具 | 观察指标 |
---|---|
vmstat 1 |
si/so 是否持续非 0(swap) |
iostat -x 1 |
await , %util 高?磁盘拥堵 |
strace -p $PID -T -e trace=write,fdatasync |
哪些 fsync 阻塞 |
5 典型场景深度剖析
5.1 慢命令阻塞
- KEYS、SMEMBERS、SUNION 等,避免在生产使用 ;改用 SCAN 家族增量遍历。
- 大集合运算需在 Replica 执行或迁往离线任务。
5.2 fork 带来的「瞬时卡顿」
-
触发时机:
BGSAVE
,BGREWRITEAOF
,MEMORY PURGE
。 -
复制页表是瓶颈:24 GB 实例约 48 MB 页表。
-
优化手段
- 使用 HVM + 新一代云主机 / 物理机。
- 降低备份频率;外部持久化(如 rdb snapshot in replica)分摊 IO。
- 大实例(> 64 GB)用 diskless replication 减少磁盘 IO。
5.3 AOF fsync 阻塞
appendfsync | 延迟风险 | 适用场景 |
---|---|---|
always |
高,高速盘必备 | 金融级强一致 |
everysec |
中(可忍受) | 通用推荐 |
no + RAID/UPS |
低 | 延迟敏感 & 有其他持久化 |
- 勾选
no-appendfsync-on-rewrite yes
,后台重写期间只写不 fsync。 - 核心业务最好用独立 SSD,避免与数据库 / 日志混用。
5.4 Swap & 内存抖动
-
grep Swap /proc/$pid/smaps | awk '{s+=$2} END {print s/1024 " MB"}'
检查 Redis 进程已换出量。
-
若 swap > 100 MB:
- 提升
vm.swappiness=0
,或直接sudo swapoff -a
。 - 降低
maxmemory
或下线其他占内存服务。
- 提升
5.5 大量 key 同时过期
-
主动过期算法每 100 ms 采样 20 个 key,若 25% 过期则循环。
-
场景:海量秒杀 coupon、会话一次性设置同一
EXPIREAT
。 -
解决:
- 将时间戳随机 + - 60 s 打散;
- 批量存到 Sorted-Set TTL Wheel,定时 Lua 扫描。
6 生产环境调优建议
类别 | 建议 |
---|---|
系统 | 关闭 THP;nofile ≥ 65535;物理机 CPU performance governor |
Redis 配置 | latency-monitor-threshold 200 ;禁用 save 或错峰快照 |
客户端 | 使用 连接池 + Pipeline;跨区走腾讯云内网或 AWS Global Accelerator |
运维 | 定期收集 SLOWLOG LEN 、LATENCY LATEST 、fork/used_cpu_sys_children |
容灾 | 母机宕机延迟 > 基线 ×10;双 AZ master-replica + Sentinel 自动切换 |
7 总结
- 先测基线 :
--intrinsic-latency
了解物理/虚拟机极限。 - 定位热点:Slow Log + Latency Monitor 快速锁定事件。
- 分层治理:命令层、持久化层、操作系统层各有对策。
- 以闲养忙:独占 SSD、错峰慢操作、随机化大量过期。
- 持续观测:关键指标告警 + 业务 P99 延迟回溯。
做到以上,即可让 Redis 处理路径保持 微秒级稳定,轻松应对高并发与突发流量。愿你的 QPS 再高,延迟依旧顺滑如丝!