Redis数据持久化策略
持久化策略之RDB
RDB:在指定的时间间隔，执行数据集的时间点快照。
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是读快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就能得到保证。这个快照文件就称为RDB文件（dump.rdb）。其中，RDB就是Redis DataBase的缩写。通俗点说就是在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里
RDB的持久化：6与7的配置是存在一定区别的
Redis 6.X中redis.conf中的配置快照部分，SNAPSHOTTING
Redis6.0.16 之前的配置情况，在Redis.conf配置文件中的SNAPSHOTTING下配置save参数，来触发Redis的RDB持久化条件。比如save m n ：表示m秒内数据集存在n次修改时，自动触发bgsave
Redis 6.2以及7之后变化频率发生了变化
如何利用dump文件进行数据恢复？
自动备份：
将备份文件（dump.rdb）移动到redis安装目录并启动服务即可恢复数据。
备份成功后故意用flushdb清空redis,看看是否可以恢复数据？执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义。
物理恢复，一定服务和备份分机隔离
备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。
手动备份：save与bgsave
redis提供了两个命令来生成RDB文件，分别是save和bgsave(默认)
save
save命令在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用
bgsave(默认)
redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发方式会fork一个子进程，由子进程复制持久化过程
fork是什么？ 从linux角度看，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率的考虑，尽量避免膨胀。
lastsave 可以通过lastsave命令获取最后一次成功执行快照的时间
时间戳转化
RDB的优点
优点总结
适合大规模的数据恢复、按照业务定时备份、对数据完整性和一致性要求不高、RDB文件在内存中的加载速度要比AOF快得多
RDB的缺点
缺点总结
在一定间隔时间做一次备份，所以如果redis意外down掉的化，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
RDB依赖于主进程的fork,在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑。
数据丢失的案例
kill -9 模拟宕机
redis重启恢复数据，查看数据是否丢失
如何检测修复dump.rdb文件
哪些情况会触发RDB快照？？
1.配置文件中默认的快照配置
2.手动save/bgsave命令
3.执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空白的
4.执行shutdown且没有设置开启AOF持久化
5.主从复制时，主节点自动触发
如何禁用快照？？
动态所有停止RDB保存规则的方法：
redis-cli config set save ""
配置文件快照禁用的方式
RDB优化配置项
相关命令
stop-writes-on-bgsave-error
默认yes。 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求
rdbcompression
默认yes 。 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum
rdb-del-sync-files
