• Redis持久化方式:RDB和AOF详解,对比


    前言

    上篇我们整理了Redis工作中常用命令大全,今天跟着老哥来学习一下Redis持久化的机制,这也是面试中经常会问道的知识点。Redis操作是基于内存的,但是它同时又是一个数据库,那么庞大的数据量不可能全部存在内存中。就需要Redis定时将内存中的数据持久化硬盘上。下面我们就讲讲Redis的两种持久化方式

    Redis持久化两种方式

    RDB持久化

    RDB是什么

    RDB持久化的机制是在一段时间内达到某修改次数,就把内存数据快照Snapshot持久化到硬盘上,比如:配置1分钟内修改100次,达到这个条件时,就会进行持久化操作。RDB文件格式是dump.rdb

    如何配置

    即:在redis.conf文件里配置,截图上的save <seconds> <changes>

    如:save 1 100(一分钟内修改100次)

    如何停止:在redis.conf文件里配置save "",或者通过命令config set save ""

    触发RDB几种方式

    • 自动触发

    就是上面说的redis.conf里的save配置

    • 手动触发

    执行save命令:save时只管保存,其它不管,全部阻塞

    执行bgsave命令:Redis会在后台异步进行快照操作,

    快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间

    执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义

    持久化原理-fork

    Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。

    整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感。

    那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

    Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等),数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。

    将持久化文件重新加载到内存中

    Redis是基于内存的,所以要将硬盘上的数据重新加载到内存中提供服务。

    • 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可,redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间,会一直处于阻塞状态,直到载入工作完成为止。

    • 获取 redis 的安装目录可以使用 config get dir 命令

    RDB优势与劣势

    优势

    • 适合大规模的数据恢复

    • 对数据完整性和一致性要求不高

    劣势

    • 在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。

    • Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性能需要考虑

    RDB总结

    AOF持久化

    AOF是什么

    Aof保存的是appendonly.aof文件,是将Redis所有的写命令(增删改)记录到这个日志文件中,读命令不记录。

    只允许在文件末尾追加内容,不允许改写文件。

    Redis启动的时候就会读取该文件,简而言之,就是将文件中的命令重新执行一遍,完成数据恢复到内存的工作。

    如何配置

    即:在redis.conf文件里配置,截图上的改成appendonly yes

    持久化策略

    通过Appendfsync配置

    • Appendfsync Always

    每次发生数据变更会被立即记录到磁盘,性能较差数据完整性比较好

    • Appendfsync Everysec

    出厂默认推荐,异步操作,每秒记录,如果一秒宕机,有数据丢失

    AOF启动/恢复/修复

    同样我们需要将AOF文件加载内存中之后才能使用,如果AOF文件被破坏了,我们该如何修复呢?

    • 正常恢复到内存中

    将有数据的aof文件复制一份保存到对应目录,目录路径可以通过config get dir命令获取,重新启动Redis就可以了

    • 异常恢复文件到内存中

    备份异常AOF文件,使用命令对文件进行修复:redis-check-aof --fix 文件名,然后重新启动Redis就可以了

    Rewrite重写AOF文件

    什么是Rewrite

    AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制。

    当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof进行重写文件

    Rewrite原理

    AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)。

    遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件。

    而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似

    触发重写机制

    Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍,且文件大于64M时触发

    AOF优势/劣势

    优势

    • 每次修改同步:appendfsync always同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好

    • 每秒同步:appendfsync everysec异步操作,每秒记录,如果一秒内宕机,仅一秒内的数据丢失

    劣势

    • 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb

    • Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

    AOF总结

    IT 老哥

    一个在大厂做高级Java开发的程序猿

  • 相关阅读:
    ubuntu c++ 关机 重启 挂起 API
    Java 并发 —— Java 标准库对并发的支持及 java.util.concurrent 包
    机器学习: Logistic Regression--python
    机器学习:朴素贝叶斯--python
    理解YOLOv2训练过程中输出参数含义
    darknet YOLO 编译使用GPU
    机器学习:决策树--python
    Xmodem通信协议实例
    MQTT协议笔记之连接和心跳
    Android实现推送方式解决方案
  • 原文地址:https://www.cnblogs.com/itlaoge/p/14219633.html
Copyright © 2020-2023  润新知