1.RDB 介绍：
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
2.RdbRDB 其他配置文件
| 配置 | 描述 |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| dbfilename dump.rdb | rdb持久化文件名称 |
| stop-writes-on-bgsave-error no | 在后台发生错误时，是否要停止写操作，默认配置成 no |
| rdbcompression yes | 对rdb文件进行压缩 |
| rdbchecksum yes | 是否开启RDB文件的校验，在写入文件和读取文件时都起作用；关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现 |
3 RDB之被动持久化
3.1 相关配置如下：
save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
3.2 被动持久化演示
操作流程：
- 当 300秒内，进行了10次修改
- 在指定的时间内即300秒内，查看是否生成了dump.rdb
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> set k6 v6
OK
127.0.0.1:6379> set k7 v7
OK
127.0.0.1:6379> set k8 v8
OK
127.0.0.1:6379> set k9 v9
OK
127.0.0.1:6379> set k10 v10
OK
127.0.0.1:6379>
查看redis目录，发现已经生成dump.rdb 文件
案例总结 ： redis 的rdb 策略在开启时，当有满足其任意一个条件时，都会触发被动持久化，生成dump.rdb 文件**
4.主动持久化
当我们使用flushall，flushDB，save ，和bgsave时都会触发主动持久化
4.1 flush 之持久化
注意：当前持久化在重新登录后，没有任何数据**
4.2 save持久化
save 持久化将造成redis 数据阻塞，是一个同步持久化方案，即当我们在执行save操作时，在save未执行完毕时，无法执行其他操作，准备工作如下：
- 首先关闭redis 的被动持久化方案
- 往redis 中存放500W 条数据
- 通过save 触发主动持久化方案，通过get指令去获得数据，看是否产生阻塞
现象如下：
127.0.0.1:6379> DBSIZE
(integer) 5001191
127.0.0.1:6379> save
OK
(6.40s)
127.0.0.1:6379>
在6.4s 过程中无法执行其他任何操作，同时在执行完毕后，生成dump.rdb文件
**案例总结：save操作会造成阻塞**
##### 4.3 bgsave 持久化
- 准备工作同save持久化
- 案例思路如save持久化
现象如下:在整个持久化过程中，不影响我们进行任何操作!
[root@localhost bin]# ./redis-server redis.conf
[root@localhost bin]# ./redis-cli -p 6379
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379>
```
结论：bgsave是异步的，不会造成阻塞（在fork子进程阶段会产生阻塞），在持久化结束后，会生成dump.rdb文件**
5.bgsave持久化原理：
底层会fork 出一条子进程，这条子进程来进行持久化操作，而主进程进行相应其他操作，在子进程进行持久过程中，会生成temp.rdb，当子进程持久化结束后，会用temp.rdb 去替换 dump.rdb
5.1 演示fork
fork 子进程的生成：通过linux 指令 ps -ef | grep redis- 查看fork 子进程，我们先来查看save操作的是否有fork 进程
[root@localhost bin]# ps -ef | grep redis
root 6772 1 14 Aug30 ? 00:05:00 ./redis-server *:6379
root 6896 6421 0 00:04 pts/0 00:00:00 ./redis-cli -p 6379
root 6905 6772 70 00:05 ? 00:00:00 redis-rdb-bgsave *:6379
root 6907 6455 0 00:05 pts/1 00:00:00 grep redis
[root@localhost bin]# ^C
[root@localhost bin]# ps -ef | grep redis
root 6772 1 14 Aug30 ? 00:05:00 ./redis-server *:6379
root 6896 6421 0 00:04 pts/0 00:00:00 ./redis-cli -p 6379
root 6909 6455 0 00:05 pts/1 00:00:00 grep redis
[root@localhost bin]#
我们发现在进行bgsave的同时，产生了fork出来的子进程,并且当初始化完毕后，bgsave的子进程就消失了
5.2 替换临时文件temp
```java
-rwxr-xr-x. 1 root root 4171863 8月 12 18:09 redis-benchmark
-rwxr-xr-x. 1 root root 16419 8月 12 18:09 redis-check-aof
-rwxr-xr-x. 1 root root 37651 8月 12 18:09 redis-check-dump
-rwxr-xr-x. 1 root root 4261097 8月 12 18:09 redis-cli
-rw-r--r--. 1 root root 41407 8月 31 00:00 redis.conf
lrwxrwxrwx. 1 root root 12 8月 12 18:09 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 5702017 8月 12 18:09 redis-server
-rw-r--r--. 1 root root 19791872 8月 31 00:06 temp-6916.rdb 生成临时文件
[root@localhost bin]# ll
总用量 67512
-rw-r--r--. 1 root root 54881755 8月 31 00:06 dump.rdb
-rwxr-xr-x. 1 root root 4171863 8月 12 18:09 redis-benchmark
-rwxr-xr-x. 1 root root 16419 8月 12 18:09 redis-check-aof
-rwxr-xr-x. 1 root root 37651 8月 12 18:09 redis-check-dump
-rwxr-xr-x. 1 root root 4261097 8月 12 18:09 redis-cli
-rw-r--r--. 1 root root 41407 8月 31 00:00 redis.conf
lrwxrwxrwx. 1 root root 12 8月 12 18:09 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 5702017 8月 12 18:09 redis-server 临时文件消失并生成了dump.rdb
[root@localhost bin]#
```
案例总结：验证bgsave持久化原理成功**
6.总结：
RDB：被动持久化方案，采用的是bgsave方案，适合大规模数据恢复，但可能会损失一个时间段的数据（因为此时并未触发持久化就宕机了）
