Redis持久化

Redis持久化

Rdb快照（snapshot）

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

在规定时间内，执行了多少次操作，则会持久化到.rdb文件

相关配置

#如果900秒内，至少一个key进行了修改，那么就进行持久化操作
save 900 1  
#如果300秒内，至少有10个key进行了修改，那么就进行持久化操作
save 300 10   
#如果60秒内，至少有10000个key进行了修改，那么就进行持久化操作
save 60 10000  

#持久化如果出错，是否还需要继续工作
stop-writes-on-bgsave-error yes  

#是否压缩.rdb文件（会消耗一定的cpu资源）
rdbcompression yes  

#保存.rdb文件的时候，进行错误检查校验
rdbchecksum yes  

#.rdb文件保存路径
dir ./     

手动执行

redis还可以手动执行命令生成RDB快照，save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里并，并覆盖原有的rdb快照文件。

save与bgsave命令

• save：同步IO执行，会阻塞redis的其他命令。
  * 优点：不会额外消耗内存
  * 缺点：阻塞redis其他命令

• bgsave：异步IO执行，不会阻塞redis的其他命令(在生成子进程执行调用fork函数时，会有短暂阻塞)
  * 优点：不阻塞redis其他命令
  * 缺点：需要fork子进程，消耗内存

配置自动生成rdb文件后台使用的是bgsave的方式

bgsave的写时复制(COW)机制：
Redis借助操作系统提供的写时复制技术(Copy-On-Write)，在生成快照的同时，依然可以正常处理写命令。简单的说bgsave子进程是由主进程Fork出来的，共享主进程的所以内存数据。
bgsave子进程运行后，开始读取主进程的内存数据，并把他们写入rdb文件。此时，如果主进程对这些数据也是读操作，那么，主进程和bgsave子进程相互不影响。但是，如果主进程修改一部分数据，那么，这块数据就会被复制一份，生成数据副本。然后bgsave子进程会把这个副本数据写入rdb文件，而在这个过程中，主进程仍然可以直接修改原来的数据。

AOF（append-only file）

快照功能可能会造成数据的丢失：如果Redis宕机，那么服务器就会丢失写入缓存，但未保存至快照的部分数据。

所以，从1.1版本开始，redis增加了AOF持久化方式，将修改的每一条指令记录进appendonly.aof文件中。（先写入os cache，每隔一段时间fsync到磁盘）。

RDB和AOF

• rdb：启动优先级低，体积小，恢复速度快。但容易丢数据。
• aof：启动优先级高，体积较大，恢复速度较慢。但可以根据策略决定数据安全性。

redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof 一般来说数据更全一点。

AOF相关配置

# aof模式默认不开启,默认是使用rdb方式持久化的
# 在大部分情况下,rdb完全够用
appendonly no   

#.aof文件名
appendfilename "appendonly.aof"  

//每次修改都会执行同步，消耗性能
# appendfsync always  
//每秒执行一次同步，但是可能会丢失这1s的数据
//推荐（并且也是默认）的措施为每秒 fsync 一次。
//这种 fsync 策略可以兼顾速度和安全性。
appendfsync everysec  
//不执行同步，这个时候操作系统自己同步数据，速度最快
# appendfsync no      

####重写规则####
# 开启AOF重写   默认关闭
no-appendfsync-on-rewrite no

# aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100
#如果aof文件大于64mb，fork一个新的进程来讲我们的文件进行重写。
auto-aof-rewrite-min-size 64mb  

####混合持久化（必须先开启AOF）####
# 是否开启混合持久化
# aof‐use‐rdb‐preamble yes

appendonly.aof（未重写）

例如执行指令：set k1 v1
aof文件内容如下：

*3
$3 
set 
$5 
k1 
$3 
v1

这是一种resp协议，*3代表有三个参数，$3代表参数有3个字符

注意：如果执行带过期时间的命令，aof里记录key过期的时间戳
如：set k2 v2 ex 1000

*3 
$3 
set 
$6 
k2
$3 
v2
*3 
$9 
PEXPIREAT 
$6 
k2
$13 
1604249786301

AOF重写

aof中可能存在很多没用的指令，比如大量的incr自增指令，所以AOF会定期根据内存的最新数据重写生成aof文件。

例如执行

127.0.0.1:6379> incr readcount 
(integer) 1
127.0.0.1:6379> incr readcount 
(integer) 2 
127.0.0.1:6379> incr readcount 
(integer) 3 
127.0.0.1:6379> incr readcount 
(integer) 4 
127.0.0.1:6379> incr readcount 
(integer) 5

重写后的AOF文件：

*3 
$3 
SET 
$2 
readcount 
$1 
5

AOF也可以手动重写，bgrewriteaof，主进程会fork出一个子进程做（和bgsave类似）。

混合持久化(Redis 4.0)

前提：1、必须开启AOF 2、开启混合持久化配置（aof‐use‐rdb‐preamble）

重启redis后，很少使用RDB文件恢复数据，因为可能会丢失数据。通常使用AOF文件来恢复数据，但是这样效率要慢很多。所以Redis4.0推出了混合持久化。

开启了混合初始化后：AOF在重写的时候，不再是单纯将resp协议的指令存入AOF文件，而是将重写前的内存做RDB快照处理，并将RDB快照内容和增量 AOF修改的内存数据的指令存在一起，写入新的AOF文件。

新的文件一开始不叫appendonly.aof，等重写完成后，新的文件改名并覆盖原先的appendonly.aof文件。

混合持久化AOF文件结构：

在Redis重启时，先加载RDB格式内容，然后再增量重放AOF格式内容，如此提升效率。

Redis数据备份策略

1、利用crontab定时调度脚本，每小时copy一份rdb或aof备份，保留48小时内备份文件。

2、每天保留一份当日的数据备份到另一个目录，可以保留近一个月的备份。

3、每次copy备份文件时，将太旧的备份文件删除。

4、每天晚上复制一份备份文件到另一台机器上，防止机器损坏。