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