【Redis】05 持久化

Redis提供了不同的持久性选项：

要理解的最重要的事情是RDB和AOF持久性之间的不同权衡。

让我们从RDB开始：

通常的指示是，如果您希望获得与PostgreSQL可以提供的功能相当的数据安全性，则应同时使用两种持久性方法。

如果您非常关心数据，但是在灾难情况下仍然可以承受几分钟的数据丢失，则可以仅使用RDB。

有很多用户单独使用AOF，但我们不建议这样做，

因为不时拥有RDB快照对于进行数据库备份，加快重启速度以及AOF引擎中存在错误是一个好主意。

默认情况下，Redis将数据集的快照保存在磁盘上名为的二进制文件中

如果数据集中至少有M个更改，可以将Redis配置为使其每N秒保存一次数据集，或者可以手动调用SAVE或BGSAVE命令。

例如，如果更改了至少1000个键，此配置将使Redis每60秒自动将数据集转储到磁盘上：

在指定的时间间隔内将内存中的数据集快照写入磁盘，

也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，

再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，

这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，RDB方式要比AOF方式更加的高效。

RDB的缺点是最后一次持久化后的数据可能丢失。

Fork的作用是复制一个与当前进程一样的进程。

新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

如何获取目录：

适合大规模的数据恢复

对数据完整性和一致性要求不高

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就 会丢失最后一次快照后的所有修改

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，

只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis

重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

Aof保存的是appendonly.aof文件

正常恢复

异常恢复

整理我们的理解及处理方式

只做缓存：

同时开启两种持久化方式

性能建议