为什么Redis订阅者在执行BGSAVE期间响应变慢_分析RDB持久化对IO的影响-Redis-PHP中文网

redis订阅者卡顿主因是bgsave引发的fork阻塞、cow内存争抢及磁盘io压力，导致主线程调度延迟、网络栈响应变慢；应将rdb迁至从节点、禁用thp、设vm.swappiness=0来缓解。

为什么redis订阅者在执行bgsave期间响应变慢_分析rdb持久化对io的影响

Redis 订阅者响应变慢，大概率不是订阅逻辑本身的问题，而是 bgsave 触发时的系统级资源争抢 —— 尤其是 fork + COW + 磁盘 IO 三重叠加导致的延迟毛刺。

Redis 的发布/订阅是纯内存操作，不走命令队列主流程，但它的响应仍依赖主线程调度和底层系统资源。当 bgsave 执行时：

bgsave 会调用 fork() 创建子进程，该系统调用在内存压力大或开启 THP（透明大页）时可能阻塞主线程数十毫秒 —— 此时所有客户端（包括 SUBSCRIBER）收不到新消息推送
子进程遍历内存做快照时，若此时主线程正高频修改 key（如频繁 PUBLISH），COW 机制会大量复制脏页，加剧内存带宽争抢和 TLB 压力
RDB 文件写入磁盘的过程会拉高 I/O 队列深度（iostat -x 1 可见 avgqu-sz 突增），间接拖慢内核网络栈处理速度，表现为 SUBSCRIBE 客户端 READ 系统调用返回延迟升高

别只盯着 redis-cli info | grep rdb，得看系统层是否真被拖住：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

执行 iostat -x 1，观察对应磁盘的 %util 是否持续 >80%，且 await（平均 I/O 等待时间）超过 10ms
检查 /proc/<redis-pid>/io</redis-pid> 中的 write_bytes 是否在 bgsave 启动后突增（注意：这是子进程写的，但父进程的 io 文件也会反映部分上下文切换开销）
用 perf record -e syscalls:sys_enter_write -p <redis-pid></redis-pid> 抓取写系统调用耗时，常能发现个别 write 耗时 >50ms —— 这就是 SUBSCRIBE 消息推送卡顿的直接源头

核心思路是解耦持久化与主服务，而非简单关掉 bgsave：

把 RDB 持久化迁移到从节点：主节点 save "" 清空自动触发规则，从节点配置 save 300 1 等策略并开启 bgsave
禁用 THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled，否则 fork() 延迟可能从毫秒级跳到百毫秒级
确保 vm.swappiness = 0，避免 fork() 过程中因内存不足触发 swap，进一步放大延迟
若必须在主节点运行 bgsave，改用 redis-cli bgsave 手动触发，并避开消息高峰时段（比如避开每小时整点的批量 PUBLISH）

当 bgsave 拉高系统负载时，即使 Redis 主线程没卡死，也可能出现：

TCP 接收缓冲区（net.ipv4.tcp_rmem）来不及消费，导致客户端 recv() 阻塞
epoll_wait() 返回频率下降，SUBSCRIBE 客户端感知为“消息断流”而非“延迟”，实际是内核事件分发变慢
云环境 cgroup 内存限制下，fork() 失败日志可能被吞掉，只留下 rdb_last_bgsave_status:err，需查 dmesg -T | grep -i "out of memory"