（七）Redis 持久化 AOF、RDB
Redis 一旦服务器宕机，内存中的数据将全部丢失，从后端数据库恢复这些数据，对数据库压力很大，且性能肯定比不上从 Redis 中读取，会拖慢应用程序。所以，对 Redis 来说，实现数据的
持久化
，避免从后端数据库中进行恢复，是至关重要的。
1、AOF 日志
AOF 日志是先执行命令，把数据写入内存，然后才记录日志以文本形式保存，如下图："*3" 表示命令有三个部分组成，每部分由"$+数字"开头，"$3 set"表示这部分有三个字节，指"set"命令，"$7 testkey"表示该部分有七个字节，即"testkey"命令，以此类推。
AOF 写后日志只有命令能执行成功，才会被记录到日志中，避免额外的检查开销，也避免了出现记录错误命令的情况，而且不会阻塞当前的写操作。说完
优点
说
风险
，如果刚执行完命令还没有来得及记日志就宕机了，就有丢失的风险。其次，AOF 日志在主线程中执行，如果在把日志文件写入磁盘压力过大，可能会带来阻塞风险。
AOF 风险与写回磁盘有关，针对这个问题提供了三种
写回策略
，即配置项 appendfsync 的三个可选值：
（1）Always 同步写回：每个写命令执行完，立马同步地将日志写回磁盘
（2）Everysec 每秒写回：每个写命令执行完，先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘
（3）No 操作系统控制的写回：每个写命令执行完，先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
三种策略各有优劣，汇总如下：
选定写回策略，并非万事大吉，随着接收的写命令越来越多，AOF 文件会越来越大，带来性能问题。主要是以下三个方面：
（1）文件系统本身对文件大小有限制，无法保存过大的文件
（2）如果文件太大，之后再往里面追加命令记录的话，效率也会变低
（3）如果发生宕机，AOF 中记录的命令要一个个被重新执行，文件太大导致整个恢复过程就会非常缓慢，影响 Redis 正常使用
日志文件太大了怎么办呢？这个时候，AOF
重写机制
就登场了。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令，而重写时，只会根据这个键值对当前的最新状态，为它生成对应的写入命令，这样一来，一个键值对在重写日志中只用一条命令就行了，并且在日志恢复时，只用执行这条命令，就可以直接完成这个键值对的写入了。举个栗子：
AOF 重写并不会阻塞主线程，重写过程是由后台线程 bgrewriteaof 来完成的，通过内存拷贝和两处日志保证数据的完整性。
2、RDB 内存快照
内存快照 RDB 就是 Redis DataBase 的缩写，和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复。但同时也面临两个问题：
（1）对哪些数据做快照？这关系到快照的执行效率问题。
（2）做快照时，数据还能被增删改吗？这关系到 Redis 是否被阻塞，能否同时正常处理请求。
为了提供所有数据的可靠性保证，全量快照会把内存中的所有数据都记录到磁盘中，一个都不少。这样会花费很多时间，全量数据越多，RDB 文件就越大，往磁盘上写数据的时间开销就越大。对于 Redis 而言，它的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的操作。Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave：
（1）save：在主线程中执行，会导致阻塞。
（2）bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。
bgsave 避免主线程阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，不能修改正在执行快照的数据。Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。示意如图：
简单来说，主线程 fork 生成 bgsave 子进程，可共享主线程的所有内存数据。bgsave 子进程运行读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），则主线程和子进程互不影响。如果主线程要修改数据（例如图中的键值对 C），则会生成该数据的副本，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。
至此上面提的两个问题“哪些数据做快照”、“做快照时数据能否修改”就都解决了。新的问题又产生了，快照间隔多久做一次合适？如果在第二次快照前宕机，就可能出现数据丢失的问题，如果太频繁又会出现第一个还没结束，第二个又开始的情况。虽然 bgsave 执行时不阻塞主线程，但是，如果频繁地执行全量快照，也会给磁盘带来额外的开销，并且 bgsave 子进程需要通过 fork 操作从主线程创建出来，频繁操作依然会阻塞主线程。
此时，增量快照就登场了，做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。比如 T1 和 T2 时刻如果再做快照，我们只需要将被修改的数据写入快照文件就行。
虽然我们记住哪些数据被修改了，但“记住”这个操作，需要我们使用额外的元数据信息去记录，这会带来额外的空间开销问题。有时改动较小时，又要引入的额外空间区记录，有些得不偿失。此时我们就可以混合使用 AOF 日志和内存快照的方法，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。
如图，T1 和 T2 时刻的修改，用 AOF 日志记录，在第二次做全量快照时，就可以清空 AOF 日志，因为修改都已经记录到快照中了。这个方法既能享受到 RDB 文件快速恢复的好处，又能享受到 AOF 只记录操作命令的简单优势，可谓鱼和熊掌兼得。