先说一个核心判断：appendfsync always 这个配置确实能大幅提升数据安全性，但光设这一项远远不够——它必须配合 appendonly yes、正确的文件路径权限，以及避免重写期间的策略降级，否则合规审计时，大概率会被判定为“形同虚设”。
确认 AOF 已全局启用，且 appendfsync always 生效
不少人踩过这个坑：只改了 appendfsync always，却忘了前置条件——appendonly 必须为 yes。不然，这个参数压根不参与任何 fsync 流程。配置文件中，这两行必须同时出现：
appendonly yes appendfsync always
改完只靠重启是不行的。用 redis-cli CONFIG GET appendfsync 实时验证返回值是否真是 always。要是返回的还是 everysec，说明没 reload，或者 CONFIG REWRITE 失败了。更要命的是，AOF 重写期间（bgrewriteaof 运行时），Redis 会临时把策略降级为 no——这是硬编码行为，没得躲。说白了，就是即使你设了 always，重写的那几十秒内，写入仍可能丢失。如果要强合规，必须盯着 info Persistence 里的 aof_rewrite_in_progress 字段，绝对别在这期间执行关键事务。
设置 AOF 文件所在目录的磁盘权限与归属
AOF 文件（默认叫 appendonly.aof）最终落盘位置由 dir 配置项决定，不是 appendfilename 能控制路径的。常见错误就是把 dir 设成 /tmp 或 root 用户的家目录，结果 Redis 进程（通常以 redis 用户跑）没写权限，AOF 写入静默失败——INFO persistence 里 aof_enabled 显示为 1，但 aof_current_size 始终是 0。
dir必须指向 Redis 进程有读写权限的目录，比如/var/lib/redis- 执行
sudo chown redis:redis /var/lib/redis和sudo chmod 755 /var/lib/redis - 确保这个目录所在的磁盘不是 tmpfs 或 overlayfs（容器场景尤其要小心），否则掉电即丢，一切都白搭。
验证方式很简单：手动触发一次 redis-cli BGREWRITEAOF，然后查 ls -l /var/lib/redis/appendonly.aof，确认属主是 redis 并且文件大小在增长。
禁用自动重写，或严格控制重写时机
auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 触发的后台重写，会强制把 fsync 策略切成 no，这与 always 的设计目标直接冲突。合规场景下，建议这么干：
- 设
auto-aof-rewrite-percentage 0，彻底禁用自动重写。 - 如果需要重写，改乘人工调度：在业务低峰期执行
redis-cli BGREWRITEAOF，并提前确认aof_rewrite_scheduled是否为 0，避免两个机制叠在一起。 - 重写完成后，检查新 AOF 文件权限是否继承正确——有时候重写会以 root 权限创建临时文件，导致后续写入失败。
别忘了 no-appendfsync-on-rewrite no 这个开关。它默认是关闭的，意味着重写时主线程的写命令会被阻塞，直到重写完成才继续 fsync。这虽然牺牲了一点吞吐量，但保证了“非重写时段始终 always”的确定性，比开启后异步写入更可控。
实际部署中，容易被忽略的三件事
合规不是配完就万事大吉了。上线之前，必须做这三件事：
- 用
strace -p $(pgrep redis-server) -e trace=fsync,write抓一段真实写入，确认每次SET之后真的有fsync系统调用，而不是只有write。 - 检查
redis.conf是否被 systemd 或容器启动脚本覆盖了。有些镜像会通过command覆盖掉appendfsync的值。 - 确认磁盘本身支持 barrier/fsync。比方说，某些云盘挂载时用了
barrier=0或nobarrier，那always也只是个摆设。
真正卡住合规验收的，往往不是配置项写没写对，而是重写期间的策略降级、文件权限错位、或底层存储不认 fsync 这三条中的某一条。别等到审计报告出来了再追悔莫及。
