AOF写入策略
由appendfsync参数控制：
| 可配置的值 |
说明 |
| always |
命令写入buf后调用系统调用fsync同步AOF文件，fsync完成后线程返回。 |
| no |
命令写入buf后调用系统调用write操作，后续fsync同步操作由操作系统来完成，一般为30秒一次。 |
| everysec |
命令写入buf后调用系统调用write操作，后续fsync同步操作专门线程每一秒调用一次。 |
everysec是always和no的折中，是性能和安全性的这种，是redis默认的配置，也是比较推荐的配置。
当使用everysec配置时，redis会使用后台子线程完成完成fsync同步。
AOF重写
AOF重写是由后台子线程完成，但是AOF会有大量的IO操作，最终会和AOF的fsync进行磁盘的竞争。
阻塞
虽然在everysec配置下aof的fsync是由子线程进行操作的，但是主线程会监控fsync的执行进度。
主线程在执行时候如果发现上一次的fsync操作还没有返回，那么主线程就会阻塞。
解决阻塞
-
减少IO竞争
redis有一个配置：
no-appendfsync-on-rewrite yes/no
- 配置就是设置为yes时候，在aof重写期间会停止aof的fsync操作（io竞争没有了）。这种配置有一个潜在的风险：如果在aof重写期间redis宕机了，那么aof的数据便会丢失，可靠性下降。
- 配置就是设置为no时候，aof重写期间还是会执行fsync，这个时候就会产生IO竞争，有可能阻塞主线程。
-
使用ssd
如果既需要性能，有需要可靠性。
经验首页