7.Redis的持久化RDB 、AOF

Redis的持久化

Redis是基于内存的，必须要考虑的一个问题就是：当redis服务挂了之后，之前的数据怎么重新加载到内存？那么必须要考虑一种存放历史数据的解决方案。

RDB：指定的时间间隔对数据进行快照存储。

假如开始拍快照时间为10：00，整个快照落库持久化完成大概需要5分钟，即10：05此次快照拍完。而在10：04的时候b被改成了5，那么在rdb生成的结果里b是存的4还是5呢？是的，用大腿想也能想到肯定是存的4，但是如果让你来着设计这个RDB持久化怎么去实现呢?

A方案:使用一个进程阻塞系统,系统拍照的时候我不准用户改动数据，等我快照拍完了你再改。此路不通。
B方案:使用一个进程且不阻塞系统，继续让用户改数据，并同时将数据持久化落库，那就意味着一有数据改动就得重新拍照，那这个快照拍到什么时候能生成？此路不通。
C方案:派（fork）一个子进程去把10：00当时那个点的数据a先落库（bgsave），主进程继续为用户服务，当用户改了数据b时，触发copyonwrite 将b的原始引用拷贝给子进程，主线程里的b引用新指向内存里的5。

RDBsave参数配置

save 900 1 # 每900s有1个key变化，时候生成RDB
save 300 10 # 每300s有10个key变化，时候生成RDB
save 60 10000 # 每60s有10000个key变化，时候生成RDB

RDB的优点
- 适用于灾难恢复，也可以根据需求恢复到不同版本的数据集.
- 与AOF相比,在恢复大的数据集的时候，RDB方式会更快
- 最大化redis的性能，存RBB主进程只管fork子进程。
RDB的缺点
- 可能会丢失数据
- 虽然fork同步操作非常快，同步大数据量时，fork也会阻塞主进程

Redis AOF(append only file)持久化

1. 开启AOF，AOF 特点

############################## APPEND ONLY MODE ###############################
appendonly yes # 默认为no,redis默认是rdb模式；
# aof 记录的文件名

appendfilename "appendonly.aof"

#每次写入仅追加日志后进行Fsync。缓慢但安全的
# appendfsync always
# Compromise（折中）方案，一秒追加一次。
appendfsync everysec
# 由操作系统调度刷新输出缓冲区写入到aof文件
# appendfsync no

特点：

记录的是数据操作流水，丢失数据少
4.0版本之后支持开启RDB+AOF，默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）

2. AOF 存在的问题：

随着日期增加 AOF 日志变得无限大，回复将会显得日志臃肿，表现为数据恢复耗时久。重写之前已经记录下来的数据指令；

在 4.0 之前: 删除抵消的命令。like:incre key 1 & decre key 1，set key 1 & delete key
4.0 之后：支持开启：aof-use-rdb-preamble 将老的数据先生成 RD 再增量的通过 AOF 添加到日志。

3. appendonly.aof 日志格式

# set key2  testvalue
*3
$3
set
$4
key2
$9
testvalue

# 执行 mset key1 1 key2 2 key33 3
# aof日志如下：
*7 # 本批命令需要往下读7行非 $ 开始的命令
$4 #接着读取4个字节宽度，‘mset’长度为4，记为 $4
mset
$4 #接着读取4个字节宽度，‘key1’长度为4，记为 $4
key1
$1 #接着读取1个字节宽度，‘1’长度为1，记为 $1
1
$4
key2
$1
2
$5 #接着读取的字节宽度，‘$key33’长度为5，记为 $5
key33
$1
3

4. aof 日志什么时候追加？

redis 提供三种追加频率：

no

不要立刻刷，只有在操作系统需要刷的时候再刷，比较快。如果 redis 重启了拿到的数据将不是很新的数
always

每次写操作都立刻写入到 aof 文件。慢，但是最安全
everysec

每秒写一次（默认）