appendfsync always 必须配合 appendonly yes、严格目录权限及禁用自动重写才真正生效；AOF 重写期间策略强制降级为 no，会导致数据丢失风险，需人工调度并监控 aof_rewrite_in_progress。
AOF 配置 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 且大小在增长。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 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 这三个点中的某一个。
