zoukankan      html  css  js  c++  java
  • 你了解Redis的持久化吗?

    Redis 持久化

    前言

    Rdis的读写都是在内存中进行,所以redis的性能很高。
    持久化可以有效地避免因进程退出而造成数据丢失问题,下次重启的时候利用之前持久化文件可以实现数据恢复。

     

    持久化的几种方式

    Redis 持久化拥有以下三种方式:

    • 快照方式(RDB, Redis DataBase)
    RDB持久化是把当前进程数据生成快照保存到硬盘的过程,触发RDB持久化过程分为手动触发和自动触发
    • 文件追加方式(AOF, Append Only File)
    记录所有的操作命令,并以文本的形式追加到文件中;
    • 混合持久化方式,
    Redis 4.0 之后新增的方式,混合持久化是结合了 RDB 和 AOF 的优点,在写入的时候,先把当前的数据以 RDB 的形式写入文件的开头,再将后续的操作命令以 AOF 的格式存入文件,这样既能保证 Redis 重启时的速度,又能减低数据丢失的风险。

    以上三种持久化方案,每一种都有特定的使用场景,具体的我们可以根据自己的需求自行选择。

    RDB持久化

    RDB(Redis DataBase)是将某一个时刻的内存快照(Snapshot),以二进制的方式写入磁盘的过程

    RDB的持久化方式有两种:

    一种是手动触发,一种是自动触发

    手动触发

    手动触发Redis提供了两个命令 :savebgsave

    • save 命令

    save 手动触发会阻塞主线程

    在客户端执行save命令时候,就会触发持久化,但也会使得Redis主线程阻塞,必须等到RDB持久化完成之后,才会相应客户端的命令,线上环境不建议使用

    下图演示使用save命令

    启动Redis (默认配置是rdb持久化方式),rdb文件时间。

    在这里插入图片描述

    然后使用save持久化数据

    在这里插入图片描述
    然后查看持久化后rdb文件的时间
    在这里插入图片描述
    说明手动持久化文件成功

    • bgsave 命令

    bgsave不会阻塞主线程

    使用bgsave命令时候,Redis进程执行fork操作创建子进程,RDB持久化过程由子 进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短,基本不会发生阻塞,与save命令相比显然bgsave更适合我们持久化数据。

    下图表示开始自动持久化数据
    在这里插入图片描述

    自动触发

    如何自动触发 RDB 持久化?

    在redis.conf文件中有这么一个配置

    在这里插入图片描述

    什么意思呢?

    • save m n

    save m n 表示m秒内数据集存在n次修改 时,自动触发bgsave命令。

    save 900 1 则表明在 900 秒内,至少有一个键发生改变,就会触发 RDB 持久化。
    save 300 10 则表明在 300 秒内,至少有10个键发生改变,就会触发 RDB 持久化。
    save 60 10000 则表明在 60 秒内,至少有10000个键发生改变,就会触发 RDB 持久化。

    满足以上任意一个条件,Redis 就会自动触发bgsvae命令进行持久化工作。

    • flushall

    注意:flushall 是把内存中的数据清空,持久化会把原先已经持久化的 .rdb 文件清空。

    • 主从同步触发

    Redis主从复制时,当从节点执行全量复制操作时,主节点会执行 bgsave 命令,并将 RDB 文件发送给从节点,该过程会自动触发 Redis 持久化。

    RDB配置说明

    # RDB 保存的条件
    save 900 1
    save 300 10
    save 60 10000
    
    # bgsave 失败之后,是否停止持久化数据到磁盘,yes 表示停止持久化,no 表示忽略错误继续写文件。
    stop-writes-on-bgsave-error yes
    
    # RDB 文件压缩 
    # Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话,可以设置为关闭此功能,# 这样的缺点是需要更多的磁盘空间来保存文件。
    rdbcompression yes
    
    # 写入文件和读取文件时是否开启 RDB 文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动。
    rdbchecksum yes
    
    # RDB 文件名
    dbfilename dump.rdb
    
    # RDB 文件目录
    dir ./
    
    RDB 优缺点

    优点

    • RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据 快照。非常适用于备份,全量复制等场景。
    • 与 AOF 格式的文件相比,RDB 文件可以更快的重启。
    • RDB 对灾难恢复非常有用,它是一个紧凑的文件,可以更快的传输到远程服务器进行 Redis 服务恢复

    缺点

    • RDB方式数据没办法做到实时持久化/秒级持久化,RDB只能保存某个时间间隔的数据,如果在这个期间Redis故障了,就会丢失一段时间的数据。
    • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运 行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
    禁用持久化
     save ""

    AOF持久化

    AOF(append only file)持久化:以独立日志的方式记录每次写命令, 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用 是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式

    AOF的工作流程操作

    命令写入 (append)、文件同步(sync)、文件重写(rewrite)、重启加载 (load)。
    配置AOF

    默认是 no表示关闭 ,yes表示开启。

    在这里插入图片描述

    • 自动触发

    持久化配置
    在这里插入图片描述

    • always:每条 Redis 操作命令都会写入磁盘,最多丢失一条数据,但会使得Redis的性能降低,但数据几乎是全的,基本不会存在丢失数据问题。
    • everysec:每秒钟写入一次磁盘,最多丢失一秒的数据,对存取数据和性能折中,可以满足大部分使用场景。
    • no:不设置写入磁盘的规则,根据当前操作系统来决定何时写入磁盘,一般不采用这种设置。
    • 手动触发

    使用bgrewriteaof命令可以手动触发aof持久化

    在这里插入图片描述

    在这里插入图片描述

    随着时间的推移和数据量变大,aof一直在进行持久化,磁盘日志越来越大,redis重启速度越来越慢,针对这个问题,Redis提供了AOF重写功能。

    Redis中的数据是有一定限量的,最多不超过物理内存大小,不可能说Redis中的数据无限增长,导致aof也无限增长,到一定的时候Redis就会采用缓存淘汰算法LRU自动将以部分数据从内存中给清除。

    AOF 重写配置
    在这里插入图片描述

    • auto-aof-rewrite-min-size:允许 AOF 重写的最小文件容量,默认是 64m 。
    • auto-aof-rewrite-percentage:AOF 文件重写的大小比例,默认值是 100,表示 100%,也就是只有当前 AOF 文件,比最后一次(上次)的 AOF 文件大一倍时,才会启动 AOF 文件重写。

    AOF 重写流程

    AOF 是存放每条写命令的,所以会不断变大,达到一定的时候,AOF做rewrite操作,会重新生成一个新的AOF文件。

    优缺点

    AOF 优点

    AOF 持久化保存的数据更加完整,AOF 提供了三种保存策略:每次操作保存、每秒钟保存一次、跟随系统的持久化策略保存,其中每秒保存一次,从数据的安全性和性能两方面考虑是一个折中的选择,也是 AOF 默认的策略,即使发生了意外情况,最多只会丢失 1s 钟的数据;

    AOF 采用的是命令追加的写入方式,所以不会出现文件损坏的问题,即使由于某些意外原因,导致了最后操作的持久化数据写入了一半,也可以通过 redis-check-aof 工具轻松的修复;

    AOF 持久化文件,非常容易理解和解析,它是把所有 Redis 键值操作命令,以文件的方式存入了磁盘。即使不小心使用 flushall 命令删除了所有键值信息,只要使用 AOF 文件,删除最后的 flushall 命令,重启 Redis 即可恢复之前误删的数据。

    AOF 缺点

    对于相同的数据集来说,AOF 文件要大于 RDB 文件;

    在 Redis 负载比较高的情况下,RDB 比 AOF 性能更好;

    RDB 使用快照的形式来持久化整个 Redis 数据,而 AOF 只是将每次执行的命令追加到 AOF 文件中,因此从理论上说,RDB 比 AOF 更健壮。

    混合持久化

    RDB和AOF持久化各有优缺点,RDB会导致一段时间内的数据丢失,AOF文件会越来越大,会影响Redis的启动速度,为了同时兼顾RDB,AOF的优点,Redis在4.0版本之后提供了混合持久化方式。

    混合持久化

    AOF 重写时会把 Redis 的持久化数据,以 RDB 的格式写入到 AOF 文件的开头,之后的数据再以 AOF 的格式化追加的文件的末尾,如下图所示。

    在这里插入图片描述

    开启混合

    no改为yes即可
    在这里插入图片描述

    混合持久化优缺点

    优点

    混合持久化结合了 RDB 和 AOF 持久化的优点,开头为 RDB 的格式,使得 Redis 可以更快的启动,同时结合 AOF 的优点,有减低了大量数据丢失的风险。

    缺点:

    AOF 文件中添加了 RDB 格式的内容,会使得 AOF 文件的可读性会很差,不容易阅读;
    如果开启混合持久化,就必须使用 Redis 4.0 以及之后版本

    使用混合持久化的时候可以根据自身业务选择关闭RDB或者AOF,或者关闭持久化。

  • 相关阅读:
    vue简单的富文本实现(亲测可以)
    做手机兼容性看友盟手机统计
    压测并发数上不去的原因分析(泽嵩大佬说的)
    跨域问题解决
    jmeter压力测试报Address already in use: connect错误
    选择器(可搜索)+气泡提示组件
    2020
    Redis集群搭建采坑总结
    echarts自定义背景图片
    百度ECharts地图Json数据在线下载(geoJson)
  • 原文地址:https://www.cnblogs.com/weifeng1463/p/14523970.html
Copyright © 2011-2022 走看看