redis持久化

1. RDB(redis database)

1.1 含义
在指定的时间间隔里,将内存中的数据集快照写入磁盘;在恢复时直接将快照数据读到内存
1.2 实现流程
1、redis 服务端开启一个子线程
2、子进程将数据集写入到一个临时RDB文件中(dump.rdb)
3、子进程完成对一个新的RDB文件写入时,替换调旧的RDB文件
1.3 优点
1、适合做某一时间点的数据备份,将数据还原到不同的版本
2、在恢复大数据量时速度快过AOF
3、最大化redis性能,不影响客户端的请求
1.4 缺点
1、服务器故障时数据丢失,保存数据集是一个耗时操作
1.5 备份方式
1. redis.conf 文件中配置触发条件
save 900 1
save 300 10
save 60 10000
#    n   m
N 秒内数据集至少有 M 个改动,触发一次数据集保存

2、BGSAVE,手动备份
在后台异步保存当前数据到磁盘
127.0.0.1:6379> BGSAVE
Background saving started
# 最近一次 Redis 成功将数据保存到磁盘上的时间
127.0.0.1:6379> LASTSAVE
(integer) 1616657937

2. AOF(append only file)

2.1 含义
以日志的方式记录redis每一次写的操作,已追加的方式写入文件(appendonly.aof),类似于mysql的binlog日志;
再重新启动redis服务时,执行该文件中的命令
2.2 开启方式
redis.conf 配置:
appendonly yes
appendfilename "appendonly.aof"
# appendfsync always  实时同步
appendfsync everysec  每秒同步
# appendfsync no      不同步
2.3 重写机制
目的:
不断的将命令追加到文件末尾,导致文件过大,大量冗余命令可以优化,比如incr key等
只保留可以恢复数据的最小指令集,提升效率,节省磁盘空间

原理:
不操作旧的aof文件,子进程遍历内存中的数据,根据数据内容生成命令重新写一个aof文件

触发重写时机:
redis会记录上一此重写后文件的大小,当AOF文件大小是上一次的一倍并且大于64m时,会触发从写机制
在redis.conf 中配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

手动重写:
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

重写流程:
1、redis 通过fork(),生成一个子进程
2、子进程根据内存数据重新生成命令,写入到一个新的aof文件中,
3、父进程将所有新执行的写的命令,加到内存缓存,将这些改动追加到现有 AOF 文件的末尾
4、当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新 AOF 文件的末尾
5、新文件代替旧文件,后面新的写入命令写到新文件中
2.4 优点
1、较为完整的保存了所有写入命令,保证了数据的完整性
2、AOF文件重写,生成恢复数据的最小指令集
3、aof文件易读,易分析,纯追加操作,不影响原有命令数据
2.5 缺点
1、大量写入操作时,持久化策略影响性能
2、AOF文件占用空间较大
3、AOF文件损坏(事务执行中,服务挂了)
2.6 AOF文件修复
[root@iZuf6fy2kg5mx828krkhcuZ src]# redis-check-aof --fix /qqc_data/redis-2.8.17/appendonly.aof 
AOF analyzed: size=3865, ok_up_to=3865, diff=0
AOF is valid

3. 如何选择

两种方式都开启,根据实际场景选择使用
可以承受分钟内部分数据丢失,需要更快恢复,用RDB;
保证恢复数据的完整性,应AOF;

参考:http://redisdoc.com/topic/persistence.html

原文地址:https://www.cnblogs.com/quqinchao/p/14592495.html