2020-08-22---redis详细篇---2种持久化和混合过程详细

Redis持久化过程详解

这篇文章, 主要了解 2种持久化方式的 具体操作过程, 会屏蔽掉其他的东西

全局过程

1. 客户端向 redis实例中, 发出了一个写操作
2. redis得到这个写操作, 把数据存储内存中
3. 调用 系统API 将数据写入磁盘
4. 操作系统 将 缓冲区的数据 交给 磁盘控制器
5. 磁盘控制器 把数据 写入实际的物理媒介

RDB

• 它是 redis 默认开启的一种持久化方式
• 目标是 : redis 当前存储的所有数据, 它是一种快照
• 当满足一定条件之后, 会自动进行的一种方式 (bgsave)
• 当然也可以使用 save 或者 bgsave 进行手动触发 RDB 的方式
• 执行FLUSHALL命令；
• 执行复制（replication）时。
• 它是一种二进制的数据流, 因此恢复起来特别的快

流程

save 和 bgsave 的区别 : save 是一种阻塞进行持久化的方式, bgsave则是异步的

这边就描述一下 bgsave 的方式

1. 因为某原因触发了RBD的流程(自动触发, 手动bgsave)
2. Redis父进程首先判断：当前是否在执行这个过程的子进程，如果在执行则bgsave命令直接返回。主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
3. FORK子进程：RDB写入时，会连内存一起Fork出一个新进程（子进程默认会与父进程共享相同的地址空间），遍历新进程内存中的数据写文件，这样就解决了些Snapshot过程中又有新的写入请求进来的问题。这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令 。父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令
4. 子进程创建RDB文件：RDB会先写到临时文件，完了再Rename成，这样外部程序对RDB文件的备份和传输过程是安全的。而且即使写新快照的过程中Server被强制关掉了，旧的RDB文件还在。
5. 可配置是否进行压缩，压缩方法是字符串的LZF算法，以及将string形式的数字变回int形式存储

AOF

• 使用 appendonly yes 来配置 aof的使用
• 这个东西 和 mysql 的binlog 有点类似, 使用的是一种增量 的 (这里要注意 , mysql的binlog , 是有命令过来就会先存储, 后执行 , 在 aof中 , 则是 先执行 , 后存储)
• 有两种关键的策略 , always 每次记录进来都添加，everysecond 每秒添加一次。
• 每一次增量都很少, 因此存储的很快 , 主要开销 在于 fsync , 强行刷新缓冲区的开销

流程

1. 命令的传播, 当redis 执行完一个写命令, 或者删除命令的时候, 会把这条指令 发送给 AOF的程序
2. AOF的程序会把命令写进 一个 AOF的缓冲区
3. 当触发了 存储的条件的时候 , AOF 会把缓冲区中的内容追加到 aof文件之后 . (fsync , 强行刷新缓冲区)
   • 在触发这个动作的时候, 会去判断是否已经开始了 , 或者 是不是正在快照, 如果是快照的话, 需要等待快照完成之后再进行

rewrite

当aof文件越来越大的时候, 我们就需要使用 rewrite 进行重写

• 自动触发 : 达到aof文件大小的阈值 (auto-aof-rewrite-percentage 大于基准值的多少百分比(基准值是上一次的rewrite执行完), auto-aof-rewrite-min-size)
• 手动触发 : bgrewriteaof
• 对aof文件进行瘦身, 主要是 (比如前面记录是增加了一个key a , 后面记录是删除了这个key . 那么这个记录是冗余的)

流程

1. 成功的触发了rewrite 请求
2. 判断当前情况下, 是否有bgsave , 或者 aof正在进行, 进行的话 就会稍等
3. 主进程fork出一个子进程 , 对 aof文件进行重写
4. 在这个过程中, 主进程 依然会去记录 日志的变化, 存储咋一个缓冲区中
5. fork的子进程完成之后 , 会发送一个信号给主进程, 告知完成
6. 主进程会把 在这个过程中新的日志变化 追加到文件后面, 完成rewrite整个过程

Redis数据持久化之RDB-AOF混合方式

• 在 Redis 4.0 之后, 可以使用 混合方式进行存储
• 这种方式 让 redis 恢复起来更快速
• 通过 aof-use-rdb-preamble 参数控制, yes 是开启 , no 是不开启(默认)

不同点

和上述的过程差不多, 唯一不同的就是 rewrite 流程 , rdb的文件(不会在.rdb的文件中, 内容转移到了 aof 中)

流程

1. 当 rewrite 触发之后
2. 主进程 fork 出子进程, 对 aof 文件进行重写 , 会先做出一个临时的文件
3. 对这个文件进行 rdb 的方式 , 以及 fork时刻时的 日志
4. 完成之后 会 告知 主进程, 对增量的日志就进行追加 日志之后
5. 完成之后, 修改名称 覆盖 原来的aof 文件. 完成 过程

恢复的流程 : 还是和之前一样

恢复的流程

1. redis 是否 开启了 aof ?
   • 开启了 , 寻找 aof 文件, 如果能找到, 进行恢复
   • 找不到 aof 文件, 或者没有开启aof , 进入第二步
2. 使用rdb进行恢复

因为 aof 文件, 现在前半段 其实 是 rdb 的内容…因此前面数据恢复起来十分迅速, 之后 加入少量的 增量日志 ,进行恢复到最精确的时刻 即可.

最后

大概描述完全了! .就是这样

最后

以上就是幸福小蝴蝶为你收集整理的2020-08-22---redis详细篇---2种持久化和混合过程详细的全部内容，希望文章能够帮你解决2020-08-22---redis详细篇---2种持久化和混合过程详细所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。