redis配置文件基本解析以及RDB持久化与AOF持久化

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了redis配置文件基本解析以及RDB持久化与AOF持久化，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5189字，纯文字阅读大概需要8分钟。

内容图文

Maxmemory-samples ：设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个

redis RDB持久化

什么是redis持久化？用两个关键词来概括，就是RDB和AOF

RDB：Redis DataBase

AOF：Append Only File

那么RDB具体有什么用？

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

　　redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

　　如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork：Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

RDB保存的是dump.rdb文件

 

 

 

 

 

 

 

 

 我们为了方便解释，先把这个dump.rdb删掉，然后开两个窗口

 

 

 

 

 

 然后我们备份一份dump.rdb文件并命名为dump_back.rdb文件：

 

 

 之后我们在redis中进行清库操作，然后关闭连接：

 那么此时，我们的dump.rdb文件应该记录的是什么？

我们重新进入redis查看：

 可以看到 ，我们之前新增的12个key已经没有了，这是因为我们在执行flushall指令的时候它会立即生成一个新的dump.rdb文件并把原来的覆盖掉，

不过这时候我们之前备份的dump_back.rdb文件就可以派上用场了：

我们先把这次的dump.rdb文件删掉，然后把之前的备份文件复制一份并命名为dump.rdb:

 

 

 然后我们再进入redis查看，就可以看到之前 新增的12个key了：

 

 

 RDB是整个内存压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件。

如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数就可以了。

如果我们传入的参数很重要，要求它立即备份，也可以再redis中键入save来完成手动备份

 

 

 

 

 

 stop-writes-on-bgsave-error yes

这一行说的是当后台保存数据时错误，那么禁止继续写入数据，当然如果配置成no，表示你不在乎数据不一致或者有其他的收端发现和控制。

 

 

 rdbcompression ：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

 

 

 rdbchecksum：在存储快照后，还可以让rdis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

 

 

 总结一下：

如何触发RDB快照：

1、配置文件中默认的快照配置-冷拷贝后重新使用 可以cp dump.rdb dump_back.rdb

2、执行save命令或bgsave：

save：save时只管保存，其他不管，一律阻塞

bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

3、执行flushall命令，也会产生dump.rdb文件，单里面是空的，无意义

如何恢复：

将备份文件（dump.rbd)移动到redis的启动目录（你在哪个目录下启动的redis，哪个目录就是你的启动目录）下并启动服务即可

config get dir 获取目录

rdb的优势：

1、适合大规模的数据恢复

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

rdb的劣势：

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

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

如何停止：

动态所有停止RDB保存规则的方法：redis-cli config set save “”

redis AOF持久化：

AOF是什么：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

我们为了方便解释，先复制一个redis.conf 并命名为redis_aof.conf，然后把所有的rdb文件全部删掉：

 

 

 然后把redis_aof.conf里的appendonly 那一项改为yes（默认是no）

 

 然后我们在左边的窗口启动redis_aof.conf：

 

 然后我们会发现我们的目录里多出来一个appendonly.aof文件：

 

我们在redis中新增四个key：

 

 然后我们可以在appendonly.aof文件中可以看到它原模原样记录了我们的写动作（甚至我们在哪个库都记录下来了）：

 

 然后我们执行flushall指令：

 

我们会发现appendonly.aof文件中也把flushall这个指令记录下来了：

 

 

可以看到现在我们的库里面是空的：

 

 

 然后我们把appendonly.aof文件里面的那行flushall删掉（实际生产中不允许直接修改appendonly.aof文件）：

 

 然后我们重新启动redis：

 

 可以看到，我们的数据又恢复了。

第二个问题，如果dump.rdb和appendonly.aof文件共存，那么启动的是谁？

我们执行一个shutdown命令，它会自动生成一个dump.rdb文件：

 

 

 

 然后我们给appendonly.aof文件搞破坏：

我们键入一大堆无用字符，并保存：

 

 那么现在这个文件相当于被损坏掉了。

那么我们再启动redis的时候，如果能够正常启动，说明它找的是dump.rdb文件，如果不能正常启动，那说明它找的是aof文件：

 

 如上图，我们可以看到进程并没有被正常启动，说明它是先识别aof文件的，那么我们把aof文件删掉，只保留rdb文件，他就应该能正常启动了，我们来试一下：

 

 

 

 果然可以正常启动，这也再次证明redis启动的时候识别的是aof文件。

那如果不删除aof，怎么修复呢？

我们要用到src目录下的redis-check-aof文件：

 

 我们把它复制一份到我的启动目录下，然后执行如下操作：

 

 然后我们就可以正常启动redis了：

 

 ------------------------------------------------------------------未完待续---------------------------------------------------------

 

redis配置文件基本解析以及RDB持久化与AOF持久化

标签：日志文件   说明   memory   推荐   span   erro   file   策略   时间   

本文系统来源：https://www.cnblogs.com/wanghaoyu666/p/12256502.html

内容总结

以上是互联网集市为您收集整理的redis配置文件基本解析以及RDB持久化与AOF持久化全部内容，希望文章能够帮你解决redis配置文件基本解析以及RDB持久化与AOF持久化所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---