一 . 持久化概述
redis的持久化功能是决定redis可以作为一定功能数据库的核心.
所谓的持久化就是将内存数据可以转存到磁盘之上,然后再特定时刻可以将磁盘文件的信息转存到内存之中.
在redis之中总共有两种方式进行持久化,一种是RDB,一种是AOF的方式.
[注意]
我们使用redis并不一定要使用持久化,只是在需要持久的时候才去用,
持久化就意味着性能的代价,但是带来的是高可用的回报.
二 .持久化的方式
在redis之中的两种持久化的方式,RDB,AOF.
其本质上讲:RDB是按照内存快照的方式进行,AOF是按照日志的方式进行.
三 .RDB的基本原理
当我们开启RDB的使用时,redis会按照一定的策略进行快照.
本质上讲非常简单,就是创建一个快照文件,当完成时就去替换之前存在的文件.
RDB的触发方式:
手工触发: 可以使用save()或者bgsave()命令进行触发
被动触发: 当我们的redis使用复制功能的时候,底层默认的实现方式就是RDB快照文件的复制.
四 .save和bgsave命令
[1]save命令是一个同步命令,会发生线程阻塞,因此我们一般不会去使用.
在线程阻塞时,以为着redis不会向其他客户端服务,本质上是由于redis的单进程模型决定
[2]bgsave命令:
客户端向redis发起bgsave命令之后,redis会fork一个子进程完成RDB持久化工作.
此时会直接向客户端返回一个成功响应.
bgsave是一个异步的非阻塞的命令,一般情况下我们会去使用这个命令来完成.
[注意]持久化会花费一定的时间,此时客户端可能对数据进行修改,这个时候我们持久的数据可能造成
不同步的情况,这个问题我们后面需要进行解决.
五 . RDB的配置
我们首先打开redis的配置文件,找到快照部分的配置.下面我们来说一下主要的配置内容:
[1] RDB策略
该配置的含义是代表900秒内有一次操作,或者300秒内10此操作,60秒内10000条操作,
此时会触发RDB的持久化.
[注意]我们一般不会使用这写持久化策略,因为太死板了.
我们一般会做一个定时任务,按照自己的业务逻辑决定是否持久化,使用的持久化的命令就是bgsave.
因此,该处的save策略我们一般都会去掉.
[2]当使用bgsave命令错误时,是否停止写操作
这个配置我们一般都会配置未yes.
[3]RDB文件是否采用压缩
这个我们一般都会采用压缩的算法
[4]RDB的校验模式
我们一般也会开启这个校验的模式
[5]RDB持久化的文件的名字
[6]指定持久化文件的存放路径
