Redis AOF与RDB知识点总结

Redis AOF与RDB知识点总结

Redis拥有两种持久化方式：AOF与RDB

AOF

AOF的存储方式

AOF是以写日志的方式记录每次写命令，客户端所执行的每一条写命令都将记入AOF日志，类似于MySQL binlog。

AOF的数据恢复

如果发生宕机重启的情况，Redis会通过顺序执行AOF日志中的所有写命令的方式来进行数据恢复（操作回放）。

AOF与WAL的区别

关系型数据库中大多使用WAL预写日志（写前日志），先写日志，再执行语句。而Redis的AOF是写后日志，先更新内存里的数据，再将这一条写命令插入AOF日志中。

• 为什么Redis采用写后日志？

先执行写命令，再将命令写入AOF日志，如果该命令无效，则可直接返回，无需写入AOF日志。这样做可以避免无效的命令被写入AOF日志文件，减少AOF文件的空间占用。

AOF重写机制

由于AOF存储着Redis的每一条操作命令，文件体积随着时间的推移不断增大，如果发生宕机情况，过大的AOF日志会导致重启后操作回放速度变慢。为了减少磁盘空间占用及加快操作回放速度，Redis会定期重写AOF。

• AOF如何瘦身？

例：
如果有一个键值对被反复修改，Redis在重写AOF的过程中会将它之前的修改命令从AOF删除，只保留最后一个修改命令。
如果有一个键值对被多次修改，最后被删除了，那么Redis在重写AOF的过程中会将与该键值对有关的写命令全部删除。

• AOF重写过程

Redis会执行fork()操作创建一个子进程，专门来负责AOF重写操作。同时考虑到在重写过程中可能会有新的写命令，Redis会为这个AOF重写进程单独开启一个重写缓冲区。如果有新的写命令，这条命令会同时插入AOF缓冲区（主进程）与AOF重写缓冲区（子进程）。在重写过程中，AOF重写缓冲区里接收的操作命令会通过管道发送给AOF重写子进程。AOF重写子进程将已经重写完毕的原AOF数据与来自AOF重写缓冲区里的新数据一起写入新的AOF日志文件，最后替换旧AOF文件，整个重写过程完毕。

• fork是什么？
  fork()是unix和linux这种操作系统的一个api，而不是Redis的api。

• fork的作用
  fork()用于创建一个子进程（注意是子进程，不是子线程）。fork()出来的进程共享其父类的内存数据。注意：仅共享fork()出子进程的那一刻的内存数据，后期主进程修改数据对子进程不可见，同理，子进程修改的数据对主进程也不可见。

AOF的刷盘策略

appendfsync：aof持久化策略的配置；

• no表示不执行fsync，由操作系统来决定什么时候将数据同步到磁盘，速度最快，但是不安全。

• always表示每次写入都执行fsync，确保数据同步到磁盘，效率很低。

• everysec表示每秒执行一次fsync，可能会丢失这1秒的数据。一般选择 everysec ，可以兼顾安全性和效率。

RDB

RDB的存储形式

二进制文件，体积较小。

RDB持久化方式

RDB是把当前内存中的数据集快照（所有键值对数据）写入磁盘。

RDB数据恢复方式

将二进制文件加载进内存。

RDB触发方式

• 自动触发
  在配置文件中配置RDB触发时机

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

满足触发条件后，Redis会执行bgsave进行RDB持久化。

• 手动触发
  手动触发RDB的命令有两个：
  （1）、save：执行save命令将会阻塞Redis服务，在RDB持久化完成之前，Redis不能进行任何操作。
  （2）、bgsave：save的改良版。执行bgsave后，Redis会先判断当前是否存在fork()出来的子进程。如果子进程存在，则忽略该bgsave命令，如果子进程不存在，Redis会执行fork()操作创建一个子进程，异步进行RDB持久化，在进行持久化的同时，Redis服务仍然能正常运行。只有执行fork的那一刻会发生阻塞。

bgsave主进程与子进程的内存共享：
bgsave在创建子进程的时候，不可能把主进程中的数据复制一份到子进程（内存占用过大，直接翻倍）。所以Redis采用了copyonwrite技术来实现主进程与子进程共享内存数据。

内存共享的详细内容可以去看这篇文章：
https://blog.csdn.net/ctwctw/article/details/105147277