Redis----AOF持久化

最新推荐文章于 2023-07-29 15:34:12 发布

原创最新推荐文章于 2023-07-29 15:34:12 发布 · 385 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库

Redis 专栏收录该内容

1 篇文章

订阅专栏

本文详细介绍了Redis的AOF（Append Only File）持久化机制，包括AOF的开启配置、实现方式、载入和数据还原、重写过程以及优缺点。AOF通过保存服务器执行的写命令记录数据库状态，提供了比RDB更高的数据安全性，但也可能导致文件体积较大。AOF重写用于减少文件大小，使用子进程进行以避免阻塞主线程。在Redis重启时，会优先加载AOF文件来恢复数据。

参考博客：https://www.cnblogs.com/ysocean/p/9114267.html
这个博客总结的不错，在他的基础上稍加改动

文章目录

一、什么是AOF持久化

除了RDB持久化之外，Redis还支持AOF持久化功能。与RDB持久化通过保存数据库中的键值对记录数据库状态不同，AOF通过保存服务器所执行的写命令来记录数据库状态。

二、AOF配置开启

Redis.conf文件配置
在这里插入图片描述

appendonly：默认值为no，redis 默认使用的是rdb方式持久化，开启 AOF 持久化方式，需将 appendonly 修改为 yes。
appendfilename ：aof文件名，默认是"appendonly.aof"
appendfsync：aof持久化策略的配置；先缓存再写入，以下的写入代表缓存，同步代表写入
        always表示服务器在每个事件循环都要将aof_buf缓存区中的所有内容写入AOF文件中，并且同步AOF文件，以保证数据同步到磁盘，效率最低，但是安全性最高；
        everysec表示服务器在每个事件循环都要将aof_buf缓存区中的所有内容写入AOF文件中，每秒执行一次同步AOF文件。可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。
        no表示服务器在每个事件循环都要将aof_buf缓存区中的所有内容写入AOF文件中，但是何时对AOF文件进行同步，由操作系统控制决定，速度最快，但是不太安全；

三、AOF持久化的实现

通过redis.conf文件的配置appendonly，打开AOF的持久化过程。
通过通过redis.conf文件的配置appendfsync，实现持久化的不同方式
appendfsync：aof持久化策略的配置；先缓存再写入，以下的写入代表缓存，同步代表写入

always表示服务器在每个事件循环都要将aof_buf缓存区中的所有内容写入AOF文件中，并且同步AOF文件，以保证数据同步到磁盘，效率最低，但是安全性最高；
everysec表示服务器在每个事件循环都要将aof_buf缓存区中的所有内容写入AOF文件中，每秒执行一次同步AOF文件。可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。
no表示服务器在每个事件循环都要将aof_buf缓存区中的所有内容写入AOF文件中，但是何时对AOF文件进行同步，由操作系统控制决定，速度最快，但是不太安全；

四、AOF的载入和数据还原

重启 Redis 之后就会进行 AOF 文件的载入。

异常修复命令：redis-check-aof --fix 进行修复

五、AOF重写

        当文件过大时，占用服务器内存越大以及 AOF 恢复要求时间越长，需要重写AOF文件：
        AOF 文件重写并不是对原文件进行重新整理，而是从数据库读取现在的键值对，用一条命令去记录键值对代替之前记录这个键值对的多条命令，这就是AOF重写的实现原理。
       我们知道 Redis 是单线程工作，如果重写 AOF 需要比较长的时间，那么在重写 AOF 期间，Redis将长时间无法处理其他的命令，这显然是不能忍受的。Redis为了克服这个问题，解决办法是将 AOF 重写程序放到子程序中进行，这样有两个好处：

①、子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。

②、子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

使用子进程解决了上面的问题，但是新问题也产生了：因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。

为了解决这个数据状态不一致的问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。

这样将 AOF 重写对服务器造成的影响降到了最低。

五、AOF优缺点

优点：

①、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。

②、AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。

③、AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

缺点：

①、对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。

②、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。

③、RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

那么对于 AOF 和 RDB 两种持久化方式，我们应该如何选择呢？

如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，而且使用 RDB 还可以避免 AOF 一些隐藏的 bug；否则就使用 AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。Redis后期官方可能都有将两种持久化方式整合为一种持久化模型。

PS：经过验证，在Redis 5.0.5版本中，如果同时开启RDB和AOF进行持久化，在重启Redis时，只会加载AOF文件！！！