Redis的持久化

rdb简介
rdb配置
rdb的优缺点

aof简介
配置
AOF的重写机制
AOF 的优缺点
aof文件实例

rdb和aof共存

rdb

rdb简介

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
Redis 在写 rdb时，会fork一个子进程来进行

rdb配置


#  下面这四个配置，以下事件会触发rdb保存:
#  900秒内有一个key发生改变
#  300秒内有10个key发生改变
# 60秒内有10000个key发生改变
# 10秒内有一个key发生改变(测试用)
save 900 1
save 300 10
save 60 10000
save 10 1

stop-writes-on-bgsave-error yes

#rdb文件是否压缩
rdbcompression yes

#是否进行CRC64校验
rdbchecksum yes

#rdb文件名
dbfilename dump.rdb

#rdb工作目录，生产环境最好改一下
dir ./

rdb的优缺点

优点：

适合大规模的数据恢复。
如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：

数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

aof

aof简介

为了规避rdb的不足，Redis推出了全新的持久化机制：aof。
原理也很简单：只要我记录每一步的写操作，就一定能推导出这个库
aof默认是关闭的

配置

#开关
appendonly yes

#aof文件名
appendfilename "appendonly.aof"

#aof保存策略
#no:由操作系统决定何时flush
#always: 每一个update操作都等待日志写完后再返回
#everysec: 每秒钟同步一次操作日志
appendfsync everysec

#没有延迟问题就保持为no
no-appendfsync-on-rewrite no

#当AOF文件大小是上次rewrite后大小的100%且文件大于64M时触发(64M还是太小了，我们生产环境一般是4G)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

#重写配置
aof-load-truncated yes
aof-use-rdb-preamble yes

若appendonly.aof 文件格式异常，可以通过命令redis-check-aof --fix appendonly.aof 进行修复

AOF的重写机制

AOF的工作原理是将update日志追加到文件中，文件的冗余内容会越来越多。所以Redis 增加了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（重写时aof文件太大了，都去内存中的数据比较快）。最后替换旧的aof文件。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

AOF 的优缺点

优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

aof文件实例

*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v1
*3
$3
set
$2
k2
$2
v2

rdb和aof共存

如果rdb和aof都存在，且不一致会怎么样？
经验证，当

appendonly yes

若同时还存在dump.rdb文件，dump.rdb文件会被忽略。将appendonly.aof文件删除，仅保留dump.rdb时，仍然不能正确地恢复rdb中的数据，此时，修改配置项appendonly no，再启动Redis，即可看到dump.rdb中的数据被恢复到redis中了

来源：CSDN

作者：fyq2016

链接：https://blog.csdn.net/fyq2016/article/details/103651233

标签

Redis

数据持久化

redis的持久化