redis的持久化操作

配置持久化

redis的持久化的方式有两种

1. 使用rdb快照的方法进行吃就好

2. 使用aof 日志追加的方式进行持久化

使用rdb快照的方法进行持久化

什么是快照:

快照: 是照内存的 , 直接内存中的数据 进行快照, 数据格式照搬过来, 直接放到磁盘上

可以理解成就是直接创建了一个内存镜像, 直接写入到了硬盘. 下次断点直接把这个镜像 放回到内存中就完成了 恢复了, 恢复的速度比较快

rdb方式的持久化是通过快照完成的，当符合一定条件时redis会自动将内存中的所有数据执行快照操作并存储到硬盘上。默认存储在dump.rdb文件中。(文件名在配置文件中dbfilename)

Redis自动实现快照的过程

redis使用fork函数复制一份当前进程的副本(子进程)

父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件

当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

注意：

redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的.这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份

RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

手动执行save或者bgsave命令让redis执行快照。

两个命令的区别在于，

save是由主进程进行快照操作，会阻塞其它请求。b

bgsave是由redis执行fork函数复制出一个子进程来进行快照操作。

rbd 快照的配置选项:

save 900 1      # 在900秒内,有1条写入,则产生快照
save 300 1000   # 如果300秒内有1000次写入,则产生快照
save 60 10000   # 如果60秒内有10000次写入,则产生快照
# (这3个选项都屏蔽,则rdb禁用)
Rdb 的备份  会fork出一个子进程来完成数据的备份, 创建出一个新的进程去工作, 不会阻碍主进程继续接受命令执行命令
stop-writes-on-bgsave-error yes  # 后台备份进程出错时,主进程停不停止写入?
rdbcompression yes    # 导出的rdb文件是否压缩
Rdbchecksum   yes #  导入rbd恢复时数据时,要不要检验rdb的完整性
dbfilename dump.rdb  #导出来的rdb文件名
dir /usr/data/redis_backup  #rdb的放置路径  注意文件夹路径一定要存在的

使用AOF日志增加的方式进行持久化

采用追加的方式来进行

简单的原理图:



主程序在执行写入的操作, 后台程序执行写入到磁盘的操作, 这样不影响主程序接受客户端发送来的命令

就是把发生的写入命令, 逐条的写入到日志文件中, 保存在磁盘上, 同样有三种频率可以选择, 来进行

默认情况下redis没有开启aof，可以通过参数appendonly参数开启

aof文件的保存位置和rdb文件的位置相同，都是dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改

AOF的配置方式, 主要的几个配置

appendonly  yes# 是否打开 aof日志功能

appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢
appendfsync everysec # 折衷方案,每秒写1次(一般选择这个, 默认的也是这个选项)
appendfsync no      # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
appendfilename "appendonly.aof"   # 默认的aof日志文件的名称

no-appendfsync-on-rewrite  yes: # 正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写

# 为什么要进行重写的操作

重写后可以大大的降低aof 文件的大小, 因为我们在操作redis的时候, 可能是对一个键操作了多次, 但是我们需要的最终结果是最后一次的操作, 前面的就没什么用了, 但是还是保存在redis的日志文件中, 进行重写就是把内存中的数据再次逆化成指令,重写的写入到aof 中 这个时候, 就没有多于的指令了, 可以大大的减少aof文件的大小

两种持久化的区别:

采用rbd快照的形式的情况下, 每次的快照形成的时间, 是固定的, 如果在这次快照已经形成后, 到下一次快照形成前, 这个期间服务器出现了问题, 那么这期间的数据就会丢失了, 就是这段时间的操作

如果使用aof的话可以配置不同的频率的保存形式, 为了减少不必要的操作, 一般采用每秒写入一次, 这样如果服务器出现问题, 那么丢失也就是这一秒的数据, 数据量就少了很多. 具体的采用那种方式, 可以按照自己的业务需求来进行选择

当rdb文件和 aof同事存在的时候, 会优先采用aof 来进行恢复 因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

恢复rdb和aof 的时候, 谁的速度比较快

rbd 比较快, 因为rdb是数据的一个内存快照, 恢复的时候, 直接载入到内存中就可以了, 而aof是命令, 需要进行逐条的写入到内存中, 进行执行.

rdb的缺陷

redis服务端的命令

redis 127.0.0.1:6380> time  ,显示服务器时间 , 时间戳(秒), 微秒数
1) "1375270361"
2) "504511"

redis 127.0.0.1:6380> dbsize  // 当前数据库的key的数量
(integer) 2
redis 127.0.0.1:6380> select 2  # 选择其他的数据库 这里是第3个 默认的是从0开始的
OK
redis 127.0.0.1:6380[2]> dbsize
(integer) 0

BGREWRITEAOF #后台进程重写AOF
BGSAVE       #后台保存rdb快照
SAVE         #保存rdb快照
LASTSAVE     #上次保存时间

Flushall  #清空所有库所有键
Flushdb  #清空当前库所有键
Shotdown [save/nosave]  # 关闭redis服务, 后面的参数是保存还是不保存

注: 如果不小心运行了flushall, 立即 shutdown nosave ,关闭服务器

然后 手工编辑aof文件, 去掉文件中的 “flushall ”相关行, 然后开启服务器,就可以导入回原来数据.

如果,flushall之后,系统恰好bgrewriteaof了,那么aof就清空了,数据丢失