redis无法真正实现“零丢失”，即使开启appendfsync always，因命令先执行后记日志、fsync不保证落盘到物理介质、进程被kill-9时日志未更新等原因，仍存在极小窗口数据丢失风险。
Redis 无法真正实现“零丢失”，即使开启 appendfsync always，仍存在极小窗口的数据风险。 这个结论不是留余地，而是由 Redis 的写入流程和操作系统行为共同决定的——它在设计上就放弃了绝对的强一致性保证。
为什么 appendfsync always 仍可能丢数据
Redis 的 AOF 日志是「写后日志」：命令先执行成功、再记日志。这意味着：
- 命令已成功写入内存，但还没来得及调用
fsync()就发生崩溃（如断电、内核 panic），这条命令就彻底丢失； -
fsync()本身不保证原子性：它只确保内核缓冲区数据刷到磁盘设备缓存，而某些磁盘固件或 RAID 卡会启用写缓存（write cache），此时数据仍在设备内存中，未落物理介质； - 即使硬件级刷盘完成，若 Redis 进程在
fsync()返回前被强制 kill（如kill -9），主线程阻塞未返回，日志文件实际未更新，后续恢复时该条命令也不会重放。
appendfsync always 的真实代价
它会让每次写命令都同步阻塞主线程，直到 fsync() 完成。实测中：
- 在普通 SATA SSD 上，单次
fsync()延迟常达 1–5ms，QPS 直接跌至 200 以下； - 遇到大 key（如 >1MB 的
SET），aof_buf写入+fsync()时间叠加，延迟可能突破 10ms； - 若同时触发 AOF rewrite（
bgrewriteaof），且no-appendfsync-on-rewrite为no（默认），主线程会在 rewrite 完成后补一次fsync，造成双倍阻塞。
比 always 更现实的“低丢失”配置
生产环境真正可用的平衡点是：
- 启用 AOF：
appendonly yes； - 设为
appendfsync everysec（默认），并确认no-appendfsync-on-rewrite yes，避免 rewrite 期间主线程被拖住； - 配合 RDB + 混合持久化：
aof-use-rdb-preamble yes，让 AOF 文件开头包含 RDB 快照，既压缩体积又加速加载； - 把 AOF 文件放在带掉电保护（PLP）的企业级 NVMe 或使用
sync=always挂载的 XFS 文件系统上，从存储层收窄丢失窗口。
真正关键但常被忽略的一环：启动时的加载顺序
Redis 启动时，只要 appendonly.aof 文件存在且校验通过，就一定优先加载它，完全忽略 dump.rdb。这点必须验证：
- 手动删掉
appendonly.aof后重启，看是否真的从dump.rdb恢复； - 若误删了 AOF 但保留了 RDB，不能靠“默认加载 RDB”侥幸——必须显式关闭 AOF（
appendonly no）再启动； - AOF 文件损坏会导致 Redis 拒绝启动，此时要用
redis-check-aof --fix appendonly.aof修复，而不是直接删掉重来。
所谓“零丢失”，本质是接受一个可量化的风险上限，并用架构手段（如主从 + 哨兵 + 多机房同步）把它摊薄到业务可容忍的水平。执着于单节点 always，反而容易因性能坍塌引发雪崩，得不偿失。
