redis的持久化操作

配置持久化

redis的持久化的方式有两种
1. 使用rdb快照的方法进行吃就好
2. 使用aof 日志追加的方式进行持久化

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

什么是快照:

快照: 是照内存的 , 直接内存中的数据 进行快照, 数据格式照搬过来, 直接放到磁盘上
可以理解成就是直接创建了一个内存镜像, 直接写入到了硬盘. 下次断点直接把这个镜像 放回到内存中就完成了 恢复了, 恢复的速度比较快

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

Redis自动实现快照的过程

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

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

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

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

两个命令的区别在于，

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

2. 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文件的大小

两种持久化的区别:

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

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

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

4. 恢复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就清空了,数据丢失