aof文件存储的是redis执行过的写命令的resp协议格式文本，非快照而是操作日志，每条命令含长度前缀和\r\n分隔符，删除单行会导致解析错位；回滚需用redis-cli --pipe选择性重放，且必须关闭aof写入避免循环。
Redis AOF 文件里到底存了什么指令
AOF 文件不是快照，是 Redis 执行过的写命令的纯文本记录，每条命令按协议格式（RESP）追加进去。它不存状态，只存操作——所以回滚本质是“重放”或“跳过”某些命令，而不是直接还原内存。
常见错误现象：redis-check-aof --fix 修复后数据反而错乱；手动删掉几行 AOF 再重启，Redis 启动失败报 Bad file format reading the append only file。
- AOF 中的命令是带参数的完整调用，比如
*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$5\r\nAlice，不是可读的 SET name Alice - 所有命令都以 RESP 协议编码，含长度前缀、换行符 \r\n，手动编辑极易破坏格式
-
EXPIRE、PEXPIRE等带时间戳的命令，在重放时会按当前时间重新计算过期逻辑，不是“回滚到某时刻”，而是“跳过某次设置”
想回滚某次 SET，能不能直接删 AOF 里的那行
不能。AOF 不是日志行 = 操作行，它是协议流，删一行可能让后续所有命令解析错位，导致 Redis 拒绝加载。
使用场景：误执行了 SET user:1001 "hacked"，想恢复成之前值。此时 AOF 里可能有几十上百条命令，包括中间的 INCR、HSET，甚至 DEL —— 单删一条 SET 无意义，还可能让整个文件不可读。
- Redis 加载 AOF 时逐字节解析，一旦遇到非法长度、缺失 \r\n、类型不匹配，立刻中止并报错
- 即使你用
redis-check-aof --fix强制修复，它只会截断损坏点之后的内容，无法智能“撤回”某条命令 - 真正安全的做法是：停写 → 备份当前 AOF → 用
redis-cli --pipe重放干净部分 → 或直接切到 RDB + 增量 AOF 的混合持久化模式
用 redis-cli --pipe 回滚时要注意哪些协议细节
redis-cli --pipe 是唯一能“选择性重放”的标准方式，但它要求输入必须是合法 RESP 格式，不是简单把 AOF 文件切几行就能用。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
性能 / 兼容性影响：重放过程不走网络协议栈，但会触发所有命令的完整执行流程（包括键过期判断、AOF 再写入），所以必须关掉 appendonly yes，否则会二次写入 AOF，形成循环。
- 先用
redis-cli config set appendonly no关闭 AOF 写入 - 从原始 AOF 提取目标区间时，得按完整命令边界切分，可用
redis-check-aof --fix输出校验位置，再用sed -n '123,456p'截取（注意行号 ≠ 命令数） - 重放前确保目标 key 当前值符合预期，比如
GET user:1001返回空，才适合重放 SET；否则会覆盖已有值 - 命令里含二进制数据（如
SET foo "\x00\x01"）时，原始 AOF 已转义，--pipe输入需保持同样编码，否则解析失败
为什么官方不提供 “rollback to timestamp” 功能
因为 AOF 本身不记录时间戳。虽然 appendfilename 和 auto-aof-rewrite 会产生新文件，但单个 AOF 文件内没有任何时间元信息。Redis 作者明确说过：AOF 是 crash recovery 机制，不是审计日志，更不是时间旅行工具。
容易被忽略的地方：很多人以为开启 aof-use-rdb-preamble yes 就能结合 RDB 的“状态”和 AOF 的“增量”做精确回滚，其实不行——RDB 是快照起点，AOF 是从该快照之后的所有写操作，但没有时间锚点，你无法知道第 827 条命令对应的是 14:22 还是 14:23。
真要时间维度回滚，得靠外部方案：比如用 MONITOR 日志（性能损耗大）、或在业务层打标 + 写入带时间戳的流水表，再配合定时备份 RDB。
