>[info] AOF AOF（append only file）持久化：与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端 对服务器的每一次写操作命令到日志当中，并将这些写操作以 Redis协议追加保存到以后缀为aof文件末尾。 >[info] 使用AOF 开启 AOF 功能需要设置配置：**appendonly yes**，默认不开启。AOF 文件名通过 appendfilename 配置设置，默认文件名 appendonly.aof。保存路径同 RDB 持久化方式一致，通过 dir 配置指定。 >[info] 持久化配置 **启用aof持久化方式：appendonly yes** 当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到 服务器状态的aofbuf缓冲区的末尾。 ***** **appendfsync always：** 每次收到写命令就立即强制写入磁盘，最慢的大概只有几百的TPS，但是保证完全 的持久化，**不推荐使用** 。 ***** **appendfsync everysec：** 每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，**推荐** 。 ***** **appendfsync no：** 完全依赖os，性能最好,持久化没保证，Redis不会主动调用fsync去将AOF日志内容同 步到磁盘，所以这一切就完全依赖于操作系统。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲 区中的数据写到磁盘上。 ***** **文件的写入和同步：** * 为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些、数据写入到文件的时候， 操作系统通常会将写入数据暂时保存在一个内存缓冲区里面。等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。 * 这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓 冲区里面的写入数据将会丢失。为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制让操作系 统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。  **说明：** 1）所有的写入命令会追加到aof_buf（缓冲区）中。 2）AOF缓冲区根据对应的策略向硬盘做同步操作。 3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。 4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。 >[info] 重写机制说明 * AOF将客户端的每一个写操作都追加到aof文件末尾，随着命令不断写入 AOF，文件会越来越大，为了解决这 个问题，Redis引入AOF 重写机制压缩文件体积。= * AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。 **比如：** 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c 可以转化为：lpush list a b c。 ***** **AOF 重写降低了文件占用空间，除此之外，另一个目的是：更小的 AOF 文件可以更快地被Redis加载。** >[info] 触发机制 ### **AOF 重写过程可以手动触发 和 自动触发：** **1. 手动触发：** 直接调用 bgrewriteaof 命令。 **2. 自动触发：** 根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。 ``` # 表示运行 AOF 重写时文件最小体积，默认为 64MB。 auto-aof-rewrite-min-size # 代表当前 AOF 文件空间（aof_current_size）和上一次重写后 AOF 文件空间（aof_base_size）的比值。 auto-aof-rewrite-percentage ``` **示例：** ``` # 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发 auto-aof-rewrite-percentage：100 auto-aof-rewrite-min-size：64mb ``` >[info] AOF追加阻塞 当开启AOF持久化时，常用的同步硬盘的策略是everysec，用于平衡性能和数据安全性。对于这种方式， Redis使用另一条线程每秒执行fsync同步 硬盘。当系统硬盘资源繁忙时，会造成Redis主线程阻塞。  **阻塞流程分析：** 1）主线程负责写入AOF缓冲区。 2）AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间。 3）主线程负责对比上次AOF同步时间： ·如果距上次同步成功时间在2秒内，主线程直接返回。 ·如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完成。 通过对AOF阻塞流程可以发现两个问题： 1）everysec配置最多可能丢失2秒数据，不是1秒。 2）如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率 >[info] AOF注意事项 **AOF文件损坏：** 在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器 时，Redis服务器会拒绝载入这个aof文件， 可以通过命令修复aof并恢复数据。 ``` redis-check-aof-fix file.aof ``` >[info] AOF的优缺点 **AOF的优点：** 1. AOF可以设置 完全不同步、每秒同步、每次操作同，默认是每秒同步。因为AOF是操作指令的追加，所以可以频繁的大量的同步。 2. AOF文件是一个值追加日志的文件，即使服务宕机为写入完整的命令，也可以通过redis-check-aof工具修复这些问题。 3. 如果AOF文件过大，Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。 4. AOF文件是有序保存数据库的所有写入操作，易读，易分析。即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。例如不小心FLUSHALL，可以非常容易恢复到执行命令之前。 **AOF的缺点：** 1. 相同数据量下，AOF的文件通常体积会比RDB大。因为AOF是存指令的，而RDB是所有指令的结果快照。但 AOF在日志重写后会压缩一些空间。 2、在大量写入和载入的时候，AOF的效率会比RDB低。因为大量写入， AOF会执行更多的保存命令，载入的时候也需要大量的重执行命令来得到最后的结果。 RDB对此更有优势。 >[info] AOF常用配置总结 ``` appendonly no：是否开启AOF appendfilename "appendonly.aof"：AOF文件名 dir ./：RDB文件和AOF文件所在目录 appendfsync everysec：fsync持久化策略 no-appendfsync-on-rewrite no：AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失 AOF重写期间的数据；需要在负载和安全性之间进行平衡 auto-aof-rewrite-percentage 100：文件重写触发条件之一 auto-aof-rewrite-min-size 64mb：文件重写触发提交之一 aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件 ```