断电后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未及时刷盘，断电后整个高可用元信息可能丢失，导致集群无法自愈。
