持久化

Redis持久化

RDB Redis DataBase

Redis会单独创建出一个子进程（fork）来进行持久化，会将数据写入到一个临时文件中，待持久化操作结束之后，临时文件会将已经持久化完成的文件替换掉，在这个过程中，主进程不进行任何IO操作，这也就确保RDB极高的性能，相比于RDB和AOF，RDB的模式会比AOF更加的高效。如果在进行大数据恢复，并且对于数据的精度要求不高，那么就可以使用RDB，Redis的持久化默认的也是RDB，在一般情况下（生产环境）不需要修改这个配置

RDB文件：dump.rdb

RDB触发机制

• 满足配置文件的save规则的情况下，会自动触发RDB规则

• 执行FLUSHALL命令，也会触发RDB规则，但是没有意义，因为文件内容为空

• 退出Redis，也会产生dump.rdb文件（退出Redis默认执行save命令）

• 在客户端中使用save或者bgsave命令，也可以触发RDB规则但是这两种规则有所不同

  • save命令会完全占用当前进程去进行持久化操作，也就是说，save命令只管保存，不管其他，只要有进程过来，一律阻塞
    bgsave命令会在后台运行，手动fork子进程进行操作，并且还会相应客户端的请求

恢复rdb

• 只需将rdb文件放入redis启动目录即可

• 查看rdb文件需要存放的位置

  127.0.0.1:6379> config get dir
  1) "dir"
  2) "D:\\Redis" #如果在这个目录下存在dump.rdb文件，启动时就会恢复其中的数据
  127.0.0.1:6379>
  

优点：

• 适合大规模数据恢复

• 对数据完整性要求不高

缺点：

• 在持久化的时候需要一定的时间间隔，如果在一定的间隔时间内服务器意外宕机，那么就会丢失最后一次持久化的数据

• 因为RDB持久化是需要fork出一份子进程进行IO操作的，也就是说，在原本的进程当中再复制出一个一模一样的进程作为子进程在内存中运行，内存的承载就会变为原来的两倍

AOF Append Only File

日志的形式来记录每一个写操作，只追加文件，不改写文件。Redis在启动时会自动加载AOF持久化的文件重新构建数据，也就是Redis重启会把AOF持久化文件中的信息从前到后执行一次以完成数据的恢复

AOF文件：配置文件中：appendonly filname "appendonly.aof"

开启aof：配置文件修改：appendonly yes。然后重启redis。

如果aof文件有错误，redis就启动不了。此时可以用redis-check-aof --fix appendonly.aof修复

优点：

• 每一次修改都同步，数据更完整
• 每秒同步，可能只会丢失一秒的数据
• 从不同步，效率最高。操作系统自动调度刷磁盘，性能是最好的。

缺点：

• aof文件远比rdb文件大，恢复速度慢
• aof运行效率比rdb慢

aof重写机制

配置文件中：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

如果aof文件大于64 m，fork一个新的进程，将文件进行重写。

创建一个新的aof文件替换原来aof文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多