dbfilename dump-test.rdb # 文件名为 dump-test.rdb
save 3600 1 # 在 3600 秒内发生一次更改,便会执行 bgsave
我们通过 redis-cli
进入操作
然后我们退出后便可在当前目录下看到刚刚生成的 dump-test.rdb
文件
说明我们配置是生效的,接着我们直接重启 Redis ,看是否还存在我们刚刚保存的数据
看到我们的数据,就说明 redis 持久化成功了。然后我们把刚刚生成的 dump-test.rdb
文件删除后重启 redis
这可以说明Redis 启动时是靠 .rdb 来恢复文件数据的。那我们上面一直说到的 bgsave
,那 bgsave
又是如何执行的呢?
我们在前面有说过两个概念 fork
和 cow
,不知道是否还有印象,这两个概念便是关键~!
bgsave
开始的时候会 fork 主进程得到一个新的子进程,而 子进程 是 共享
主进程的内存数据的。子进程会将数据写到磁盘上的一个临时的 .rdb
文件中,当子进程写完临时文件后,会将原来的 .rdb
文件替换掉。这个就是 fork 的核心,那什么是 cow 呢?cow 全称 copy-on-write
技术,当主进程执行读操作的时候是访问共享内存的,而主进程执行写操作的时候,则会拷贝一份数据,执行写操作。
具体流程如下:
这种持久化方式有什么优点呢?
-
方便持久化,只有一个
dump.rdb
文件 -
容灾性好,可以将文件保存到安全的磁盘中
-
性能最大化,fork 子进程来完成写操作,让主进程继续处理命令,将 IO 最大化,保证 Redis 的高性能
缺点也是有的:
-
数据安全性低,RDB 是间隔一段时间来持久化 (save) ,如果持久化期间 Redis 发生故障,那么就会造成数据丢失,所以这种方式适用于数据要求不是很严谨的情况下使用
-
保存时间长,如果数据量很大,保存快照的时间就会很长,会占用磁盘空间
优劣均沾,斟酌使用
点击关注公众号,Java干货****及时送达
二、AOF
AOF 全称 A
ppend O
nly F
ile (追加文件)。作用便是 Redis 处理的每一个写命令都会记录在 AOF 文件中,可以看做是命令日志文件。
该功能默认是关闭的,我们可以在 redis.conf
文件中查看有关于 AOF 相关的配置项
1、
appendonly yes # 开启 AOF 日志记录功能,默认是关闭的
2、
appendfilename “appendonly.aof” # AOF 文件的名称
以上两个配置项便是用来开启 AOF 日志记录,那么还有个额外的配置项也需要了解
3、
appendfsync everysec # AOF 命令记录的频率
该配置项有三个可选值
| 配置项 | 刷盘时机 | 优点 | 缺点 |
| — | — | — | — |
| Always | 同步刷盘 | 可靠性高,几乎不会丢失数据 | 性能影响较大 |
| everysec | 每秒刷盘 | 性能适中 | 最多丢失1秒的数据 |
| no | 操作系统控制 | 性能最好 | 可靠性较差,可能丢失大量的数据 |
有了解 Mysql 中 relay log 日志的同学,就不会对这种模型很陌生。
原理:它是将写命令追加到 AOF 文件的末尾,使用 AOF 持久化需要设置同步选项,从而确保写命令同步到磁盘文件上的时机,这是因为对文件进行写入并不会马上将内存同步到磁盘上,而是先存储到缓存区中,然后由操作系统决定什么时候同步到磁盘。
我们开启 AOF 记录功能查看下:
可以看出我们的每一个操作都已经记录到 AOF 文件中,我们这边通过重启 Redis 也一样能获取到刚刚存储的数据,说明持久化是有生效的~
如果你还在到处找面试题,不如上这个Java面试库面试小程序。
我们看到上面的 AOF 记录文件是不是觉得很规整?但是在线上环境中越规整反而不好,因为这文件主要是给机器看的,而不是跟我们看的,因此我们最好能够进行压缩。
为了解决AOF文件体积不断增大的问题,用户可以向Redis发送 bgrewriteaof命令,这个命令会通过 通过移除AOF文件中的冗余命令 来重写(rewrite)AOF文件,使AOF文件的体积变得尽可能地小。bgrewriteaof的工作原理和 bgsave 创建快照的工作原理非常相似:Redis会创建一个子进程,然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程,所以快照持久化因为创建子进程而导致的性能问题和内存占用问题
,在AOF持久化中也同样存在。
既然存在手动触发压缩,那也存在自动触发压缩,这就得说到配置文件中的两个配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
该配置项的意思为当AOF文件的体积大于64MB,并且AOF文件的体积比上一次重写之后的体积大了至少一倍(100%)的时候,Redis将执行bgrewriteaof命令。
总结下,它的优点如下:
-
数据安全。AOF 持久化可以配置 appendfsync 属性中的
always
,每进行一次写命令操作就会记录到 AOF 文件中一次 -
一致性。通过 append 模型写文件,即使中途服务器宕机,也可以通过
redis-check-aof
工具来解决数据一致性问题
缺点如下:
-
AOF 文件比 RDB 文件大,而且恢复速度慢
-
数据集大的时候比 RDB 文件启动效率低
同样是优劣均沾,斟酌使用
三、两者区别
分别介绍了两者,我们回顾一下两者有什么区别?
| 方面 | RDB | AOF |
| — | — | — |
| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不完整,两次备份之间会丢失 | 相对完整。取决于刷盘策略 |
| 文件大小 | 会有压缩,文件体积小 | 记录命令,文件体积很大 |
| 宕机恢复速度 | 很快 | 慢 |
| 数据恢复优先级 | 低,因为数据完整性不如AOF | 高,因为数据完整性更高 |
| 系统资源占用 | 高,大量CPU和内存消耗 | 低,主要是磁盘IO资源。且 AOF 重写时会占用大量CPU和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高 |
看完上面后,想必对两种持久化机制都有一定的了解了。两者都有优劣势,那我们该如何选择?这里给出几点意见~
读者福利
更多笔记分享
统资源占用 | 高,大量CPU和内存消耗 | 低,主要是磁盘IO资源。且 AOF 重写时会占用大量CPU和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高 |
看完上面后,想必对两种持久化机制都有一定的了解了。两者都有优劣势,那我们该如何选择?这里给出几点意见~
读者福利
[外链图片转存中…(img-0BTtdNCB-1719195981786)]
更多笔记分享
[外链图片转存中…(img-B7L2T3DI-1719195981787)]