Redis kill -9 后数据是否丢失取决于持久化模式：仅RDB会丢失上次save后写入，AOF在appendfsync always下理论不丢但受磁盘缓存影响，混合模式优先加载AOF；AOF末尾截断会导致加载失败而非数据丢失。
kill -9 后 Redis 重启丢失数据？先确认你用的是哪种持久化模式
Redis 不会自动保证“kill -9 后数据不丢”，它只按配置的持久化策略执行写盘动作。AOF 和 RDB 行为差异极大，混用时还可能互相干扰。appendonly yes 开启 AOF 后，save 配置（RDB 触发条件）依然生效，但 RDB 快照内容不会覆盖 AOF 日志——除非你手动执行 bgrewriteaof 或配置了 aof-rewrite-incremental-fsync yes 等联动行为。
实操建议：
- 演练前先查
CONFIG GET appendonly和CONFIG GET save，确认当前生效的持久化方式 - 若只开 RDB，
kill -9后丢失的是上次save以来的所有写入；RDB 文件本身是全量快照，不依赖中间状态 - 若只开 AOF，且
appendfsync always，理论上每条命令都落盘，但实际受磁盘缓存和文件系统影响，kill -9仍可能丢失最后几毫秒日志 - 混合开启时，Redis 启动优先加载 AOF（如果存在且完整），否则才加载 RDB —— 这点常被忽略，导致误判“RDB 没生效”
用 redis-cli DEBUG RELOAD 模拟崩溃更可控，但不等价于 kill -9
DEBUG RELOAD 会强制清空内存、重新加载持久化文件，看起来像“重启恢复”，但它跳过了进程信号处理、文件描述符清理、AOF 缓冲区刷盘等真实崩溃路径。尤其当 AOF 处于 appendfsync everysec 模式时，DEBUG RELOAD 会把内核页缓存里还没刷到磁盘的那部分日志也一并加载，而 kill -9 一定丢失这部分。
实操建议：
- 想测真实数据一致性，必须用
kill -9（或kill -SIGKILL），不能只依赖DEBUG RELOAD - 执行
kill -9前，用redis-cli INFO persistence记下aof_current_size和rdb_bgsave_in_progress，确认没在做后台保存 - 杀进程后，检查 Redis 日志是否报
Failed to open the AOF file或Invalid argument reading RDB file—— 这说明持久化文件已损坏，不是数据丢失，而是加载失败
AOF 文件末尾截断、校验失败？这是 kill -9 最常见的“假丢失”
Redis AOF 在 everysec 或 no 模式下，依赖后台线程定时刷盘。kill -9 可能中断正在写的 AOF 文件，导致末尾多出半条命令（比如只写了 *3\r\n$3\r\nSET\r\n$4\r\nkey1\r\n 就断了），重启时 Redis 会拒绝加载整个 AOF 并报错：Unexpected end of file reading the append only file。
实操建议：
- 遇到 AOF 加载失败，先用
redis-check-aof --fix尝试自动修复（仅适用于末尾不完整命令） - 修复后别直接启动，先用
redis-check-aof --check验证语法合法性 - 若 AOF 文件被破坏严重（如中间字节损坏），
--fix会截掉损坏点之后所有内容 —— 这时数据确实丢了，但丢的是“不可解析的日志”，不是业务数据本身 - RDB 文件相对健壮，
kill -9不会导致 RDB 损坏（它是 fork 子进程写临时文件再原子 rename），但若刚好在rename前被杀，旧 RDB 仍可用
验证数据一致性不能只看 key 数量，要对比写入序列
重启后 DBSIZE 和写入前一样，不代表数据一致。比如 AOF 中有 INCR counter 连续执行 100 次，但最后 5 条没刷盘，重启后 counter 值比预期小 5 —— key 还在，值错了。
实操建议：
- 演练前用
redis-cli --scan --pattern '*' | xargs -n 1 redis-cli GET导出所有 key-value 快照（适合小数据量） - 对写密集场景，改用写入时打日志：每条 SET/INCR 命令同时记入本地文件，重启后用
redis-cli --pipe回放并比对最终状态 - 不要依赖
LASTSAVE判断 RDB 新鲜度 —— 它只反映上一次成功 save 时间，不反映是否被后续写操作覆盖 - 如果用云托管 Redis（如阿里云 Tair、腾讯云 CRS），它们底层可能禁用
fork或替换 AOF 实现，kill -9行为与社区版不一致，务必以厂商文档为准
真正难控的不是 kill 动作本身，而是 AOF 刷盘时机、文件系统缓存策略、以及你是否把“加载成功”误认为“数据完整”。每次演练后，盯住日志里那行 DB loaded from disk 后面有没有警告，比数 key 更管用。
