都2024年了,不会还有人不知道redis的RDB和Aof吧?不知道没关系,看完这篇文章我相信你就会有个大概的了解和认识了
1. Redis持久化
1.1 持久化概念
Redis本身是一个基于内存的数据库,它提供了RDB持久化、AOF持久化两种方式,用来将存储在内存中的数据库状态保存到磁盘中。前者是保存了整个Redis数据库状态,而后者是保存了从Redis启动后所有执行的写命令。接下来我们就从这两方面展开。
1.2 生成RDB文件
触发RDB持久化过程分为手动触发和自动触发,手动触发的命令有两个,一个是SAVE
命令,一个是BGSAVE
命令,执行命令后会在根目录生成名为dump.rdb
的文件。
大家看下以下手动触发的使用。
# 手动生成RDB文件指令 127.0.0.1:6379> save OK 127.0.0.1:6379> bgsave Background saving started
另外RDB文件是在Redis启动时自动载入,如果把dump.rdb
文件删除,重启Redis后会发现原先的数据库状态都不存在了。
# 初始化 127.0.0.1:6379> set name JavaGetOffer OK 127.0.0.1:6379> get name "JavaGetOffer" 127.0.0.1:6379> save OK # 重启Redis 127.0.0.1:6379> get name "JavaGetOffer" # 删除dump.rdb,重启Redis后name为nil 127.0.0.1:6379> get name (nil)
1.3 两种命令的选择
SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理其他任何命令请求。
而BGSAVE命令则不进行阻塞,它会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程继续处理命令请求。可以在上面的指令中看到执行BGSAVE指令后,终端显示Background saving started
。
所以如果在业务高峰期要使用进行RDB持久化,建议是使用后者,可以防止某些请求丢失了。
1.4 生成AOF文件
AOF文件生成需要在Redis配置文件配置appendonly
的属性值。
appendonly yes
重启Redis执行写命令后,会生成appendonly.aof
文件。
也可以在终端手动设置appendonly
属性值。
config set appendonly yes
2. AOF重写
2.1 AOF概念
AOF文件是AOF持久化的产物,AOF持久化通过保存服务器所有执行的写命令来记录数据库状态。而AOF文件重写主要是为了解决AOF文件体积膨胀的问题。
对于一个键值对,AOF旧的文件会保存数十条对该键值对的修改命令,这样浪费了大量内存空间。
而AOF文件重写可以创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含任何浪费空间的冗余命令,使得新的AOF文件体积很小。
简单来说,就是新的AOF文件只会保存键值对的最终状态的创建命令。
2.2 多条命令记录键值
如果每个键的创建只有一条命令,在执行命令时可能会造成客户端输入缓冲区溢出。
Redis重写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元素的键时,如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD
常量的值,那么重写程序将使用多条命令来记录键的值,而不单单只使用一条命令。
2.3 AOF重写缓冲区
AOF重写过程中,有新的创建请求进来怎么办?可以把这些新的创建请求写入到一个缓冲区里。
Redis服务器会维护一个AOF重写缓冲区,该缓冲区会在子进程创建新AOF文件期间,记录服务器执行的所有写命令。
等新的AOF文件创建完成,Redis服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾,从而保证两个新旧AOF文件状态一致。
你好,我是胡广。 致力于为帮助兄弟们的学习方式、面试困难、入职经验少走弯路而写博客 🌹🌹🌹 坚持每天两篇高质量文章输出,加油!!!🤩
如果本篇文章帮到了你 不妨点个赞吧~ 我会很高兴的 😄 (^ ~ ^) 。想看更多 那就点个关注 吧 我会尽力带来有趣的内容 。
😎感兴趣的可以先收藏起来,还有大家在毕设选题,项目以及论文编写等相关问题都可以 给我留言咨询,希望帮助更多的人
更多专栏:
📊 Java设计模式宝典:从入门到精通(持续更新)📡 未完待续。。。
🎯 未完待续。。。
🔍 未完待续。。。
感谢订阅专栏 三连文章