Redis AOF 刷盘策略：`always`, `everysec`, `no` 的权衡与数据安全 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众，早上好/下午好/晚上好！

今天咱们聊聊 Redis 的 AOF (Append Only File) 刷盘策略，这玩意儿听起来有点高大上，但其实就是个关于“写日记”的故事。Redis 就像个记账先生，AOF 就是他的日记本，记录着每一笔交易。关键在于，这个记账先生有多认真，多久把日记本上的内容誊写到永久保存的地方（磁盘）。

Redis 提供了三种记账策略，也就是 AOF 的刷盘策略：always, everysec, no。这三个策略，就像三种不同程度的强迫症，程度不同，各有优劣。咱们一个个来分析。

1. always：最靠谱的“强迫症患者”

这个策略，你可以理解为“笔笔都记，记完就存”。每次 Redis 接收到写命令，立马把这个命令追加到 AOF 文件，并且立刻强制刷盘。啥叫强制刷盘？就是确保数据真正写到磁盘上，而不是还在操作系统的缓冲区里晃悠。

优点： 数据安全性最高！只要 Redis 成功响应了客户端，你就百分之百确定数据已经安全落地了。就算服务器突然断电，数据也不会丢失。堪称数据安全的“铁布衫”。
缺点： 性能最低！每次写命令都要刷盘，磁盘 I/O 负担很重，会严重影响 Redis 的性能。就像你每次写一个字都要盖一个钢印，累死个人。

代码演示（伪代码，仅用于说明原理）

def handle_write_command(command):
    # 1. 将命令追加到AOF文件
    append_to_aof(command)
    # 2. 强制刷盘
    fsync(aof_file_descriptor)
    # 3. 响应客户端
    send_response_to_client("OK")

2. everysec：折中的“时间管理大师”

这个策略，就像个“时间管理大师”，他会把一段时间内的写命令先缓存在内存里，然后每秒钟刷一次盘。

优点： 性能和数据安全之间取得了较好的平衡。相比 always，它减少了刷盘的次数，提高了性能。相比 no，它能保证最多丢失 1 秒的数据。
缺点： 在最坏的情况下，可能会丢失 1 秒的数据。如果服务器在刷盘前崩溃，那这 1 秒内的数据就没了。

代码演示（伪代码，仅用于说明原理）

import time

aof_buffer = []

def handle_write_command(command):
    # 1. 将命令追加到AOF缓冲区
    aof_buffer.append(command)
    # 2. 响应客户端
    send_response_to_client("OK")

def background_aof_flush():
    while True:
        time.sleep(1) # 每秒执行一次
        if aof_buffer:
            # 1. 将缓冲区内容写入AOF文件
            for command in aof_buffer:
                append_to_aof(command)
            # 2. 强制刷盘
            fsync(aof_file_descriptor)
            # 3. 清空缓冲区
            aof_buffer.clear()

3. no：放飞自我的“佛系青年”

这个策略，就像个“佛系青年”，他只管往 AOF 文件里写，但啥时候刷盘，完全交给操作系统自己决定。

优点： 性能最高！因为省去了频繁刷盘的开销，Redis 可以全速运行。
缺点： 数据安全性最低！一旦服务器崩溃，可能会丢失大量数据。操作系统刷盘的时间是不确定的，可能几秒，也可能更久。

代码演示（伪代码，仅用于说明原理）

def handle_write_command(command):
    # 1. 将命令追加到AOF文件
    append_to_aof(command)
    # 2. 响应客户端
    send_response_to_client("OK")
    # 注意：没有强制刷盘操作！ 操作系统自己决定何时刷盘

总结：三种策略的对比

为了方便大家理解，我把这三种策略的优缺点整理成表格：

策略	数据安全性	性能	适用场景
`always`	最高	最低	对数据安全性要求极高，可以容忍较低性能的场景。例如：金融系统、支付系统等。
`everysec`	较高	较高	对数据安全性有一定要求，同时对性能也有较高要求的场景。例如：电商平台的订单系统、社交应用的消息系统等。
`no`	最低	最高	对数据安全性要求不高，对性能要求极高的场景。例如：缓存系统、计数器等。但实际上生产环境很少使用，除非对数据丢失极度不敏感且对性能有极致追求。

选择哪个策略？这是一个灵魂拷问

选择哪个策略，取决于你的应用场景和对数据安全性的要求。

如果你的应用对数据安全性要求极高，宁可牺牲性能也要保证数据不丢失，那就选择 always。
如果你的应用对数据安全性有一定要求，同时对性能也有较高要求，那就选择 everysec。这也是 Redis 官方推荐的策略。
如果你的应用对数据安全性要求不高，对性能要求极高，那你可以选择 no。但请务必三思而后行，因为数据丢失的风险是很高的。实际上生产环境很少使用，除非对数据丢失极度不敏感且对性能有极致追求。

AOF 重写：日记本的“瘦身”

AOF 文件会随着时间的推移越来越大，因为每一条写命令都会被记录下来。为了避免 AOF 文件过大，Redis 提供了 AOF 重写 (rewrite) 机制。

AOF 重写，就是把当前 Redis 数据库的状态，用最少的命令重新生成一个新的 AOF 文件。比如，你先执行了 SET key value，然后又执行了 DEL key，那么在 AOF 重写之后，这个 key 就不存在于 AOF 文件中了，相当于给日记本“瘦身”。

AOF 重写的过程

Redis 会创建一个子进程 (fork)。
子进程会扫描 Redis 数据库中的数据，并将当前数据库的状态以 Redis 命令的形式写入到一个新的 AOF 文件中。
在重写期间，Redis 主进程会继续处理客户端的请求。为了保证数据的一致性，Redis 会将新的写命令同时写入到旧的 AOF 文件和一个内存缓冲区中。
当子进程完成 AOF 重写后，Redis 主进程会将内存缓冲区中的数据追加到新的 AOF 文件中。
最后，Redis 会用新的 AOF 文件替换旧的 AOF 文件。

AOF 重写的触发条件

Redis 提供了两个配置项来控制 AOF 重写的触发：

auto-aof-rewrite-percentage：当前 AOF 文件大小超过上一次重写后 AOF 文件大小的百分比。默认值是 100%，表示当前 AOF 文件大小是上一次重写后 AOF 文件大小的两倍时，触发重写。
auto-aof-rewrite-min-size： AOF 文件最小体积，只有当 AOF 文件大于这个值时，才可能重写，即使达到了auto-aof-rewrite-percentage的条件。默认值是 64MB。

配置 AOF

redis.conf中找到相关的配置

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF 和 RDB：双保险，更安心

Redis 还提供了 RDB (Redis Database) 持久化机制。 RDB 就像给 Redis 拍快照，定期把内存中的数据保存到磁盘上。

AOF 和 RDB 可以同时使用，也可以只使用其中一种。如果同时使用 AOF 和 RDB，Redis 会优先使用 AOF 来恢复数据，因为 AOF 记录了更详细的写操作，数据恢复的完整性更高。

总结：选择适合你的持久化方案

特性	AOF	RDB
数据安全性	根据 `appendfsync` 配置，可高可低	取决于快照频率，可能丢失较多数据
性能	相对较低，尤其 `always` 策略	较高
文件大小	通常比 RDB 文件大	通常比 AOF 文件小
恢复速度	相对较慢	较快
适用场景	对数据安全性要求较高，可以容忍较低性能	对数据安全性要求不高，对性能要求较高
重写	支持 AOF 重写，减小文件大小	不适用

建议：

如果对数据安全性要求极高，建议同时开启 AOF 和 RDB。
如果对数据安全性要求较高，但对性能也有较高要求，建议开启 AOF，并选择 everysec 策略。
如果对数据安全性要求不高，对性能要求极高，可以只开启 RDB。但请务必评估数据丢失的风险。
如果可以容忍一定程度的数据丢失，仅仅使用RDB即可，RDB的性能更高。

关于 AOF 的一些小技巧

定期检查 AOF 文件： 确保 AOF 文件没有损坏。可以使用 redis-check-aof 工具来检查 AOF 文件。
监控 AOF 重写： 关注 AOF 重写的时间和频率，避免影响 Redis 的性能。
合理配置 AOF 重写的触发条件： 根据实际情况调整 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size。

好了，今天的分享就到这里。希望大家对 Redis 的 AOF 刷盘策略有了更深入的了解。记住，选择适合自己的策略才是最重要的。就像找对象一样，没有最好的，只有最合适的。

感谢各位的观看！下次再见！

发表回复 取消回复

发表回复取消回复