16.Redis 持久化 AOF 操作

zhanglei 2022年07月30日 343次浏览

16.Redis 持久化 AOF 操作

AOF(Append Only File)

AOF 被称为追加模式，或日志模式，是 Redis 提供的另一种持久化的策略。它能够储存 Redis 服务器已经执行过的命令，每当有一个修改数据库的命令被执行时，服务器就将命令写入到 appendonly.aof 文件中，该文件存储了服务器执行过的所有修改命令，因此，只要服务器重新执行一次 .aof 文件，就可以实现还原数据的目的。这就是 AOF 持久化机制。

AOF 持久化流程

说到日志，我们可能会想到数据库的写前日志，即在数据写入之前，将这些修改数据的记录存到日志文件中，然而Redis的AOF日志正好相反，他是在Redis数据存入内存（服务器先执行命令），后再将这些操作命令记录到日志中的。如下图所示：

这样做一方面是因为，这些操作命令成功存入到Redis中后，就表明这些语句是正确的，那存入日志文件的时候就不需要再对这些操作命令进行校验了。既保证了存储到日志文件的命令行时正确的，而且也加快了存储的效率。

AOF 的缺点及解决方法

缺点

1、由于 Redis 将数据存入内存，因此在存储数据后，记录日志的服务器宕机了，这样就会导致这次存储的数据丢失。（这个算是用 Redis 存储数据的通病）

2、记录日志和存储数据都是采用的主线程，那当记录日志时，就不可避免的会导致主线程的阻塞，影响Redis的性能。

解决方法

为了解决以上两个问题，Redis 设计了三种写回策略，如 Redis.conf中：

Always，同步写回：服务器每个写命令执行完，就调用一次 fsync 函数，立马同步地将缓冲区里面的命令写回磁盘；这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据，但是其执行速度较慢；

Everysec（默认），每秒写回：服务器每一秒调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据，通常都使用它作为 AOF 配置策略；

No，操作系统控制的写回：服务器不主动调用 fsync 函数，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的，所以这种策略，不确定性较大，不安全。

开启 AOF 持久化

AOF 机制默认处于未开启状态，可以通过修改 Redis 配置文件开启 AOF，如下所示：

AOF 重写机制（压缩原aop文件）

当Redis运行越久，记录的日志文件就会越大，那么记录日志的时间就会越长，对主线程的阻塞就会越来越严重，并且恢复数据重新执行aof文件里的命令时也会花费很长的时间，这个时候就需要用到AOF重写机制了。

手动触发 AOF 重写

手动执行BGREWRITEAOF命令，开始重写 aof 文件，如下所示：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

通过上述操作后，服务器会生成一个新的 aof 文件，该文件具有以下特点：

新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令。

下表对原有 aof 文件和新生成的 aof 文件做了对比，如下所示：

从上表可以看出，新生成的 aof 文件中，它的命令格式做了很大程度的简化。

自动触发 AOF 重写

Redis 为自动触发 AOF 重写功能，提供了相应的配置策略。如下所示：修改 Redis 配置文件，让服务器自动执行 BGREWRITEAOF 命令。

#默认配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb 
#表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。

该配置项表示：触发重写所需要的 aof 文件体积百分比，只有当 aof 文件的增量大于 100% 时才进行重写，也就是大一倍。比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。

上一篇： Day 10 下一篇： Day 9