redis数据安全（三）数据持久化 AOF

接上一篇RDB，本篇看下Redis数据持久化的第二种方式AOF。

目录

一、AOF原理

1、写入机制：

2、缓冲机制：

3、重写机制?：

4、运行流程

二、AOF文件配置

1、开启AOF：

2、自动触发AOF重写?

3、重写规则：

三、AOF的备份恢复：

1、正常恢复：

2、异常恢复：

四、重写流程：

五、AOF优缺点：

1、优点：

2、缺点：

---

一、AOF原理

?AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

1、写入机制：

Redis 在收到客户端修改命令后，先进行相应的校验，如果没问题，就立即将该命令存追加到 .aof 文件中，也就是先存到磁盘中，然后服务器再执行命令。这样就算遇到了突发的宕机情况情况，也只需将存储到 .aof 文件中的命令，进行一次“命令重演”就可以恢复到宕机前的状态。

2、缓冲机制：

在上述执行过程中，有一个很重要的环节就是命令的写入，这是一个 IO 操作。Redis 为了提升写入效率，它不会将内容直接写入到磁盘中，而是将其放到一个内存缓存区（buffer）中，等到缓存区被填满时采用异步真正将缓存区中的内容写入到磁盘里，Linux 系统的 fsync() 函数可以将指定文件的内容从内核缓存刷到硬盘中。

?但是如果机器突然宕机，AOF 日志内容可能还没有来得及完全刷到磁盘中，这个时候就会出现日志丢失。Redis 为数据的安全性考虑，同样为 AOF 持久化提供了策略配置appendfsync：有三个选项，见第二部分配置参数

3、重写/压缩机制?：

Redis 在长期运行的过程中，aof 文件会越变越长。如果机器宕机重启，“重演”整个 aof 文件会非常耗时，导致长时间 Redis 无法对外提供服务。为了让 aof 文件的大小控制在合理的范围内，Redis 提供了 AOF 重写机制

（1）自动触发AOF重写：Redis 为自动触发 AOF 重写功能，提供了相应的配置策略，默认配置

? ?

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

（2）手动执行BGREWRITEAOF命令，这个命令通过移除AOF文件中的冗余命令来重写AOF文件

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令。
即使 Bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改

4、运行流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内
（2）AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
（4）redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

二、AOF文件配置

1、开启AOF：

?AOF默认不开启，可以在 redis.conf 文件中对AOF进行配置开启：

??

appendonly no # 是否开启AOF，yes：开启，no：不开启，默认为no
appendfilename "appendonly.aof" # aof文件名称，默认为appendonly.aof
dir ./ # aof文件所在目录，默认./，表示执行启动命令时所在的目录

2、自动触发AOF重写/压缩?

见原理部分。

3、appendfsync同步频率：

默认为Everysec，有三个选项

（1）Always：服务器每写入一个命令，就调用一次 fsync函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据，但是其执行速度较慢；
（2）Everysec（默认）：服务器每一秒调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据，通常都使用它作为 AOF 配置策略；
（3）No：服务器不主动调用 fsync 函数，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的，所以这种策略，不确定性较大，不安全。

4、重写/压缩规则：

no-appendfsync-on-rewrite：重写时，不会执行appendfsync操作

no-appendfsync-on-rewrite no

?该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘，也就是说在进行AOF重写的时候，如果此时有写操作进来，此时写操作的命令会放在aof_buf缓存中（内存中），而不会将其追加到旧的AOF文件中，这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压力。
（1）默认是ON，表示关闭，即在AOF重写时，会对AOF缓冲区中的数据做同步磁盘操作，这在很大程度上保证了数据的安全性。但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

（2）如果no-appendfsync-on-rewrite为yes，不写入aof文件，只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）。

但在数据量很大的场景，因为两者都会消耗磁盘IO，对磁盘的影响较大，可以将其设置为“yes”减轻磁盘压力，但在极端情况下可能丢失整个AOF重写期间的数据。

三、AOF的备份恢复：

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

1、正常恢复：

（1）修改默认的appendonly no，改为yes

（2）将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）

（3）恢复：重启redis然后重新加载

2、异常恢复：

（1）修改默认的appendonly no，改为yes

（2）如遇到aof文件损坏，通过?redis-check-aof --fix appendonly.aof?进行恢复，appendonly.aof是文件名

四、重写流程：

1、手动执行 bgrewriteaof命令触发重写，判断是否当前有bgfsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
2、主进程fork出子进程执行重写操作，保证主进程不会阻塞
3、子进程遍历redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整性以及新AOF文件生成期间的新的数据修改动作不会丢失
4、子进程写完新的AOF文件后，向主进程发送信号，父进程更新统计信息
5、主进程把aof_rewrite_buf中的数据写入到新的AOF文件
6、使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

五、AOF优缺点：

1、优点：

（1）备份机制更稳健，丢失数据概率更低

（2）可读的日志文本，通过操作AOF文件，可以处理误操作

2、缺点：

（1）比RDB占用更多的磁盘空间

（2）恢复备份速度要慢

（3）每次读写都同步的话，有一定的性能压力

（4）存在个别bug，造成不能恢复