redis进阶(三):持久化

最新推荐文章于 2022-09-07 15:05:36 发布

原创最新推荐文章于 2022-09-07 15:05:36 发布 · 218 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#reids #持久化

本文深入解析Redis的两种持久化方式：RDB和AOF。RDB通过快照将内存数据定期存储到硬盘，AOF则记录每次写命令，提供更高的数据安全性。结合使用可优化数据恢复。

文章目录

有时候我们希望redis在重启之后能够保存数据不丢失,然而reids的数据都存储在内存中操作,这个时候我们就需要对redis做持久化操作,将数据从内存中以某种形式同步到硬盘中,使得重启后可以根据硬盘中的记录恢复数据
redis支持两种持久化方式:

RDB方式,根据指定的规则"定时"将内存中的数据存储在硬盘上
AOF方式,每次执行命令后将命令本身记录下来

可以单独使用一种,但更多情况下是将二者结合使用
如果同时开启RDB和AOF,重启redis会使用AOF文件恢复数据,因为该方式可能丢失的数据更少

RDB方式

通过快照完成,当符合一定条件时redis会自动将内存中的所有数据生成一份副本并存储在硬盘上,这个过程即为快照
redis会在以下几种情况对数据进行快照:

根据配置规则进行自动快照
用户执行 SAVE 或 BGSAVE 命令
执行 FLUSHALL 命令
执行复制(replication)

根据配置自动快照

redis允许自定义快照条件,符合条件时redis自动执行快照,条件自定义由两个参数构成:
时间窗口M和改动的键的个数N
每当时间M内被更改的键个数大于N时,即符合自动快照条件
如 redis安装目录中包含的样例配置文件中预置的三个条件:

save 900 1
save 300 10
save 60 10000

每条快照条件占一行,以save开头,可以同时存在多个条件,条件之间为 “或” 关系,
save 900 1 的意思为:在15分钟内有一个或一个以上的键被更改则进行快照

该策略为异步快照

用户执行SAVE或BGSAVE命令

当进行服务重启、手动迁移以及备份时会需要手动执行快照操作,redis提供两条命令来完成

SAVE
redis同步进行快照操作,执行时阻塞所有来自客户端的请求,若数据比较多时,会导致redis较长时间不响应,所以尽量避免在生产环境中使用

BGSAVE
后台异步进行快照操作,快照时可以相应客服端请求,执行命令后redis立即返回OK,如果想知道是否执行完成,使用 LASTSAVE 命令,返回最近一次成功快照的unix时间戳

执行FLUSHALL命令

执行该命令时,redis会清除数据库中的所有数据
无论清空数据库时是否触发了自动快照条件,只要自动快照条件不为空,redis就会执行一次快照操作
没有定义自动快照条件时,该命令不会进行快照

执行复制

当设置了主从模式,使用复制操作时,即使没有定义自动快照条件,也没有手动执行过快照操作,也会生成RDB快照文件

快照原理

redis默认会将快照文件存储在redis当前进程的工作目录中的 dump.rdb 文件中,可通过配置 dir 和dbfilename 分别指定快照文件的存储路径和文件名
快照过程如下:

redis使用fork函数复制一份当前进程(父进程)的副本(子进程)
父进程继续接收并处理客户端发来的请求,子进程开始将内存中的数据写入硬盘中的临时文件
当子进程写完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照完成

执行fork函数时会使用写时复制策略,父子进程共享同一内存数据,父进程更改某片数据时,操作系统(类unix)会将该片数据复制一份以保子进程数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据
虽然父子进程共享数据,不会导致占用内存翻倍,但如果快照时写入操作较多,造成fork前后数据差异较大,会导致内存使用量显著超过实际数据大小

如果数据相对重要,希望将损失降低到最小,则可以使用AOF方式进行持久化