断电后Redis数据恢复能力取决于AOF配置：always零丢失但性能差；everysec默认策略，最多丢1秒数据；no不可靠。RDB因是定时快照且易损坏，断电后基本无效。

断电后Redis还能恢复多少数据？看AOF fsync策略

宿主机突然断电，Redis能否留存数据，核心取决于AOF是否启用及appendfsync配置。RDB在此场景下基本无效——它只在定时快照或手动SAVE/BGSAVE时落盘，断电前若没触发，就什么都没了。

而AOF的留存能力分三级：

• appendfsync always：每次写命令都fsync到磁盘，理论上零丢失，但性能暴跌（尤其机械盘），实际生产极少用
• appendfsync everysec（默认）：命令先写入内核缓冲区，每秒fsync一次；断电最多丢失1秒数据，是**平衡可靠性与性能的主流选择**
• appendfsync no：完全交由操作系统决定何时刷盘，可能丢数秒甚至数分钟数据，不推荐用于关键业务

注意：everysec不是绝对“1秒”，若内核缓冲区满或系统压力大，fsync可能延迟；断电瞬间若正处在“写入缓冲区→落盘”间隙，这部分就没了。

RDB文件在断电后为什么大概率失效？

RDB是全量快照，生成过程依赖BGSAVE子进程完成fork + 写时复制（COW）。断电发生时：

• 若BGSAVE正在执行，临时RDB文件（如temp-rewriteaof-{pid}.aof）未重命名完成，直接丢失
• 若上一次RDB已写完，但距断电已过去几分钟甚至几小时，那这期间所有写操作全部消失
• 更隐蔽的问题：RDB文件本身可能因断电导致末尾损坏（如CRC校验失败），Redis启动时拒绝加载，报错Wrong RDB checksum

所以RDB在断电场景下，本质是「最后成功快照时间点」的数据快照，不是容灾保障手段，而是冷备兜底选项。

断电重启后Redis起不来？重点检查AOF重写与破损

断电常导致AOF文件处于中间状态：命令写了一半、末尾无换行、或fsync中途被截断。Redis启动时会尝试载入AOF，失败则直接退出，并在日志中打印类似：

Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix

此时必须人工干预：

• 先备份原AOF文件：cp appendonly.aof appendonly.aof.bak
• 用官方工具修复：redis-check-aof --fix appendonly.aof（会截掉最后一个不完整命令）
• 若修复后仍无法启动，可尝试降级加载：临时注释appendonly yes，启动后用CONFIG SET appendonly yes动态开启，让Redis重新生成AOF（前提是内存数据仍有效）

别跳过备份——--fix是破坏性操作，可能删掉最后若干条合法命令。

单机Redis扛不住断电？该上Sentinel还是Cluster？

无论AOF多严谨，单机Redis在断电后必然有服务中断期（哪怕只有几十秒），且恢复依赖人工介入。真要应对宿主机级故障，必须脱离单点依赖：

• Sentinel方案：适合中小规模。主库断电后，Sentinel在down-after-milliseconds（默认30s）内确认宕机，再经选主、通知、重配置，通常1~2分钟内完成切换。但注意：Sentinel不解决数据丢失，它只保证“谁来当新主”，AOF/RDB策略仍决定能恢复多少
• Cluster方案：适合高吞吐、分片明确的场景。断电节点所属哈希槽会标记为fail，其余节点继续服务；只要不是超过半数主节点同时宕机，集群保持可用。但Cluster对客户端要求高，需支持重定向（MOVED/ASK）

真正容易被忽略的是：Sentinel和Cluster本身也依赖持久化配置。如果Sentinel节点没开sentinel.conf自动保存，或Cluster节点nodes.conf未及时刷盘，断电后整个高可用元信息可能丢失，导致集群无法自愈。