redis持久化的介绍

1. rdb

1.1 rdb简介

rdb：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的snapshot快照，它恢复时是将快照文件直接读到内存里。

工作机制：每隔一段时间，就把内存中的数据保存到硬盘上的指定文件中。

rdb是默认开启的！

redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何io操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那rdb方式要比aof方式更加的高效。

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

1.2 rdb保存策略

save 900 1    900 秒内如果至少有 1 个 key 的值变化，则保存

save 300 10   300 秒内如果至少有 10 个 key 的值变化，则保存

save 60 10000  60 秒内如果至少有 10000 个 key 的值变化，则保存

save “”  就是禁用rdb模式；

1.3 rdb常用属性配置

1.4 rdb数据丢失的情况

两次保存的时间间隔内，服务器宕机，或者发生断电问题。

1.5 rdb的触发

         ①基于自动保存的策略

         ②执行save，或者bgsave命令！执行时，是阻塞状态。

         ③执行flushdb命令，也会产生dump.rdb，但里面是空的，没有意义。

         ④当执行shutdown命令时，也会主动地备份数据

2. aof

2.1 aof简介

1. aof是以日志的形式来记录每个写操作，将每一次对数据进行修改，都把新建、修改数据的命令保存到指定文件中。redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
2. 默认不开启，需要手动开启
3. aof文件的保存路径，同rdb的路径一致。
4. aof在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！
5. 当rdb和aof存的不一致的情况下，按照aof来恢复。因为aof是对rdb的补充。备份周期更短，也就更可靠。

2.2 aof保存策略

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。

appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

2.3 aof常用属性

2.4 aof文件的修复

如果aof文件中出现了残余命令，会导致服务器无法重启。此时需要借助redis-check-aof工具来修复！

命令：redis-check-aof  --fix 文件

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。如果你想了解更多相关内容请查看下面相关链接