• Redis从入门到精通(四:持久化)


    持久化简介

    什么是持久化
    利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化
    持久化用于防止数据的意外丢失,确保数据安全性
    为什么持久化

    redis是将数据存储在内存上的,一旦断电,或者因为机器故障使redis服务宕机,那么存储的内容就会消失

    持久化过程保存什么
    RDB:将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据
    AOF:将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程

    RDB

    1.save指令进行手动RDB过程
    2.bgsave指令进行手动RDB过程
    3.save配置进行自动RDB过程
    4.RDB优缺点

    1.save指令进行手动RDB过程

    save

    save指令相关配置:
    设置本地数据库文件名,默认值为 dump.rdb,通常设置为 dump- 端口号 .rdb
    dbfilename filename
    设置存储.rdb文件的路径,通常设置成存储空间较大的目录中,目录名称 data
    dir path
    设置存储至本地数据库时是否压缩数据,默认yes,设置为no,节省 CPU 运行时间,但存储文件变大
    rdbcompression yes|no
    设置读写文件过程是否进行RDB格式校验,默认yes,设置为no,节约读写10%时间消耗,单存在数据损坏的风险
    rdbchecksum yes|no
    2.bgsave指令进行手动RDB过程
    手动启动后台保存操作,但不是立即执行
    bgsave
    bgsave指令相关配置:
    后台存储过程中如果出现错误现象,是否停止保存操作,默认yes
    stop-writes-on-bgsave-error yes|no
    其他:
    dbfilename filename
    dir path
    rdbcompression yes|no
    rdbchecksum yes|no
    3.save配置进行自动RDB
    设置自动持久化的条件,满足限定时间范围内key的变化数量达到指定数量即进行持久化
    save second changes
    参数
    second:监控时间范围
    changes:监控key的变化量
    范例
    save 900 1
    save 300 10
    save 60 10000
    其他
    dbfilename filename
    dir path
    rdbcompression yes|no
    rdbchecksum yes|no
    stop-writes-on-bgsave-error yes|no
    4.RDB优缺点
    RDB优点
    RDB是一个紧凑压缩的二进制文件,存储效率较高
    RDB内部存储的是redis在某个 时间点 的数据快照,非常适合用于数据备份,全量复制等场景
    RDB恢复数据的速度要比AOF快很多
    应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复。
    RDB缺点
    RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
    bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一些性能
    Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象

    AOF

    1.AOF概念
    2.AOF执行策略
    3.AOF重写
    4.AOF的工作流程以及重写的工作流程
    1.AOF概念
    AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为 由记录数据改为记录数据产生的变化
    AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式
    启动AOF相关配置:
    开启AOF持久化功能,默认no,即不开启状态
    appendonly yes | no
    AOF持久化文件名,默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof
    appendfilename filename
    AOF持久化文件保存路径,与RDB持久化文件保持一致即可
    dir
    AOF写数据策略,默认为everysec
    appendfsync always | everysec | no
    2.AOF执行策略
    always(每次):每次写入操作均同步到AOF文件中
    数据零误差 性能较低 ,不建议使用。
    everysec(每秒):每秒将缓冲区中的指令同步到AOF文件中,在系统突然宕机的情况下丢失1秒内的数据
    数据 准确性较高 性能较高 ,建议使用,也是默认配置
    no(系统控制):由操作系统控制每次同步到AOF文件的周期
    整体过程 不可控
    3.AOF重写
    AOF重写
    随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。
    AOF重写作用
    降低磁盘占用量,提高磁盘利用率
    提高持久化效率,降低持久化写时间,提高IO性能
    降低数据恢复用时,提高数据恢复效率 AOF
    AOF重写规则
    1.进程内具有时效性的数据,并且数据已超时将不再写入文件
    2.非写入类的无效指令将被忽略,只保留最终数据的写入命令
     如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
     如select指令虽然不更改数据,但是更改了数据的存储位置,此类命令同样需要记录
    3.对同一数据的多条写命令合并为一条命令
    如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为:lpush list1 a b c。
    为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素
    AOF重写方式:
    手动重写
    bgrewriteaof
    自动重写
    auto-aof-rewrite-min-size size
    auto-aof-rewrite-percentage percentage
    4.AOF的工作流程以及重写的工作流程

    RDB与AOF区别

  • 相关阅读:
    线程 相关
    MyCat-web安装文档:安装Zookeeper、安装Mycat-web
    【论文阅读 09】融合门控自注意力机制的生成对抗网络视频异常检测
    VUE前端实现“模糊搜索“(纯前端)
    面试官:你说你用过Dubbo,那你说说看Dubbo的SPI
    吴恩达2022机器学习专项课程C2W2:实验SoftMax
    【MySQL功法】第5话 · SQL单表查询
    Myvatis关联关系映射与表对象之间的关系
    关于vue中关于eslint报错的问题
    mybatis批量插入
  • 原文地址:https://blog.csdn.net/weixin_44680802/article/details/132858999