Redis持久化

思维导图

AOF日志

如何实现：写后日志，Redis先执行命令，把数据写入内存，然后记录日志（记录的是修改数据集的命令）

为什么要先执行命令再记日志

避免额外的检查开销

AOF日志文件中保存的是Redis执行修改数据集的命令。在写入日志文件时并不会检查这些命令是否有语法错误，所以，如果先写入日志在执行命令的话，日志中可能记录的就是错误的命令，当Redis使用日志进行数据恢复时，就会出错。

Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。

不会阻塞当前写操作

潜在风险

执行完命令，写日志之前宕机，则这条命令和相应数据有丢失的风险

有阻塞的风险

AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了

解决风险

3种写回策略

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘

• 同步写回”可以做到基本不丢数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免地会影响主线程性能；

Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲

• “每秒写回”采用一秒写回一次的频率，避免了“同步写回”的性能开销，虽然减少了对系统性能的影响，但是如果发生宕机，上一秒内未落盘的命令操作仍然会丢失。

No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

• 虽然“操作系统控制的写回”在写完缓冲区后，就可以继续执行后续的命令，但是落盘的时机已经不在 Redis 手中了，只要 AOF 记录没有写回磁盘，一旦宕机对应的数据就丢失了

性能问题：AOF是以文件的形式记录所接收到的所有写命令，命令越多，文件越大

文件系统对文件大小有限制，无法保存过大的文件

文件过大，在往里面追加命令记录的话，效率会变低

发生宕机，Redis恢复数据时，会重新执行AOF文件中的命令，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用

AOF重写机制：AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。

目的就是防止AOF日志文件过大

为什么重新机制可以把日志文件变小？

重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。

AOF重写会不会阻塞进程？

不会阻塞进程，和AOF日志有主线程写回不同，AOF重写是由主线程fork出后台的bgrewriteaof子线程完成，就是为了避免阻塞主线程

AOF重写是否存在潜在的阻塞点？

1.fork子进程

fork这个瞬间一定是会阻塞主线程的（注意，fork时并不会一次性拷贝所有内存数据给子进程，fork采用操作系统提供的写实复制(Copy On Write)机制，就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题，但fork子进程需要拷贝进程必要的数据结构，其中有一项就是拷贝内存页表（虚拟内存和物理内存的映射索引表），这个拷贝过程会消耗大量CPU资源，拷贝完成之前整个进程是会阻塞的，阻塞时间取决于整个实例的内存大小，实例越大，内存页表越大，fork阻塞时间越久。拷贝内存页表完成后，子进程与父进程指向相同的内存地址空间，也就是说此时虽然产生了子进程，但是并没有申请与父进程相同的内存大小。那什么时候父子进程才会真正内存分离呢？“写实复制”顾名思义，就是在写发生时，才真正拷贝内存真正的数据，这个过程中，父进程也可能会产生阻塞的风险，就是下面介绍的场景。

AOF重写过程中有写入场景

fork出的子进程指向与父进程相同的内存地址空间，此时子进程就可以执行AOF重写，把内存中的所有数据写入到AOF文件中。但是此时父进程依旧是会有流量写入的，如果父进程操作的是一个已经存在的key，那么这个时候父进程就会真正拷贝这个key对应的内存数据，申请新的内存空间，这样逐渐地，父子进程内存数据开始分离，父子进程逐渐拥有各自独立的内存空间。因为内存分配是以页为单位进行分配的，默认4k，如果父进程此时操作的是一个bigkey，重新申请大块内存耗时会变长，可能会产阻塞风险。另外，如果操作系统开启了内存大页机制(Huge Page，页面大小2M)，那么父进程申请内存时阻塞的概率将会大大提高，所以在Redis机器上需要关闭Huge Page机制。Redis每次fork生成RDB或AOF重写完成后，都可以在Redis log中看到父进程重新申请了多大的内存空间

AOF的重写日志为什么不重用AOF本身的日志？

AOF重写不复用AOF本身的日志，一个原因是父子进程写同一个文件必然会产生竞争问题，控制竞争就意味着会影响父进程的性能。二是如果AOF重写过程中失败了，那么原本的AOF文件相当于被污染了，无法做恢复使用。所以Redis AOF重写一个新文件，重写失败的话，直接删除这个文件就好了，不会对原先的AOF文件产生影响。等重写完成之后，直接替换旧文件即可。

RDB快照是一种内存快照，就是指内存中的数据在某一个时刻的状态记录。而RDB 记录的就是某一时刻的数据。

哪些数据会做快照？

Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中

如何生成快照文件？

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

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

做快照时是否能修改数据？

肯定是可以的。Redis借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。如图所示：这样既能保证快照的完整性，也允许主线程同时对数据进行修改

多久做一次快照？

频繁做快照的问题(例如每秒做一次快照)？

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

bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了（所以，在 Redis 中如果有一个 bgsave 在运行，就不会再启动第二个 bgsave 子进程）

增量快照

就是做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。但是着也会带来额外的空间开销问题，因为需要使用额外的元数据信息记录哪些数据被修改了。

跟 AOF 相比，快照的恢复速度快，但是，快照的频率不好把握，如果频率太低，两次快照间一旦宕机，就可能有比较多的数据丢失。如果频率太高，又会产生额外开销。如何既能利用 RDB 的快速恢复，又能以较小的开销做到尽量少丢数据呢？

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

内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。