首页 > 应用开发 > Java > 刨根问底Redis——Redis的持久化机制
我们前两章已经讲了,redis是内存型的数据库,他之所以快是因为数据存储在内存。那么数据存储在内存会有什么问题呢?当然就是当服务重启或者服务器宕机内存数据就被清除,我们就无法访问之前存储的数据了。那么怎么解决这个问题呢?当然就是使用持久化技术
持久化(Persistence),即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。持久化是将程序数据在持久状态和瞬时状态间转换的机制。比如JDBC就是一种持久化机制。文件IO也是一种持久化机制。
redis也是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化,持久化可以避免因进程退出而造成数据丢失;
redis支持两种持久化方式, RDB和 AOF
RDB持久化把当前进程数据生成快照(.rdb)文件保存到硬盘的过程,有 手动触发和 自动触发
手动触发有save和bgsave两命令
save****命令:阻塞当前Redis,直到RDB持久化过程完成为止,若内存实例比较大会造成长时间阻塞,线上环境不建议用它
bgsave****命令:redis进程执行fork操作创建子进程,由子线程完成持久化,阻塞时间很短(微秒级),是save的优化,在执行redis-cli shutdown关闭redis服务时,如果没有开启AOF持久化,自动执行bgsave;
bgsave流程如下:
命令:config set dir /usr/local //设置rdb文件保存路径
备份:bgsave //将dump.rdb保存到usr/local下
恢复:将dump.rdb放到redis安装目录与redis.conf同级目录,重启redis即可
1,查看启动目录,没有dump文件
2、set值
3、执行shutdown命令关掉服务,查看目录,已经生成对应的dump文件。
4、重启redis服务,发现数据还存在
5、执行shutdown命令关掉服务,并把dump文件删除
6、启动redis在进行查看,发现存储的数据已经不存在了。
优点:
缺点:
针对RDB不适合实时持久化,redis提供了AOF持久化方式来解决
开启方式就是在redis.conf设置:appendonly yes (默认不开启,为no)
默认文件名:appendfilename "appendonly.aof"
| 配置信息 | 含义 |
| appendonly yes | 启用aof持久化方式 |
| appendfsync always | 每收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用 |
| appendfsync everysec | 每秒强制写入磁盘一次,性能和持久化方面做了折中,推荐 |
| no-appendfsync-on-rewrite yes | 正在导出rdb快照的过程中,要不要停止同步aof |
| auto-aof-rewrite-percentage 100 | aof文件大小比起上次重写时的大小,增长率100%时,重写 |
| auto-aof-rewrite-min-size 64mb | aof文件,至少超过64M时,重写 |
设置appendonly yes;
如果同时都开启了AOF和RDB 两种持久化方式,那么加载顺序及流程如下
一直想整理出一份完美的面试宝典,但是时间上一直腾不开,这套 一千多道面试题宝典,结合今年金三银四各种大厂面试题,以及 GitHub 上 star 数超 30K+ 的文档整理出来的,我上传以后,毫无意外的短短半个小时点赞量就达到了 13k,说实话还是有点不可思议的。
内容涵盖:Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、SpringBoot、SpringCloud、RabbitMQ、Kafka、Linux等技术栈(485页)
内容涵盖:Java基础、JVM、高并发、多线程、分布式、设计模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、数据库、云计算等
由于篇幅限制,详解资料太全面,细节内容太多,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
需要的小伙伴,可以一键三连, 点击这里获取免费领取方式!
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70000438/viewspace-2784419/ ,如需转载,请注明出处,否则将追究法律责任。