redis开启rdb和aof redis rdb fork

转载

半夜未央好 2023-08-11 16:49:19

文章标签 redis开启rdb和aof redis 学习 java 数据 文章分类 Redis 数据库

redis学习五redis的持久化RDB，fork，copyonwrite,AOF,RDB&AOF混合使用

回顾
RDB

RDB时点性
RDB配置方式
RDB的优缺点

AOF(Append Only File)
实际演示

回顾

redis作为缓存：数据可以丢【追求的是急速】
redis作为数据库：数据绝对不能丢的
通常所说的redis+mysql -》是将redis作为数据库来用的，但是这样的话就需要保证redis
和mysql数据一致性的问题。【一般会加个消息队列来写】
从而引出redis自己的持久化操作。

RDB

RDB时点性

RDB相当于生成一个快照或者副本。

并且具有时点性的特性：

要说明时点性的问题的话redis数据从内存中持久化到磁盘中分为如下几种

情况：

1、redis阻塞去读取内存的数据到磁盘中，读取到磁盘数据的时间不对外提供

服务。

如果从八点持续读取到八点半，磁盘里面的数据是归属于八点的。

redis开启rdb和aof redis rdb fork_java

在实际生产中，如果采用上述方式导致服务不可用是个非常不好的方式：

所以引出如下方式：

redis开启rdb和aof redis rdb fork_数据_02

本来要写b=4，还没写，然后修改b=6了，就把b=6写入到磁盘里面去了，在写入b=6的时候a右变成8了，然而这个时候a不会再写了，这个文件的时点就混乱了，磁盘里面有八点这个时间点的数据也有八点半这个时间点的数据

所以引入如下形式：

在说这个形式之前，引入一个管道的概念：

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_03

((num++)) | echo ok 执行此命令会在管道的左边创建一个子进程以及管道的右边创建一个子进程

redis开启rdb和aof redis rdb fork_数据_04

$$的优先级高于 | 管道

从而引出使用linux的时候是有一个父子进程的概念的：

父进程的数据，子进程可不可以看到？

redis开启rdb和aof redis rdb fork_数据_05

此时起了一个子进程，发现子进程是看不了父进程的数据的【常规思想是进程间的数据是隔离的】

redis开启rdb和aof redis rdb fork_数据_06

此时再退回为父进程【是能够取到num的】

redis开启rdb和aof redis rdb fork_redis_07

再用export 关键字修饰一下num【发现子进程也能访问父进程的数据了】

redis开启rdb和aof redis rdb fork_数据_08

子进程修改是否影响父进程，然后看父进程修改是否影响子进程，写出如下脚本

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_09

redis开启rdb和aof redis rdb fork_java_10

然后执行脚本：并让他在后台执行

redis开启rdb和aof redis rdb fork_redis_11

回到父进程发现父进程还是1，子进程的修改不会影响到父进程。父进程的修改也不会影响子进程：

redis开启rdb和aof redis rdb fork_学习_12

从而子进程是有父进程的一个副本，且修改互相不影响，如果父进程是redis，那么它的内存数据如果

有10个G，那么当他需要持久化数据的时候，那么就创建一个子进程，将数据导入到子进程里面去，

但是这样速度会慢并且内存空间也需要考虑【需要空余的空间多余10G】

所以linux有个系统调用fork()，这个的优点是速度相对比较快，且占用空间相对较少，这个fork如何实现

的呢？

计算机会有一个固定内存空间物理地址，想象成一个数组，redis会有一个虚拟地址空间，从而做一个虚拟地址

到物理地址的一个映射,假设redis有个a的key，对应的虚拟地址是3，指向了物理地址的8位置，redis

想取a的时候能把8对应的x取出来，如果redis想创建一个子进程【它也有一个虚拟地址】，通过fork

创建进程可以让两个进程同时指向一个物理空间，

redis开启rdb和aof redis rdb fork_数据_13

（copy on write）创建子进程的时候并不发生复制，只有父子进程任意一方想修改数据的时候才

定向的去复制数据,这样创建进程的速度变快了，同时子进程不可能把所有

数据都改一遍。

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_14

输入man 2 fork，可以看到关于fork的描述信息：

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_15

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_16

下面就来说redis中RDB的真正做法了：

redis通过fork的方式创建一个子进程，且数据没有真的拷贝出来，只是加了相应的指针指向，当父进程有某些

值改变了以后，会触发内核级别的一个写时复制，则在内存中对应物理地址中，让父进程中的那个key指向新

的地址，而子进程的那个key还是指向原来的那个物理地址

redis开启rdb和aof redis rdb fork_学习_17

RDB配置方式

save方式：前台阻塞的方式去持久化【需要明确情况：比如，关机维护】

bgsave方式：后台异步非阻塞的方式去持久化（fork创建子进程）【要求不影响对外提供服务的时候】

配置文件中给出bgsave的规则：save这个标识、

进入redis的配置文件，可以看到如下配置信息：

第一个参数是时间，第二个参数是操作数，一般是操作数随时间增加而减少

redis开启rdb和aof redis rdb fork_java_18

# save 3600 1
# save 300 100 //如果60s操作数没有到10000次，那么会等到300s的时候判断操作数是否有100次
# save 60 10000 //表示60s，操作数有10000次的时候执行bgsave持久化
save "" 这样写的话rdb功能会关闭

rbdchecksum是rdb的校验位,然后下面一个是配置的持久化到磁盘的文件名

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_19

redis开启rdb和aof redis rdb fork_数据_20

RDB的优缺点

缺点：
1、不支持拉链，只有一个dump.rdb【需要运维去做维护】
2、丢失数据相对多一些，不是实时记录数据的变化，8点得到一个RDB文件，9点的时候刚要
做持久化的时候服务器挂机了
优点：
1、类似java中的序列化，恢复的速度相对快一些

AOF(Append Only File)

只会向文件里面追加，文件里面追加的是redis的写操作。
优势：
1、丢失数据少
2、RDB和AOF可以同时开启，如果开启了AOF，只会用AOF恢复【
在redis的4.0版本以后，AOF中包含了RDB的一个全量，并且增加增量记录新的
写操作】
弊端：
1、就是序列化慢
2、假设redis运行了10年，开启了AOF，首先这个AOF会非常大，其次恢复这个
数据也很慢，但是恢复不会造成内存溢出。【AOF的体量会无限变大，恢复慢】

如何设计出一个方案来让AOF足够小呢？

1、hdfs，fsimage+edits.log，让日志只记录增量，合并的过程

2、redis的4.0以前，重写，删除可以抵消的命令，合并重复的命令，最终是一个

纯指令的日志文件。

3、redis的4.0以后，将老的数据通过RDB的方式写到AOF文件中（二进制的字节），

将增量的以指令的方式Append到AOF，AOF是一个混合体，利用了RDB的快，也利用了日志

的全量【例如8点开始执行持久化，将8点前的数据RDB到硬盘文件中，其间增量的数据

通过AOF追加在文件中】

redis开启rdb和aof redis rdb fork_数据_21

再回到redis作为内存数据库来使用，增删改写操作会触发IO行为，redis写IO会有

三种级别可以调整 appendsync always/no/everysec

redis开启rdb和aof redis rdb fork_redis_22

redis开启rdb和aof redis rdb fork_redis_23

appendsync no :内核的buffer什么时候满了，再向磁盘里面刷数据，可能会丢一个buffer大

小的数据：这里就是把数据放在操作系统的buffer中，并没有落盘，如果数据刚好放满一个buffer，操作系统刚要把数据刷到磁盘，机器挂了，那么这一个buffer的数据也就丢失了

appendsync always:发生写的时候立马调用操作系统的内核去把操作系统中的buffer里的数据写入
到磁盘里面去，相对来说数据最可靠
appendsync everysec:每秒级别，每一秒调一次flush，可能会接近丢一个buffer的数据，这个
概率会比较小

redis开启rdb和aof redis rdb fork_数据_24

redis抛出一个子进程，子进程在做RDB，那么父进程不会再去调刷新磁盘争抢

IO的操作。

当AOF 的appendfsync配置为 everysec 或 always ，并且后台运行着RDB的save或者AOF重写时，（由于save和rewrite会）消耗大量的磁盘性能。在某些Linux配置下，aof同步到磁盘执行 fsync() 将被阻塞很长时间。
注意：这个问题目前还没有解决办法。因为即使在不同的线程中执行fsync，也会阻塞同步 write() 调用。
为了减轻这个问题，可以使用 no-appendfsync-on-rewrite 选项防止执行BGSAVE或BGREWRITEAOF时，在主进程中调用fsync()。
这意味着当有另一个子进程执行BGSAVE或BGREWRITEAOF 时，磁盘同步策略相当于 appendfsync no。在最坏的情况下(使用默认的Linux设置)可能会丢失最多30秒的日志。
如果你有延迟问题可以将该项设置为“yes”。否则，从数据完整性的角度看，使用“no”更安全。

redis开启rdb和aof redis rdb fork_redis开启rdb和aof_25