redis是一个内存数据库,当redis服务器重启,获取电脑重启,数据会丢失,我们可以将redis内存中的数据持久化保存到硬盘的文件中
持久化的方式有：
- RDB:定时将数据保存在硬盘中(dump.rdb)(默认)
- AOF:保存所有操作的命令
什么是AOF？
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF（仅追加文件）：AOF 持久性记录服务器收到的每个写入操作。然后可以在服务器启动时再次重播这些操作，重建原始数据集。命令的记录格式与 Redis 协议本身相同。
快照功能并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说，数据的耐久性并不是最重要的考虑因素，但是对于那些追求完全耐久能力（full durability）的程序来说，快照功能就不太适用了。
如何使用
默认情况下,redis是没有开启AOF(append only file),开启AOF功能需要设置配置:appendonly yes
AOF同步频率设置（什么时候进行写）
appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec
（默认）每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no
redis不主动进行同步，把同步时机交给操作系统。
aof文件-保存路径
redis6 - AOF保存文件的位置和RDB保存文件的位置一样,都是通过redis.conf配置文件的dir配置 redis7之后最新:dir + appenddirname
aof文件-保存名称，redis6只有一个
Redis7.0 Multi Part AOF的设计
- base:表示基础AOF,它一般由子进程通过重写产生,该文件最多只有一个
- incr:表示增量AOF,它一般会在AOFRW开始执行时被创建,该文件可能存在多个
- manifest清单文件,用来管理aof的
aof文件恢复指令：
异常修复命令:redis-check-aof --fix 进行修复
redis-check-of [--fix] <file.aof>
如果用户在运行redis-check-aof程序时给定了--fix参数，那么程序将对AOF文件进行修复。程序修复AOF文件的方法非常简单，它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有的命令，只保留那些位于出错命令之前的正确命令。在大多数情况下，被删除的都是AOF文件末尾的不完整的写命令。
AOF重写机制
启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
- 由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断的进行,AOF的文件会越来越大,文件越大,占用服务器内存越大以及AOF恢复要求时间越长
- 为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的峰值时,Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
- 可以手动使用命令bgrewriteaof来重新
自动触发:满足配置文件中的选项后,Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
手动触发:客户端向服务器发送bgrewriteaof命令
启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集：
如何工作
日志重写采用了和快照一样的写时复制机制。下面是过程：
- Redis调用fork()。于是我们有了父子两个进程。
- 子进程开始向一个临时文件中写AOF。
- 父进程在一个内存缓冲区中积累新的变更(同时将新的变更写入旧的AOF文件，所以即使重写失败我们也安全)。
- 当子进程完成重写文件，父进程收到一个信号，追加内存缓冲区到子进程创建的文件末尾。
- 搞定！现在Redis原子性地重命名旧文件为新的，然后开始追加新数据到新文件。
AOF优缺点
AOF优点：数据完整性好，最多丢失一秒的数据；文件可读性较好，可以手动修改文件。
AOF缺点：数据恢复速度慢；AOF运行速度慢于RDB
