三档对比
| 取值 | 刷盘时机 | 丢失窗口 | 性能 |
|---|---|---|---|
| always | 每条写命令后 | 接近零（取决于磁盘确认） | 吞吐明显下降 |
| everysec | 每秒一次（后台线程） | 约 1 秒 | 通用默认 |
| no | 由 OS 决定 | 通常数十秒内 | 最快 |
示例
示例
redis-cli CONFIG SET appendfsync everysec
redis-cli CONFIG GET appendfsynceverysec 由后台线程执行 fsync，避免主线程被磁盘延迟拖住，这是它成为默认值的原因。
本包目录（421 条）
数据结构与选型42 条
持久化56 条
- AOF 原理：追加日志与重放
- RDB 快照原理
- RDB 与 AOF 对比与混用
- appendfsync：always/everysec/no
- 持久化方案：先定可容忍丢失量
- fork 与写时复制（COW）机制
- 从 RDB 恢复数据
- appendonly 与 AOF 文件形态
- BGREWRITEAOF：AOF 重写
- SAVE 与 BGSAVE 的区别
- BGSAVE 失败与写保护
- INFO persistence 常用字段解读
- RDB 的触发方式
- 启动加载：数据库从文件恢复的顺序
- redis-check-aof 修复 AOF
- save 配置：自动快照节奏
- 物理备份：定时拷贝快照文件
- vm.overcommit_memory 与后台保存
- dbfilename 与 dir：数据文件位置
- 自动重写触发条件
- 运行时切换持久化配置
- redis-check-rdb 校验快照
- 7.0 多文件 AOF 结构
- 丢失窗口计算与业务对账
- aof-load-truncated：尾部截断处理
- SHUTDOWN 与保存行为
- 持久化监控指标清单
- 换机迁移：快照加配置的完整流程
- 禁用自动快照：save 空字符串
- 透明大页（THP）与 fork 延迟
- 持久化磁盘与文件系统的选择
- 数据安全组合：持久化之外的三层
- rdbcompression 与快照体积
- RDB 版本兼容与升级回滚
- no-appendfsync-on-rewrite 权衡
- 版本升级时的持久化注意点
- AOF 体积增长与磁盘水位
- rdbchecksum：快照完整性校验
- RDB 会保存 LFU/LRU 元数据
- 重写缓冲区：衔接新旧文件
- fsync 错误与数据安全
- 恢复演练：备份可用性的唯一证明
- 容器化实例的持久化注意点
- 持久化排查工具速查
- COW 内存监控方法
- 低峰快照与重写编排
- 备份完整性校验：md5 与抽检
- 纯缓存实例的持久化取舍
- AOF 时间戳注释（7.0）
- 备份文件的权限与加密
- 增量文件轮转与重写关系
- 磁盘告警时的应急处置顺序
- WAITAOF：等待 AOF 落盘确认
- DEBUG RELOAD 验证落盘数据
- 快照临时文件与残留处理
- manifest 完整性要求
appendfsync：always/everysec/no
appendfsync 控制刷盘时机：always 每条命令后 fsync（最稳最慢）、everysec 每秒一次（默认，折中）、no 交给操作系统（最快但丢失窗口不可控）。
易错点
- 把 everysec 理解为「不丢数据」是误判，断电或内核崩溃仍有约 1 秒丢失窗口
- 磁盘抖动时 everysec 可能退化为最长 2 秒一次的刷盘，需要监控 aof 相关延迟指标
数据来源与参考
- Redis 官方文档：redis.conf appendfsync 注释