redis持久化卡住需优先检查thp是否禁用、fork耗时及磁盘写入状态；调优rdb/aof策略，监控rdb_last_bgsave_time_sec、aof_delayed_fsync等核心指标并设动态基线告警。
Redis持久化耗时突增，bgsave 或 bgrewriteaof 卡住怎么办
当 bgsave 执行时间超过 1 秒，或 bgrewriteaof 超过 5 秒，大概率已影响主线程响应——这不是警告，是服务抖动前兆。Redis 的 fork() 子进程做 RDB 快照，或 AOF 重写时，若内存页过多、系统负载高、或使用了透明大页（THP），fork 会阻塞数秒甚至更久。
- 检查
/sys/kernel/mm/transparent_hugepage/enabled，必须为never（不是advise） - 用
info persistence查看rdb_last_bgsave_time_sec和aof_last_rewrite_time_sec，持续 >1s 就要干预 - 避免在高峰期触发手动
SAVE；RDB 配置建议用save 60 10000这类宽松策略，而非高频小变更触发 - AOF 重写期间，如果
aof_current_size比aof_base_size增长过快（比如 20 倍以上），说明写入突增或重写太慢，需结合auto-aof-rewrite-percentage与auto-aof-rewrite-min-size调整
last_save_time 长期不更新，但 rdb_last_bgsave_status 是 ok？查这个字段
表面看持久化成功，实则可能因磁盘满、权限不足、或 dir 路径不可写，导致 RDB 文件未真正落盘。Redis 只校验 fork 和子进程退出状态，不验证文件是否写入完成、是否可读。
- 务必监控
info persistence中的rdb_last_bgsave_status（必须为ok）和rdb_last_bgsave_time_sec（数值应合理递增，不能长期为 0 或负数） - 定期用
ls -l <code>dir/dump.rdb 确认文件大小是否非零且时间戳更新 - 若使用 NFS 或网络存储，禁用 RDB —— fork + 写远程文件极易超时失败，改用 AOF +
appendfsync everysec更稳妥
AOF sync 策略选 everysec 还是 no？看你的数据容忍底线
appendfsync everysec 是默认且最常用选择：内核每秒刷一次页缓存到磁盘，崩溃最多丢 1 秒数据，性能损耗可控。选 no 表示完全交由 OS 决定，看似快，但实际可能几十秒不刷盘，且受系统 dirty_ratio 影响极大，在内存紧张时反而引发 write stall。
- 除非业务明确允许分钟级数据丢失（如实时排行榜缓存），否则不要用
no - 若启用了
aof-use-rdb-preamble yes（混合持久化），AOF 重写会生成带 RDB 结构的 AOF 文件，此时everysec仍适用，无需调整 - 注意：开启
appendfsync always会严重拖慢写入吞吐（每次写都 fsync），仅限金融类强一致场景，且必须配 SSD + 调整 IO 调度器
监控告警该设哪些硬指标？别只盯 used_memory
内存用量只是间接因素。真正决定持久化成败的是 fork 开销、磁盘 I/O 能力、以及子进程生命周期。以下 4 个字段必须接入 Prometheus + Alertmanager 或类似系统：
-
rdb_last_bgsave_time_sec > 2：连续 2 次超 2 秒，触发 P2 告警 -
aof_delayed_fsync > 100：表示有 100 次以上 fsync 被延迟执行，说明内核刷盘压力大，需查 iowait -
latest_fork_usec > 500000（即 500ms）：fork 耗时异常，立刻查 THP、内存碎片率mem_fragmentation_ratio -
aof_current_rewrite_time_sec > 30：AOF 重写超 30 秒，配合redis_aof_rewrite_in_progress判断是否卡死
这些值不是固定阈值，上线前需在压测环境跑出基线。比如大内存实例（32G+）的 latest_fork_usec 基线可能就是 300ms，盲目套用 100ms 阈值只会产生噪音。
