AOF写入和AOF重写对redis的阻塞以及解决方案

目录

• AOF写入策略
• AOF重写
• 阻塞
• 解决阻塞

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操作还没有返回，那么主线程就会阻塞。

解决阻塞

1. 减少IO竞争

   redis有一个配置：

   no-appendfsync-on-rewrite yes/no
   

   • 配置就是设置为yes时候，在aof重写期间会停止aof的fsync操作（io竞争没有了）。这种配置有一个潜在的风险：如果在aof重写期间redis宕机了，那么aof的数据便会丢失，可靠性下降。
   • 配置就是设置为no时候，aof重写期间还是会执行fsync，这个时候就会产生IO竞争，有可能阻塞主线程。

2. 使用ssd

   如果既需要性能，有需要可靠性。

   • 将配置设为no
   • 硬盘采用高速固态硬盘SSD