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重写