AOF 持久化(appedn-only log file)
原理：记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。AOF文件中的命令全部命令以redis协议的格式来保存，新命令会被追加到文件的尾部。优点就是可以最大程度保证数据不丢，但缺点也显而易见，那就是日志记录量级比较大。
AOF文件的生成过程具体包括 命令追加，文件写入，文件同步
命令追加 ：Redis 在执行完一个写命令后，都会将执行的写命令追回到 Redis 内部的缓冲区的末尾
文件写入 ：接下来，缓冲区的写命令会被写入到 AOF 文件
文件同步 ：对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程。只有经过文件同步过程，AOF 文件才在硬盘中真正保存了 Redis 的写命令
配置文件中相关参数配置
|
1 2 3 4 5 |
vim /data/6379/redis.conf # 指定aof文件 appendfilename "appendonly.aof" appendonly yes appendfsync everysec |
| appenfsync选项 | 同步频率 |
|---|---|
| always | 每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能 |
| everysec | 每秒执行一次同步，显式地将多个写命令同步到硬盘 |
| no | 让操作系统来决定应该何时进行同步 |
重写AOF文件
AOF文件随着时间不断的写入，会逐渐堆积的越来越大，那么自然而然地恢复就越来越慢。redis为了解决该问题也提供了相应的措施，即重写AOF文件，用户可以向redis发送bgrewriteaof，这个命令会移除aof文件中冗余命令来重写AOF文件。它工作原理和快照持久化命令 BGSAVE 的工作原理类似，Redis 会创建一个子进程来负责对 AOF 文件进行重写。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK # 第一次查看该文件，AOF会记录每个重复操作， [root@db01 ~]# tail -n30 /data/6379/appendonly.aof ..... # 开始重写AOF文件 127.0.0.1:6379> BGREWRITEAOF Background append only file rewriting started # 此时再查看发现只保留了最新的K/V [root@db01 ~]# tail -n30 /data/6379/appendonly.aof |
倘若AOF文件已经很大 ，那么重写必然导致性能的下降，因此redis提供以下参数来配置重写
auto-aof-rewrite-percentage 当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写
auto-aof-rewrite-min-size 当 AOF 文件需要达到多大体积时才进行 AOF 重写
AOF优缺点
AOF优点：提供了多种同步频率，及时使用默认的，redis最多也就丢失1秒的数据而已。AOF文件可读性较强，如若不小心将flushall可以在AOF未重写时将AOF文件中的此命令去除后再重启来恢复数据
AOF缺点：也就是比RDB文件大，而且由于每秒的同步也较RDB性能消耗高
