redis自身不提供aof实时校验，应按数据敏感度分级设置扫描频率：核心业务每6小时一次，普通缓存每天凌晨一次，且每次bgrewriteaof后须立即校验。
redis-check-aof 扫描频率怎么设才合理
Redis 自身不提供 AOF 文件完整性实时校验，必须靠外部工具周期性扫描。直接在 crontab 里每分钟跑一次 redis-check-aof 是错的——它会阻塞磁盘 I/O，且频繁扫描对大文件（>1GB）压力极大。
实际应按数据敏感度分级设置：
- 核心业务 Redis（如支付缓存）：每 6 小时执行一次，配合
redis-check-aof /var/lib/redis/appendonly.aof 2>&1 | grep "The first error"提取关键行 - 普通缓存实例：每天凌晨低峰期执行一次，用
timeout 300 redis-check-aof --check-utf8 /path/to/aof防卡死 - 若启用了 AOF 重写（
auto-aof-rewrite-percentage），必须在每次BGREWRITEAOF完成后立即触发一次校验——重写过程本身可能引入协议错误
Prometheus 告警规则中如何识别“真损坏”而非临时截断
AofCorruptionDetected 告警不能只看 redis_aof_current_size - redis_aof_base_size > 10000000。这个差值暴涨可能是正常追加，也可能是末尾截断后 Redis 自动跳过（aof-load-truncated yes 已生效）。
真正要告警的组合条件是：
-
redis_aof_last_rewrite_status == 0（上一次重写失败） -
redis_aof_enabled == 1且redis_aof_rewrite_in_progress == 0（非重写中） - 同时
redis_aof_current_size比前 1 小时增长> 500MB，且日志中最近 10 分钟出现Bad file format reading the append only file
单独一个 size 突增或单次日志报错都不够——很多运维误把 redis-check-aof 输出的 Everything OK 当作万能证明，其实它检测不出 RDB preamble 混入（头部 5 字节是 REDIS）这类静默损坏。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
磁盘层异常怎么和 AOF 协议损坏区分开
看到 Bad file format reading the append only file 第一反应不是修 AOF，而是查底层是否已不可信。常见混淆点：
- 磁盘只读（
EROFS）：Redis 启动日志会卡在Reading the remaining AOF tail，且strace -p $(pidof redis-server)显示大量write() = -1 EROFS - inode 耗尽：
df -i显示 100%，此时redis-check-aof可能直接失败并报Cannot open file: No space left on device，和协议损坏无关 - 文件系统损坏（如 ext4 journal 错乱）：
redis-check-aof报错位置随机跳变，且hexdump -C /path/to/aof | head -n 20显示开头字节乱码（非标准*数字\r\n$数字\r\n结构）
只要 redis-check-aof 能跑出具体字节偏移（如 byte offset 51200000），就说明文件系统层尚可读——问题在协议层面；一旦连打开文件都失败，优先救磁盘。
修复前必须验证的三个状态
redis-check-aof --fix 不是回滚按钮，它从第一个错误字节开始硬截断后续全部内容。执行前必须确认：
- Redis 进程已停止：
systemctl is-active redis-server返回inactive，否则截断后重启仍会加载损坏段 - AOF 文件未被其他进程写入：
lsof /var/lib/redis/appendonly.aof输出为空，避免修复中被覆盖 - 备份文件有完整时间戳：
stat appendonly_backup.aof中Modify时间早于最后一次业务写入时间，否则备份本身已损坏
最容易被忽略的是第三点：很多团队用 cp 备份但没关写入，导致备份文件和原文件同步损坏。真正安全的做法是先 CONFIG SET appendonly no 停写，再 SAVE 触发 RDB 落盘，最后拷贝 AOF——用 RDB 时间戳锚定一致性边界。
