Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照
一、AOF日志
aof日志记录了redis所有增删改的操作，保存在磁盘上，当redis宕机，需要恢复内存中的数据时，可以通过读取aop日志恢复数据，从而避免因redis异常导致的数据丢失。
AOF的操作过程如下图
Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。除此之外，AOF 还有一个好处：它是在命令执行后才记录日志，所以不会阻塞当前的写操作。
mysql是先写日志后执行，为什么不和mysql采用一样的方式
第一：mysql到执行器的时候，已经对sql做了校验，不会出现错误命令，而redis不是
第二：mysql的redo日志是可以循环记录，大小是固定的，而AOF不是，大小是递增的，越大越影响性能，所以日志尽量是正确的
AOF 也有两个潜在的风险。
第一，如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。此时，因为命令没有记入日志，所以就无法用日志进行恢复了。
第二，AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。
这两个风险都是和 AOF 写回磁盘的时机相关的。这也就意味着，如果能够控制一个写命令执行完后 AOF 日志写回磁盘的时机，这两个风险就解除了。
三种写回策略
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；（基本不丢数据，性能无法保证）
Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；（高性能高可靠折中方案，最多丢失一秒数据）
No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。（高性能，但是如果宕机数据丢失较多）
AOF文件为什么无法过大
一是，文件系统本身对文件大小有限制，无法保存过大的文件；
二是，如果文件太大，之后再往里面追加命令记录的话，效率也会变低；
三是，如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用
AOF文件过大怎么办--》AOF 重写机制
AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。
和 AOF 日志由主线程写回不同，重写过程是由后台子进程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。
“一个拷贝，两处日志”
每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。