目录
- 1、背景
- 2、appendfsync always（同步写回）
- 【1】工作机制
- 【2】特点
- 【3】实现原理
- 3、appendfsync everysec（每秒写回，默认配置）
- 【1】工作机制
- 【2】特点
- 【3】实现原理
- 4、appendfsync no（操作系统控制）
- 【1】工作机制
- 【2】特点
- 【3】实现原理
- 5、三种策略对比
1、背景
redis的AOF（Append Only File）持久化提供了三种不同的写回策略，通过appendfsync配置项来控制，这三种策略在数据安全性和性能之间提供了不同的权衡选择。
2、appendfsync always（同步写回）
【1】工作机制
1、每次写入命令后立即执行fsync，将数据同步到磁盘
2、确保每个写命令都持久化到磁盘后才返回成功响应
【2】特点
| 维度 | 说明 |
|---|---|
| 数据安全性 | 最高，级别不会丢失数据 |
| 性能影响 | 最差，每次写入都有磁盘I/O等待 |
| 适用场景 | 对数据一致性要求极高的金融场景 |
| 吞吐量 | 低，受限于磁盘IOPS |
【3】实现原理
1、命令写入内存数据库
2、命令追加到AOF缓冲区
3、立即调用fsync()将缓冲区内容写入磁盘
4、返回客户端成功响应
3、appendfsync everysec（每秒写回，默认配置）
【1】工作机制
1、后台线程每秒执行一次fsync
2、折中方案，平衡性能和数据安全
【2】特点
| 维度 | 说明 |
|---|---|
| 数据安全性 | 可能会丢失最近1秒的数据 |
| 性能影响 | 中等，突发写入可能有延迟 |
| 适用场景 | 大多数生产环境的推荐配置 |
| 吞吐量 | 较高，适合常规业务场景 |
【3】实现原理
1、命令写入内存数据库
2、命令追加到AOF缓冲区
3、主线程不阻塞，后台线程每秒检查一次缓冲区，缓冲区有数据就执行fsync()同步到磁盘
4、返回客户端成功响应
4、appendfsync no（操作系统控制）
【1】工作机制
1、完全由操作系统决定何时同步到磁盘
2、通常30秒一次，取决于内核配置
【2】特点
| 维度 | 说明 |
|---|---|
| 数据安全性 | 最低，可能丢失较多数据 |
| 性能影响 | 最好，无额外同步开销 |
| 使用场景 | 允许数据丢失的非关键业务 |
| 吞吐量 | 最高，适合大量写入场景 |
【3】实现原理
1、命令写入内存数据库
2、命令追加到AOF缓冲区
3、立即返回客户端成功响应
4、操作系统在适当时机调用fsync()
5、三种策略对比
| 策略 | 数据安全性 | 性能 | 数据丢失风险 | 适用场景 |
|---|---|---|---|---|
| always | 极高 | 差 | 几乎为零 | 金融交易，支付系统 |
| everysec | 高 | 中 | ≤1秒数据 | 大多数web应用 |
| no | 低 | 优 | 可能丢失多秒数据 | 缓存、非关键数据 |
