专栏首页琦小虾的BinaryRedis技术知识总结之六——Redis持久化机制

Redis技术知识总结之六——Redis持久化机制

接上篇《Redis技术知识总结之五——Redis集群模式》

六. Redis 持久化机制

参考地址:《Redis持久化机制》

Redis 有两种持久化机制:快照 (RDB)AOF 日志。其中快照是一次性全量备份,AOF 是增量备份。

6.1 快照 (RDB)

Redis 使用操作系统的多进程 COW (Copy On Write) 机制实现快照持久化。在持久化时,由于要一边要持久化,一边又要满足 Redis 的正常使用,所以 Redis 在持久化的时候,使用了 glibc 的 fork 函数产生了一个子进程,在子进程中进行快照持久化操作,主进程满足业务的正常使用。

RDB的原理是fork和cow。fork是指redis通过创建子进程来进行RDB操作,cow指的是copy on write,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。

快照持久化的内存策略是:子进程按照数据页进行复制。在持久化过程中,子进程负责持久化过程,它将主进程数据段的数据页复制一份出来,然后对原数据页进行存储;同一时间,主进程对那份复制出来的数据进行操作。通过复制小数据量数据页(通常每个数据页只有 4KB)的方式,保证了主进程修改数据不会影响子进程存储,子进程存储的数据,还是子进程产生一瞬间的数据。

快照触发方式有自动触发与手动触发两种。

  • 自动触发:通过 redis.conf 配置文件进行配置;
  • 手动触发
    • save: 阻塞式触发,在未完成前,客户端无法进行命令操作;
    • bgsave: 非阻塞式触发,主进程 fork 出子进程进行备份操作;

在恢复文件时,将备份文件 (dump.rdb) 放在 Redis 安装目录,然后启动 Redis,就能把 RDB 中的文件加载到 Redis 服务中。

快照存储的优点缺点:

  • 优点
    • 数据结构紧凑,保存了 Redis 服务在某个时间点上的数据集,非常适合做备份和灾难恢复;
    • 进行 RDB 快照持久化时,主进程会 fork 出一个子进程进行备份工作,主进程不需要额外的 IO 操作;
    • RDB 恢复大数据集时,速度比 AOF 快;
  • 缺点
    • 版本兼容问题:Redis 版本更新过程中有多个 RDB 版本,存在老版 RDB 兼容性无法兼容新版的问题;
    • 无法做到实时持久化,因为 bgsave 时的 fork 操作每次都会创建子进程,内存中的数据被克隆了一份,属于重量级操作。

6.2 AOF

AOF 日志存储的是 Redis 服务器的顺序指令序列,它只记录对内存进行修改的指令记录。AOF 使用追加记录的方式,在 Redis 长期运行的过程中,AOF 日志会越来越长,所以一旦宕机重启载入 AOF 日志,将会是一个非常耗时的功能,因此我们需要对 AOF 进行瘦身,即 AOF 重写。 AOF 重写并不是对原始的 AOF 文件进行重新整理,而是 fork 一个子进程遍历服务器的键值对,转换成一系列 Redis 的操作指令,序列化到一个新的 AOF 日志文件中。序列化完毕后,将原来的文件替换为序列化后的文件即可。 AOF 重写分为两个过程,一个是 fork 子进程重写过程执行的原始数据内容,另一个是在 fork 过程中主进程修改的指令

6.3 混合持久化

Redis 4.0 之后加入了新的持久化选项:混合持久化。它将 RDB 和 AOF 内容放在一起,其中 AOF 日志记录的不是全量日志,而是持久化开始到持久化结束时间内的 AOF 日志(通常该部分日志很小)。

6.4 AOF 的持久化策略

问:如果突然机器掉电会怎样?

AOF 的持久化策略:AOF 日志是以文件形式存在的,里面记录的是内存的操作记录,它的实现是将操作系统内核为文件描述符分配的内存缓存,通过异步的方式刷新到数据磁盘中。这种操作是 glibc 的 fsync 操作,它是一个很慢的操作,与 Redis 的高性能是相反的。 AOF 提供了三种持久化策略:

  • no: 无 fsync,由系统保证数据刷新到磁盘,速度最快,但很不安全(通常不使用);
  • always: 每次 fsync,每一个修改内存的 Redis 指令都会执行一次 fsync,速度很慢(通常不使用);
  • everysec: 每秒进行一次 fsync,有可能丢失一秒的 fsync 的数据。通常选择 everysec 策略,兼顾安全性和效率。

持久化取决于 AOF 日志 sync 属性的配置,如果不要求性能,在每条写指令时都sync一下磁盘,就不会丢失数据。但是在高性能的要求下每次都sync是不现实的,一般都使用定时sync,比如1s1次,这个时候最多就会丢失1s的数据。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Queue 相关数据结构的原理与实现 (LinkedList, ArrayDeque, PriorityQueue)

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.n...

    剑影啸清寒
  • 图像纹理特征总体简述

    图像纹理特征总体简述 纹理是一种反映图像中同质现象的视觉特征,它体现了物体表面的具有缓慢变化或者周期性变化的表面结构组织排列属性。纹理具有三大标志: 某种局部序...

    剑影啸清寒
  • Java 注解 —— 注解的理解、注解的使用与自定义注解

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.n...

    剑影啸清寒
  • 【数据库】Redis进阶篇

    为了保证多条命令组合的原子性,Redis提供了简单的事务功能以及集成Lua脚本来解决这个问题。简单介绍Redis中事务的使用方法以及它的局限性。

    用户3467126
  • Redis 用的很溜,了解过它用的什么协议吗?

    他说,事情是这样的,刚开始,问了一些基础的问题,比如 Redis 的几种基本数据类型和使用场景,以及主从复制和集群的一些问题,这些都还好。

    古时的风筝
  • redis的持久化存储AOF的原理

    上篇文章我们将了RDB的原理,这节来看看AOF。 AOF字面的意思是,append only file仅追加文件。 AOF 是以协议文本的方式,将所有对数据...

    居士
  • Intellij IDEA神器居然还有这些小技巧?你知道吗??

    Intellij IDEA真是越用越觉得它强大,它总是在我们写代码的时候,不时给我们来个小惊喜。出于对Intellij IDEA的喜爱,我决定写一个与其相关的专...

    乱敲代码
  • [入门]为什么要建设“泛在电力物联网”

    如果没有五颜六色的海水,也许永远不会有人知道沿海城市海边景色有多美。如果没有美国队长,也许人们对克里斯·埃文斯的认知只停留在《神奇四侠》中的“霹雳火”。

    木禾wen
  • [入门]为什么要建设“泛在电力物联网”

    如果没有五颜六色的海水,也许永远不会有人知道沿海城市海边景色有多美。如果没有美国队长,也许人们对克里斯·埃文斯的认知只停留在《神奇四侠》中的“霹雳火”。

    木禾wen
  • IDEA快捷键拆解系列(前言)

      在学校那会,前两年入门写代码用的IDE都是Eclipse,后来也不知道从哪里看到了IDEA,就这样开始慢慢入坑了。博主不是来吐槽的,但博主现在确实对Ecli...

    happyJared

扫码关注云+社区

领取腾讯云代金券