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方案，适合大规模数据恢复，但可能会损失一个时间段的数据（因为此时并未触发持久化就宕机了）

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方案，适合大规模数据恢复，但可能会损失一个时间段的数据（因为此时并未触发持久化就宕机了）