Redis持久化

Redis持久化存储分为AOF与RDB两种模式，默认开启RDB。

RDB

RDB是在某个时间点将数据写入一个临时文件dump.rdb，通过dump.rdb实现数据的备份和恢复。优点：使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能；缺点：RDB 是间隔一段时间进行持久化，如果在这段时间内发生故障，会发生数据丢失，所以RDB适合要求不高的场景。

AOF

Append-only file，将Redis的每条写命令追加到日志文件的尾部，它所做的工作包括以下三个：

1. 追加(append)

将Redis的写命令追加到缓冲区aof_buf，不是直接写入文件，主要是避免频繁的IO操作成为Redis的瓶颈。

2. 同步(sync)

根据不同的同步策略将aof_buf中的内容同步到硬盘，Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数（通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘）和fsync同步函数（强制操作系统立刻将缓冲区中的数据写入到硬盘里）。AOF缓存区的同步文件策略由参数appendfsync控制，它有三个值：always、no、everysec。always：实时同步每一条写命令，硬盘IO成为性能瓶颈；no：直接调用操作系统的write操作，这样数据安全性无法保证；everysec：先调用write函数，然后每秒调用fsync同步函数，相当于always和no的折中，它是Redis的默认配置。

3. 重写(rewrite)

随着Redis服务器执行的写命令越来越多，AOF文件会越来越大，需要定期重写AOF文件，达到压缩的目的。AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件，不会对旧的AOF文件进行任何读取、写入操作!重写能够压缩文件的原因在于：过期数据不再写入文件，无效的命令不再写入文件（写了之后又删掉的），可以命令合并。重写流程如下：
（1）父进程执行fork操作创建子进程，由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据，因此Redis使用AOF重写缓冲区aof_rewrite_buf保存这部分数据，防止新AOF文件生成期间丢失这部分数据，也就是说，在重写期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区；
（2）子进程根据内存快照，按照命令合并规则写入到新的AOF文件；
（3）子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息；
（4）父进程把AOF重写缓冲区的数据写入到新的AOF文件；
（5）使用新的AOF文件替换老文件，完成AOF重写。

总结

AOF更加安全，可以将数据更加及时的同步到文件中，但是AOF需要较多的磁盘IO开支，且文件尺寸较大，文件内容恢复数度相对较慢；RDB，安全性较差，它是数据备份以及master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。不建议两者同时使用，根据场景需求确定。

参考：
https://blog.csdn.net/itcats_cn/article/details/82432530
https://blog.csdn.net/qq_35433716/article/details/82195106