redis性能骤降主因是单线程模型下阻塞操作叠加，如keys*、hgetall、del大key等毫秒级命令引发秒级阻塞，且slowlog仅记录>10ms操作，易滞后发现；大key还会导致网络传输卡顿、fork失败、内存碎片恶化；rdb/aof持久化中fork耗时、aof重写i/o高、appendfsync always配置亦显著拖慢服务；客户端连接超限、内存swap、lua脚本超时等隐形阻塞源常被忽略，需结合info memory/clients/stats综合排查。
Redis性能骤降，大概率不是“突然变慢”，而是多个阻塞点在短时间里叠加爆发——单线程模型下，一个耗时操作卡住主线程，后续所有请求排队等待，延迟雪球式放大。
哪些命令会在毫秒级就拖垮整个实例？
不是所有 O(n) 命令都一样危险，关键看 n 的实际规模和 Redis 当前负载。以下命令在数据量稍大时极易触发秒级阻塞：
-
KEYS *：全库扫描，n = 总 key 数，生产环境必须禁用 -
HGETALL、SMEMBERS、LRANGE key 0 -1：当 hash/set/list 元素超 5000，响应时间常突破 100ms -
DEL大 key：删除一个含 20 万成员的Set，主线程同步释放内存，可能卡住 300ms+ -
FLUSHALL或FLUSHDB：清空全部或当前库，阻塞时长与总 key 数正相关
这些命令本身不报错，但会把 slowlog 记录推到 10000 微秒以上（即 10ms+），而 Redis 默认只记录 >10ms 的操作——意味着你看到的 slowlog，已经是“已经出事”的证据。
为什么“刚加了几个大Key”就崩了？
大 key 不只是读写慢，它会连锁触发多个阻塞环节：
- 网络传输卡顿：
GET一个 8MB 的 string，Redis 要一次性打包发给客户端，期间无法处理其他请求 - 持久化 fork 失败：RDB
BGSAVE时需 fork 子进程，若父进程堆内存过大（比如刚加载了几个大 key），fork 可能失败或耗时激增，导致主线程卡顿数秒 - 内存碎片恶化：大 key 分配/释放后易留下不连续空闲块，后续小分配频繁失败，触发主动内存整理（
activedefrag），进一步抢 CPU
注意：--bigkeys 扫描本身也会加重负载，线上慎用；推荐用 redis-cli --scan + 客户端分批采样替代。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
持久化操作怎么悄悄拖慢服务？
RDB 和 AOF 重写不是“后台安静运行”，它们对主线程有明确干扰点：
-
fork()系统调用：复制页表项，若 Redis 占用 10GB 物理内存，fork 可能消耗 200–500ms CPU 时间，期间主线程完全停顿 - AOF
rewrite过程中，新写入仍要追加到旧 AOF 文件，同时子进程还要读取全量数据生成新文件，磁盘 I/O 和 CPU 双高 -
appendfsync always配置会让每个write()调用都等磁盘落盘完成，单次写入延迟从微秒级升至毫秒级，积压后直接阻塞
验证是否被持久化拖累：执行 INFO persistence 查看 rdb_bgsave_in_progress 和 aof_rewrite_in_progress 是否为 1；再用 INFO stats 对比 total_commands_processed 和 instantaneous_ops_per_sec 是否断崖下跌。
容易被忽略的“隐形阻塞源”
有些问题不体现在 slowlog 里，却真实阻塞主线程：
- 客户端连接数超限：
maxclients设太低，新连接排队等待 accept，表现为大量连接超时而非命令超时 - 内存 swap：
used_memory_rss远大于used_memory（比如差 2GB+），说明 OS 正在交换页，Redis 每次 malloc/free 都可能触发缺页中断，延迟飙升 - Lua 脚本超时：脚本里用了
for i=1,100000 do ... end，哪怕没报错，也会独占主线程直到执行完
真正棘手的阻塞，往往藏在 slowlog 之外——它不报慢，但让你的 P99 延迟翻倍、连接池打满、监控曲线毛刺不断。排查时别只盯 SLOWLOG GET，得同步看 INFO memory、INFO clients、INFO stats 三组指标联动异常。
