Redis持久化

Redis提供了2个不同形式的持久化方式

备份是如何执行的

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失

RDB (Redis DataBase)

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，他恢复时是将快照文件直接读到内存里

Redis的默认持久化规则

如何触发RDB快照

127.0.0.1:6379> save  #只管保存其他不管，全部阻塞
127.0.0.1:6379> bgsave  #会在后台异步进行快照操作，同时还能相应客户端请求
127.0.0.1:6379> flushall  #也会产生dump.rdb文件，但里面是空的，无意义

RDB配置文件

#配置备份失败的时候是否禁止写操作
stop-writes-on-bgsave-error yes   
#对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，redis会采用LZF算法进行压缩。
rdbcompression yes 
#在快照存储的后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加10%性能消耗
rdbchecksum yes
#停用RDB保存规则 
save ""
#快照文件名
dbfilename dump.rdb

如何使用快照恢复数据

将备份文件移动到redis安装目录重启服务即可

CONFIG GET dir获取目录

优势

适合大规模的数据恢复 对数据完整性和一致性的要求不高

劣势

在一定间隔时间做一次备份，如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性

AOF (Append Of File)

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构造数据

配置文件

# 是否开启AOF 
appendonly no
# 日志文件名
appendfilename "appendonly.aof"
# everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失   
# Always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差，但数据完整性比较好
# No 不同步
appendfsync everysec
#当AOF文件的大小是上次Rewrite后大小的一倍且文件大小大于64MB时触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF和RDB可以共存吗

可以共存，先加载AOF

修复AOF文件

Redis-check-aof --fix

Rewrite

AOF采用文件追加的方式，文件会越来越大 为了避免这个情况，新增了重写机制，当AOF文件大小达到指定阈值的时候，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

劣势

相同数据集的数据而言aof文件要远大于rdb文件，速度慢于rdb

aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

Redis持久化

原文：https://www.cnblogs.com/licha233/p/12847086.html