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

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
作者:iBrake
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.
原文地址:https://www.cnblogs.com/Brake/p/14352772.html