Redis持久化（七）

1. RDB

redis默认的持久化方式， RDB是紧凑压缩的二进制文件，代表Redis早某个时间点上的数据快照，非常适合用于备份，主要使用的是全量复制的场景

1.1. 存储流程

1.2. 说明

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中（RDB文件），待持久化完成以后才会将这个临时文件替代上次持久化好的文件。整个过程中主线程都是没有任何IO操作的，这样就确保了极高的性能。

1.3. 触发机制

1. save规则满足时就会触发生成RDB文件并写入磁盘中

save 900 1 # 900秒（15分钟）之后，且至少1次变更
save 300 10 # 300秒（5分钟）之后，且至少10次变更
save 60 10000 # 60秒之后，且至少10000次变更

2. 执行flushall命令时，也会触发我们的RDB文件生成
3. 退出redis时也会产生RDB文件

1.4. RDB基础配置

# 当导出到 .rdb 数据库时是否用LZF压缩字符串对象。
# 默认设置为 "yes"，所以几乎总是生效的。
# 如果你想节省CPU的话你可以把这个设置为 "no"，但是如果你有可压缩的key的话，那数据文件就会更大了。
rdbcompression yes

# 数据库的文件名：默认是dump.db
dbfilename dump.rdb

# 工作目录
# 数据库会写到这个目录下，文件名就是上面的 "dbfilename" 的值。
# 累加文件也放这里。
# 注意你这里指定的必须是目录，不是文件名。
dir ./

1.5. 如何恢复数据

1. 我们可以把磁盘中已经备份好的RDB文件放在Redis服务的启动目录就可以了，Redis启动的时候会自动检查dump.rdb恢复其中的数据。

2. 查看RDB文件存放的位置

   127.0.0.1:6379> config get dir
   1) "dir" # 对应的就是上述的dir 配置
   2） "/usr/local/bin" #如果在这个目录下存在dump.rdb文件，redis服务启动时就会自动恢复其中的数据
   

1.6. 优缺点

优点：

1. 适合大规模数据恢复
2. 对数据完整性要求不高

缺点：

1. 需要一定的时间间隔进程操作！如果redis服务以外宕机，会容易丢失最后一次执行的数据
2. 子进程的fork会占用一定的内存空间

2. AOF

将我们所有的命令都存入一个AOF文件，以日志的形式记录每一个增删改操作命令（读操作不记录）。此文件只允许追加不可以更改（即使用一种增量复制的方式扩展文件），Redis服务启动之初会读取该文件，然后执行AOF文件中记录的所有增删改查操作命令来达到数据恢复的目的 。如果数据操作特别多，数据量特别大，此种方式的性能就会很差，不推荐。

2.1. 存储流程

2.2. AOF配置

# 默认是关闭AOF，如果要开启AOF备份就设置为yes
appendonly no 

# 纯累加文件名字（默认："appendonly.aof"）
appendfilename appendonly.aof

# 同步规则 
# always代表一直同步
# everysec代表每秒同步一次；默认采用的
# no代表从不同步
appendfsync always
appendfsync everysec
appendfsync no

2.3. 恢复数据

Redis提供了一个工具专门用来进行AOF文件恢复数据redis-check-aof

redis-check-aof --fix appendonly.aof

2.4. 优点和缺点

优点：每一次修改都同步，文件的完整性很好

缺点：

1. 相对于数据文件来说，AOF远远大于RDB，AOF修复的速度是远远比RDB慢，因为其本质还是执行命令日志
2. AOF执行命令需要消耗大量热IO，效率低，数据恢复的速度远远不如RDB。