Redis持久化

原 作者 许泽文 | 发表于 | 分类于 2021级

持久话就是把Redis中的数据写进磁盘里面

  • RDB:snapshot(快照)，保存不同时刻的状态，服务器启动的时候，启动rdb文件进行重新一次性启动
  • AOF：对于redis的每个操作，都进行保留，在服务器启动的时候，再重复之前的操作

RDB

RDB
RDB保存的是数据而不是操作

就是一指定的时间间隔执行数据集的快照（类似照相机）
（例如1分钟的时间间隔对Redis的状态进行保存一次）
在某一个时刻，将数据和状态以文件（RDB文件dump.rdb）的形式存在磁盘中，数据可靠性得到保证
在服务器挂机重启之后，把磁盘上的rdb文件，写回到Redis中

RDB在数据恢复的时候速度更快

6以前的变化频率比7小
7的快照配置文件只要触发以下的一个就会进行一次快照

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 change was performed
#   * After 300 seconds (5 minutes) if at least 100 changes were performed
#   * After 60 seconds if at least 10000 changes were performed

快照期间发生了数据修改

值的一提的是，BGSAVE命令是fork子进程来完成的，fork会使用到一体个写时拷贝（copy on write）机制，

在这里插入图片描述
正常Redis有两种快照的方式，一种是SAVE（阻塞，强烈不推荐），还有一种是BGSAVE(非阻塞)

在这里插入图片描述

做快照的时间

增量式快照

在执行BGSAVE的时候，父进程对数据进行修改，在子进程完成对之前的快照的形成时，会将新写入的数据，进行合并，实现快照更新
但是同样这也会引入内存空间，有点不好

我们可以使用一个机制：

在两次RDB快照期间使用AOF来保存之间的操作的命令，在第二次快照之后，就把这之间的AOF给删除掉，这样就能够解决AOF文件过大的问题

在这里插入图片描述

AOF

AOF保存的是操作，而不是数据

appendonly yes

AOF保存下来的文件是appendonly.aof

重写

重写就是把数据的指令集进行一个瘦身，只保留重建数据库的最小的指令集
如果发生重写的时候，还有服务器还有数据进来
在这里插入图片描述

RDB与AOF混合持久化

  1. 没有启动aof-use-rdb-preamble

在持久化，可以将RDB和AOF进行同时使用，如果有AOF就使用AOF进行恢复，没有的话就查看如果有RDB就使用RDB来进行恢复，否则就无法恢复数据

在这里插入图片描述
2. 启动`aof-use-rdb-preamble
在这里插入图片描述

redis在读取appendonly.aof数据的时候先把RDB格式的头读取，在读取AOF格式的尾，更好的对数据进行恢复

在这里插入图片描述

总结

AOF优点

  1. AOF每隔1s进行将缓冲区的数据写入到磁盘上，这样既能够保持高的性能，也能够在故障的时候最多只会丢失1s的数据，可以把损失降到最低
  2. AOF只有append操作，没有seek等操作，即使最后的数据被截断，也可以使用redis-check-aof工具来进行恢复
  3. AOF文件变大的时候，可以进行重写来缩小

AOF缺点

  1. AOF体积比RDB文件要大，数据的恢复速度也比较慢

RDB优点

  1. RDB可以快速恢复数据，比AOF一条一条进行恢复数据要快很多
  2. RDB对灾难恢复和数据迁移比较友好
    RDB缺点
  3. 内存快照，过快会造成频繁的对数据进行访问，过慢会导致数据的丢失