RDB
redis默认持久化方式为RDB，即快照持久化
在redis.conf中，有触发备份的规则
save 900 1 在900秒内，如果有一次redis操作，就进行备份
save 300 10 在300秒内，如果有10次redis操作，就进行备份
save 60 10000 在60秒内，如果有10000次redis操作，就进行备份
#save "" 如果想禁用rdb,取消注释即可
stop-writes-on-bgsave-error yes 如果备份进程出错，主进程停止写入操作，保持数据一致性
rdbcompression yes 开启压缩配置rdb文件，建议关闭，因为压缩也会消耗cpu的性能，cpu比硬盘更值钱
备份会生成一个dump.rdb文件，此文件是二进制文件
创建RDB文件
save很少使用，因为save指令会在redis的主线程中进行备份，redis是用一个主线程来处理请求的，会阻塞client的请求
通过lastsave来获取上次save的时间
可以通过java计时器，调用bgsave指令，来生成备份文件，并添加时间戳存储，作为某个时间的全量数据脚本move dump.rdb dumo时间戳.rdb
自动触发RDB持久化
- 根据redis.conf配置的save m n 定时触发（用的是BGSAVE）
- 主从复制时，主节点自动触发
- 执行Debug Reload
- 执行shutdown且没有开启AOF持久化
BGSAVE原理
执行BGSAVE指令后，首先检查当前主进程有没有正在执行的RDB或AOF子进程，如果有，则返回错误，没有，则开始持久化，调用rdbSave
Background,调用linux的fork指令，创建进程，实现了Copy-On-Write。
传统方式的fork，会将主进程的所有资源复制给子进程，这种方式实现简单，但是效率低下，而且复制的资源可能对子进程毫无用处。
linux为了降低创建子进程的成本，当父进程创建子进程时，内核只为子进程创建虚拟空间，父子两个进程使用相同的物理空间，只有父进程发生更改时，才为子进程创建独立的物理空间
RDB持久化的缺点
AOF
开启aof需要在reids.conf中将appendonly 设置为yes。
appendfsync everysec 设置aof文件写入方式，还能接收always 和no 作为参数
always是，一旦缓存内容发生方便，就将缓存的内容写入到aof中
everysec是每隔一秒将缓存的文件写入到aof文件中
no是将写入aof文件的操作交给系统来决定，一般操作系统会在缓存区被填满再执行备份操作
推荐使用everysec方式，速度快，安全性也不错
aof持久化是一个追加操作，就会出现aof文件不断增大的问题。
如果将一个计数器递增100次，只需要保留结果为100即可，但是aof会保存100次操作记录，但是redis有解决方案，在不中断服务的情况下，在后台重建aof文件，即通过日志重写来解决
日志重写原理
RDB和AOF文件共存情况下的数据恢复
先检查aof文件是否存在，如果存在就加载aof忽略rdb，如果不存在就尝试加载rdb文件
RDB和AOF的优缺点
RDB和AOF混合持久化
redis4.0后，使用混合持久化作为默认的备份方式
来源：CSDN
作者：gclhaha
链接：https://blog.csdn.net/weixin_43797872/article/details/104146622