Redis:两种持久化方式RDB和Aof对比(3)
一、RDB快照
1、概念
默认的持久化方案。
在指定时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。
在指定目录下生成一个dump.rdb文件。
重启会通过加载dump.rdp文件恢复数据。
2、对应配置参数
save <seconds> <changes>
eg:
save 900 1
save 300 10
save 60 10000
若不想用RDB方案，则为save ""
# 时间策略save 900 1
save 300 10
save 60 10000
# 文件名称
dbfilename dump.rdb
# 文件保存路径
dir /home/work/app/redis/data/
# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes
# 是否压缩
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
3、手动触发rdb快照
save 会阻塞
bgsave 不会阻塞，重fork新子进程保存
4、优缺点
1）优点：适合大规模数据恢复，如果对数据完整性和一致性要求不高，RDB是很好的选择
2）缺点：完整性和一致性不高
二、Aof日志追加
1、概念
默认不开启。
出现是为了弥补RDB的不足。
2、对应配置参数
appendonly yes （默认为no）
appendfilename "appendonly.aof"
# appendfsync always appendfsync everysec # appendfsync no
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 配置重写触发机制
# 是否开启aofappendonly yes
# 文件名称appendfilename "appendonly.aof"
# 同步方式appendfsync everysec
# aof重写期间是否同步no-appendfsync-on-rewrite no
# 重写触发配置auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理aof-load-truncated yes
# 文件重写策略aof-rewrite-incremental-fsync yes
3、手动触发
bgrewriteaof 瘦身机制 ，重新整理aof命令日志
4、优缺点
优点：数据完整性和一致性更高
缺点：aof记录的内容对，文件会越来越大，数据恢复也会越来越慢
三、两者同时使用
两种可同时使用
当数据恢复时，优先加载aof文件恢复
