【Redis】Redis 持久化 AOF、RDB

本文主要是介绍【Redis】Redis 持久化 AOF、RDB—（七），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Redis 一旦服务器宕机，内存中的数据将全部丢失，从后端数据库恢复这些数据，对数据库压力很大，且性能肯定比不上从 Redis 中读取，会拖慢应用程序。所以，对 Redis 来说，实现数据的持久化，避免从后端数据库中进行恢复，是至关重要的。

一、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 来完成的，通过内存拷贝和两处日志保证数据的完整性。
在这里插入图片描述

二、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 日志记录这期间的所有命令操作。