薛小嵩blog

Redis AOF同步刷盘机制：性能瓶颈分析与优化

 
  • 2024年 11月02日
  • 0 阅读

问题概述

在Redis生产环境中，有时会遇到这样一种情况：系统突然出现大量IO超时，而Redis日志中出现如下警告：

Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

AOF持久化过程中，fsync操作耗时过长，进而影响了Redis的整体性能

问题分析与定位

现象描述

  • 单个Redis实例短时间内出现大量IO timeout报错
  • Redis日志显示异步AOF fsync耗时过长
  • 服务器监控显示磁盘利用率(util)达到100%
  • 使用的是HDD磁盘而非SSD

性能瓶颈定位

典型的磁盘IO瓶颈问题。当Redis配置为appendfsync everysec时，后台线程负责每秒执行一次fsync操作将数据刷到磁盘。当磁盘IO负载过高时，fsync操作会被延迟，进而影响Redis的整体性能。

Redis AOF刷盘机制源码解析

要理解问题本质，需要深入Redis的源码。关键函数是flushAppendOnlyFile：

void flushAppendOnlyFile(int force) {
    // ...省略
    
    if (server.aof_fsync == AOF_FSYNC_EVERYSEC && !force) {
        /* 检查是否有后台fsync正在进行 */
        sync_in_progress = bioPendingJobsOfType(BIO_AOF_FSYNC) != 0;
        
        if (sync_in_progress) {
            if (server.aof_flush_postponed_start == 0) {
                /* 第一次推迟写操作，记录时间并返回 */
                server.aof_flush_postponed_start = server.unixtime;
                return;
            } else if (server.unixtime - server.aof_flush_postponed_start < 2) {
                /* 已推迟写操作不超过2秒，继续推迟 */
                return;
            }
            /* 推迟已超过2秒，无法再等待，执行写操作 */
            server.aof_delayed_fsync++;
            serverLog(LL_NOTICE,"Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.");
        }
    }
    
    // ...继续执行写操作...
}

关键逻辑解析

  1. 当设置appendfsync everysec时，Redis会检查是否有后台fsync正在进行
  2. 如果有fsync在进行，Redis会尝试推迟当前的写操作
  3. 但推迟时间不会超过2秒，超过2秒后会强制执行写操作
  4. 此时会记录aof_delayed_fsync并打印警告日志

为什么超过2秒Redis会阻塞？

源码注释中有一段关键说明：

When the fsync policy is set to ‘everysec’ we may delay the flush if there is still an fsync() going on in the background thread, since for instance on Linux write(2) will be blocked by the background fsync anyway.

这说明在Linux系统上，如果有后台fsync在进行，即使Redis调用write系统调用，该调用也可能被阻塞。这是Linux文件系统的工作特性，为了保证数据一致性。

AOF数据落盘全过程

Redis AOF持久化的完整流程：

命令写入 → AOF buffer(用户空间内存) → write系统调用 → 操作系统缓冲区(内核空间) → fsync → 物理磁盘

当fsync操作耗时过长时，整个链路会受到影响：

  • 如果推迟时间<2秒，Redis会继续推迟写操作
  • 如果推迟时间≥2秒，Redis会执行write调用，但该调用可能被阻塞
  • 阻塞的write调用会导致Redis主线程无法处理新请求，引发超时错误

多层次解决方案

1. 硬件层面优化

将HDD替换为SSD：这是最直接有效的解决方案。SSD的随机IO性能比HDD高出数个数量级，可以显著减少fsync的耗时。

2. 操作系统层面优化

调整Linux内核参数vm.dirty_bytes：

# 查看当前设置
sysctl -a | grep vm.dirty_bytes
vm.dirty_bytes = 0  # 0表示由系统自动控制

# 设置为较小值，例如32MB
echo "vm.dirty_bytes=33554432" >> /etc/sysctl.conf
sysctl -p

这会使操作系统更频繁地执行fsync，避免积累过多脏页导致单次fsync耗时过长。

3. Redis配置层面优化

  1. 调整AOF同步策略：
    • appendfsync always：每次写入都fsync，最安全但性能最差
    • appendfsync everysec：每秒fsync一次，平衡性能和安全性
    • appendfsync no：由操作系统决定何时fsync，性能最好但安全性最差
  2. 优化AOF重写相关配置：
    • 设置no-appendfsync-on-rewrite yes：在AOF重写期间不执行fsync
    • 调整auto-aof-rewrite-percentage和auto-aof-rewrite-min-size控制AOF重写触发频率
  3. 主从架构差异化配置：
    • 主库：关闭或降低AOF同步频率，提高写性能
    • 从库：开启AOF，保证数据安全性

实践建议

根据业务对数据安全性和性能的不同需求，可采取不同策略：

  1. 高安全性场景：
    • 使用SSD存储
    • 保持appendfsync everysec
    • 调整操作系统参数优化fsync性能
  2. 高性能场景：
    • 主从复制+从库AOF的架构
    • 主库设置appendfsync no或完全关闭AOF
    • 利用RDB提供周期性持久化
  3. 平衡方案：
    • 使用SSD存储
    • 设置appendfsync everysec
    • 设置no-appendfsync-on-rewrite yes
    • 合理配置AOF重写参数

总结

Redis AOF刷盘过程中的性能问题通常源于磁盘IO瓶颈。当fsync操作耗时过长时，会导致Redis写操作阻塞，进而影响整体服务质量。通过了解AOF的工作机制和刷盘流程，我们可以从硬件、操作系统和Redis配置三个层面优化性能。

对于生产环境，建议根据业务需求选择合适的持久化策略，必要时使用SSD替代HDD以提供更可靠的IO性能。同时，合理监控Redis的aof_delayed_fsync指标和磁盘IO性能，可以帮助我们及早发现并解决潜在的AOF刷盘性能问题。

搜索