目录：
1、什么是RDB
2、触发机制-主要三种方式
3、触发机制-不容忽略方式
4、试验
1、什么是RDB
Redis是在内存中的，RDB存储在硬盘中。RDB持久化就是redis通过一条命令将redis内存中的数据完整的生成一个快照保存到硬盘中，就是一个RDB文件（二进制保存）。当我们需要恢复Redis，可以加载这个RDB文件将某时某刻的一个RDB备份文件恢复到Redis中
2、触发机制-主要三种方式（save、bgsave、自动）
-
save（同步）
save是一条同步的命令，就是说在它执行这个命令之前其他的所有命令都需要去排队等到它执行之后再执行其它命令
save命令
文件策略及复杂度 -
bgsave（异步）
bgsave 异步命令，表示执行完该命令之后会立刻返回OK，然后在后头单独开启一个线程去执行
bgsave过程
-
save和bgsave的区别
| 命令 | save | bgsave |
|---|---|---|
| IO阻塞 | 同步 | 异步 |
| 阻塞？ | 是 | 是（阻塞发生在fork） |
| 复杂度 | O(n) | O(n) |
| 优点 | 不会消耗额外内存 | 不阻塞客户端命令 |
| 缺点 | 阻塞客户端命令 | 需要fork，消耗内存 |
-
自动生成RDB
其实这样的自动生成并不好，因为我们无法控制生成RDB文件的频率或者说它生成RDB文件的频率太高了。另外内存中的数据写一个快照到硬盘中，如果这个文件非常大的话或者说很频繁去做这个操作的话，肯定会对硬盘有一定的压力而且生成的一个规则也不太好控制，因为写入量我们无法控制，所以说这种其实不是一种很好的方式。
3、触发机制-不容忽略方式
1、全量复制
主从要进行复制的时候，主会自动生成RDB文件
2、debug reload
debug重启，不会将内存清空的重启，会触发RDB文件的生产
3、shutdown
4、试验
1、save命令是否真正的阻塞
2、bgsave fork的过程
3、自动配置的save是否真的有效
4、RDB长啥样
实际操作
1、找到配置文件，修改配置文件。因为redis一般都会做集群，所以pidfile，logfile，dbfilename 最好加上再多加上机器名或者别的作为区别区分。 我这边是在本地测试，所以以端口做区分。
daemonize yes
pidfile /var/run/redis-6379.pid
logfile “6379.log”
dbfilename dump-6379.rdb
dir /Users/apple/data/redis/redis/data
#注释掉
#save 900 1
#save 300 10
#save 60 1000
2、
往redis批量新增600w条数据进行测试，加入这么都数据是因为测试save的阻塞效果，在执行save命令时，其他命令会在其后面阻塞，直至save命令执行完，后面的命令才能进行执行
3、执行save命令，然后再执行别的命令时，会停顿，直至save命令结束才会返回结果，这里不好演示就不展示了
这时候rdb文件会生成到之前配置的dir的目录下
4、bgsave命令操作
这里看出来fork出来了一个线程执行bgsave
日志中也可查看bgsave命令的执行情况
5、配置save 条件 自动执行save 命令进行rdb文件生成
因为随便满足一个就会触发，所以我们这里演示开启的表示 60s 发生5次change，就会自动的rdb文件生成。
我们在60秒内触发5次change，则会自动生成rdb文件
5、RDB总结
- RDB是Redis内存到硬盘的快照，用于持久化
- save通常会阻塞Redis
- bgsave不会阻塞Redis，但会fork新进程
- save自动配置满足任一就会被执行
- 有些触发机制不容忽视
