首页 / REDIS / redis的rdb和aof
redis的rdb和aof
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了redis的rdb和aof,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1212字,纯文字阅读大概需要2分钟。
内容图文
由于redis的数据都直接存储在内存里,在服务器发生宕机时内存的数据会瞬间清空,那么必须要有重启时恢复数据的方法。
redis通过持久化机制将数据存储到磁盘中从而在服务器重启时恢复数据,这篇文章主要简介redis的持久化机制。
-
rdb:rdb是通过快照的方式实现持久化,redis定期将数据集快照写入磁盘。
- 触发RDB持久化过程分为手动触发和自动触发。手动触发的命令为save和bgsave。
save:会阻塞主进程,一般不使用;bgsave:fork操作创建子进程,子进程执行,完成后自动结束,阻塞只发生在fork阶段,阻塞时间很短。
自动触发都是通过bgsave的方式执行(save配置、从节点发送同步请求后主节点通过bgsave然后发送给从节点、默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave) - save配置:
save 900 1 #在900秒(15分钟)之后,如果至少有1个key发生变化,则dump内存快照。
save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。
save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。 - rdb的优点:
- RDB是一个紧凑压缩的二进制文件,代表Redis在某一个时间点上的数据快照。非常适合用于备份,全量复制等场景。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程机器或者文件系统中(如hdfs),用于灾难恢复。
- Redis加载RDB恢复数据远远快于AOF方式。
- rdb的缺点:
- RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
- RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题。
- 触发RDB持久化过程分为手动触发和自动触发。手动触发的命令为save和bgsave。
-
aof:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。
- 由于aof文件可能会变得很大,提供了文件重写机制,分为自动重写和手动重写
- aof配置:
appendfsync always # 每次有数据修改发生时都会写入AOF文件。
appendfsync everysec # 每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no # 从不同步。高效但是数据不会被持久化。
-
此外,redis4.0还推出了混合持久化策略,解决了重启时使用aof恢复慢和rdb保存时效不高的问题,有兴趣的读者可以自行了解。
原文:https://www.cnblogs.com/fcb-it/p/12920217.html
内容总结
以上是互联网集市为您收集整理的redis的rdb和aof全部内容,希望文章能够帮你解决redis的rdb和aof所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。