赞
踩
### Redis 持久化之RDB
#### 1.RDB 介绍:
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
#### 2.RdbRDB 其他配置文件
| 配置 | 描述 |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| dbfilename dump.rdb | rdb持久化文件名称 |
| stop-writes-on-bgsave-error yes | 在后台发生错误时,是否要停止写操作,默认配置成 yes |
| 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
```java
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 之持久化
![1](.\img\主动持久化之flush操作.png)
**注意:当前持久化在重新登录后,没有任何数据**
##### 4.2 save持久化
save 持久化将造成redis 数据阻塞,是一个同步持久化方案,即当我们在执行save操作时,在save未执行完毕时,无法执行其他操作,准备工作如下:
- 首先关闭redis 的被动持久化方案
- 往redis 中存放500W 条数据
- 通过save 触发主动持久化方案,通过get指令去获得数据,看是否产生阻塞
现象如下:
```java
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持久化
现象如下:在整个持久化过程中,不影响我们进行任何操作!
```java
[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
![1](.\img\bgsave阻塞修改.png)
##### 5.1 演示fork
fork 子进程的生成:通过linux 指令 ps -ef | grep redis- 查看fork 子进程,我们先来查看save操作的是否有fork 进程
```java
[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方案,适合大规模数据恢复,但可能会损失一个时间段的数据(因为此时并未触发持久化就宕机了)
更多python学习资料可关注:gzitcast
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。