一、关于持久化
持久化,利用永久性存储介质将数据进行保存,在特定的时间将保存的数据据进行恢复的工作机制成为持久化,持久化的目的是防止数据的意外丢失,确保数据安全性。
redis的持久化有两种方式:
- RDB
将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据 - AOF
将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程
这一节内容我主要讲解的是RDB方式。
二、使用save指令快速体验RDB
准备工作
在【redis教程】8、linux下安装、配置redis这一节中我讲解了启动redis时使用配置文件,那么,下面我就通过使用配置文件的方式启动redis,配置文件的内容不变,如下:
port 6379
daemonize yes
logfile "redis-6379.log"
dir /an-dev/redis-4.0.14/data
启动redis并查看是否启动成功:
由于输出路径在data目录下,我现在看一下data目录下的文件:
可以看到目前只有两个日志文件。
进行持久化
进行持久化其实很简单,就执行save
命令就可以完成数据的持久化,
现在我去data目录下看一下持久化的文件:
可以看到多了一个dump.rdb文件,cat一下瞅一眼,找到了我刚写入数据库的一条数据city:wuhan
三、RDB持久化的一些配置
上面我使用save指令完成了数据的持久化,并输出在了data目录下,除了输出目录我还可以配置:文件名、是否压缩、是否校验等。
port 6379
daemonize yes
logfile "redis-6379.log"
dir /an-dev/redis-4.0.14/data
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
四、数据的恢复
重启redis服务就会自动恢复数据。
五、bgsave指令(非阻塞式)
bgsave
指令与save
的不同指出在于前者是非阻塞式的,当数据量较大是执行save
会阻塞比较长的时间,线上环境不建议使用save
,使用bgsave
比较好。
bgsave
指令是对save
阻塞问题做的优化,redis内部所有涉及RDB操作都采用bgsave的方式,save命令基本可以放弃使用。
六、RDB持久化的触发条件(自动持久化)
限定时间内key的变化数量达到指定数量即进行持久化
save second changes
second: 监控时间范围
changes:监控key的变化量,注意是变化量,不是key的数量。
port 6379
daemonize yes
logfile "redis-6379.log"
dir /an-dev/redis-4.0.14/data
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 600 20
600秒内变化量达到20个就持久化。
七、RDB的优缺点
优点
- RDB是一个紧凑压缩的二进制文件,存储效率高
- RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据全量备份
- RDB恢复数据比AOF快的多
- 应用:服务器每x小时执行bgsave备份,将RDB文件拷贝到远程服务器,用于灾难恢复。
缺点
- RDB方式无论是执行指令还是利用配置,无法做到实时持久化,较大可能丢数据
- bgsave指令fork创建子进程,消耗性能
- RDB文件在不同版本的redis中不兼容