redis持久化（AOF和RDB）

Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照

一、AOF日志（主线程执行）

AOF日志记录了redis所有增删改的操作，保存在磁盘上，当redis宕机，需要恢复内存中的数据时，可以通过读取AOF日志恢复数据，从而避免因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 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。

  但AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很缓慢，影响到正常使用

二、RDB内存快照（可以选择是否主线程执行 一般默认是创建个子线程执行）

类似照片记录效果的方式，就是把某一时刻的状态以文件的形式写到磁盘上，也就是快照,和 AOF 相比，RDB 记录的是某一时刻的数据

1.RDB存储哪些数据

执行的是全量快照，把内存中的所有数据都记录到磁盘中

2.是否堵塞主线程

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。

save：在主线程中执行，会导致阻塞；

bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

3.快照时数据能修改吗?

为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。

bgsave 子进程是由主线程 fork（复制线程） 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。

4.写时复制流程

此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。

也就是说，RDB读取的是原来的主线程的数据C，而修改的是数据C的数据副本

5.多久做一次快照？

如果先在 T0 时刻做了一次快照，然后又在 T0+t 时刻做了一次快照，在这期间，如果机器宕机了，那么只能按照 T0 时刻的快照进行恢复。所以期间的数据就丢失了，

所以为了尽可能恢复数据，t 值就要尽可能小，但是t 越小，就需要频繁地执行全量快照，也会带来两方面的开销。

一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。

另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。

所以可以做增量快照，所谓增量快照，就是指做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。（前提是我们需要记住哪些数据被修改了）

6.混合使用 AOF 日志和内存快照

AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。