断电后第一件事是检查aof文件是否损坏：先用ls -l appendonly.aof查看文件大小是否异常小，再用redis-check-aof --fix修复，否则直接重启会因格式错误失败。
断电后第一件事：别急着重启，先确认AOF是否损坏
直接重启 Redis 很可能失败，因为断电常导致 appendonly.aof 文件写到一半就被截断。Redis 启动时会校验 AOF 格式，遇到不完整命令就报错退出，典型错误是：Bad file format reading the append only file。
必须先做两步检查：
- 用
ls -l appendonly.aof看文件大小是否异常小（比如 - 用
tail -n 20 appendonly.aof查看末尾是否缺少换行、是否卡在某个命令中间（如*3\r\n$3\r\nSET\r\n$4\r\nkey1\r\n突然中断）
只要末尾不是完整的 RESP 协议格式（以 \r\n 结尾的完整命令块），就大概率需要修复。
用 redis-check-aof --fix 恢复 AOF，但必须带备份
redis-check-aof --fix 是唯一能抢救损坏 AOF 的官方工具，但它会无条件删掉最后一个不完整命令——哪怕那条命令本身合法，只是没来得及写完换行符。
执行前务必手动备份：
cp appendonly.aof appendonly.aof.bak-$(date +%s)- 再运行
redis-check-aof --fix appendonly.aof
修复后启动 Redis，观察日志是否仍有 Unexpected EOF 或 Invalid argument 报错。如果还有，说明损坏不止一处，此时不要反复 --fix，应降级处理：临时关闭 AOF（CONFIG SET appendonly no），让 Redis 先以内存数据启动，再手动触发 BGREWRITEAOF 生成新日志。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
集群环境下，单节点修复不等于数据一致
即使每个节点的 AOF 都修好了、也能启动，也不代表集群整体数据一致。断电可能发生在不同时间点，各节点的 master_repl_offset 已经严重偏离。
必须立刻分层验证：
- 在所有主节点执行
INFO replication，记下各自的master_repl_offset - 在所有从节点执行
INFO replication，对比其slave_repl_offset是否全部对齐任一主节点（注意：脑裂后可能有多个“主”） - 若发现某从节点 offset 比所有主节点都大，说明它曾被误升为新主，且接收过写入——这是脑裂的铁证，不能简单回滚
此时不能依赖自动同步：repl-backlog-size 通常只有 1MB，默认配置下，断电超过几秒就可能覆盖 backlog，导致部分同步（PSYNC）失效，只能全量重传。
最终一致性验证必须用 redis-full-check，不能只看 DBSIZE
偏移量对齐 + DBSIZE 相同，只说明 key 总数一致，掩盖了 HASH 字段缺失、ZSET score 错位等深层不一致。业务报“读到旧值”往往就出在这里。
运行校验命令要严格控制节奏：
./redis-full-check -s 10.0.1.10:6379 -t 10.0.1.11:6379 --comparetimes=3 --qps=300-
--comparetimes=3防止瞬时写入造成误判；--qps=300避免压垮节点（尤其断电刚恢复时资源紧张） - 输出中的
content mismatch行会精确指出哪个 key 的哪个 field 不一致，这才是修复依据
最容易被忽略的是：校验必须在所有主从配对之间交叉执行，不能只比“原主 vs 原从”。断电后拓扑可能已变，旧主现在可能是从，而某个从节点已是新主——不按当前角色关系比，结果毫无意义。
