开发者

redis的两种持久化方式RDB和AOF解读

开发者 https://www.devze.com 2025-04-02 10:47 出处:网络 作者: L丶小先生
目录Redis两种持久化方式RDB和AOFRDB持久化1、开启/禁用方式2、触发机制3、参数配置4、数据安全性AOF持久化1、开启/禁用方式2、触发机制3、参数配置4编程客栈、数据安全性5、补充总结redis两种持久化方式RDB和AOF
目录
  • Redis两种持久化方式RDB和AOF
    • RDB持久化
      • 1、开启/禁用方式
      • 2、触发机制
      • 3、参数配置
      • 4、数据安全性
    • AOF持久化
      • 1、开启/禁用方式
      • 2、触发机制
      • 3、参数配置
      • 4编程客栈、数据安全性
      • 5、补充
  • 总结

    redis两种持久化方式RDB和AOF

    Redis 提供了两种主要的持久化方式:RDB(Redis Database)和 AOF(Append Only File)。

    默认情况下,Redis 没有开启任何持久化方式,但可以在配置文件(redis.conf)中启用它们。

    RDB持久化

    RDB 是一种快照持久化方式,它会在指定的时间间隔内生成内存数据的快照并保存到磁盘上的一个 RDB 文件中,RDB 快照(Snapshot)机制在每次触发快照保存时,都会生成一个新的 RDB 文件,这个新文件会覆盖之前保存的 RDB 文件。

    以下是 RDB 快照机制的一些关键点:

    1、开启/禁用方式

    在配置文件的SNAPSHOTTING(快照)模块中设置save参数即可开启,相应的禁用RDB持久化只需要不设置save指令或给save传入一个空字符串即可禁用。

    2、触发机制

    • 达到配置文件中save指令指定的触发条件
    • 通过SAVEBGSAVE(异步执行) 命令触发

    3、参数配置

    #900秒内有一个key发生变化触发快照操作
    save 900 1
    #300秒内有10个key发生变化触发快照操作
    save 30www.devze.com0 10
    # 60秒内有10000个key发生变化触发快照操作
    save 60 10000
    
    # 如果配置成no,表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致,那么在快照写入失败时,也能确保redis继续接受新的写请求
    stop-writes-on-bgsave-error yes
    
    #rdb快照是否进行压缩,但是会消耗cpu
    rdbcompression yes
    
    # 在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能
    rdbchecksum yes
    
    # rdb快照文件名
    dbfilename dump.rdb
    
    #存储位置,默认是当前路径
    dir ./

    4、数据安全性

    • 由于 RDB 文件会覆盖旧文件,因此在故障恢复时,你只能恢复到最后一次成功快照的时间点的数据状态。
    • 为了提高数据安全性,通常建议结合使用 AOF(Append Only File)持久化,这样即使 RDB 文件丢失,AOF 也可以提供更细粒度的数据恢复。

    AOF持久化

    AOF 是一种日志持久化方式,它会记录每次写操作并追加到 AOF 文件中,Redis的AOF文件在重写(rewrite)过程中会被覆盖。

    AOF重写的目的是为了减少AOF文件的大小,并去除那些冗余的、不再必要的命令,使得该文件只包含恢复当前数据集所需的最小命令集。

    在重写工作完成后,Redis会将新的AOF文件覆盖现有的AOF文件,这就相当于压缩了AOF文件,vtPpK使得AOF文件体积变小了。

    以下是 AOF日志机制的一些关键点:

    1、开启/禁用方式

    在配置文件的APPEND ONLY MODE模块中把appendonly参数设置为yes即可开启,设置为no即禁用。

    2、触发机制

    每次写操作都会追加到 AOF 文件中。

    3、参数配置

    #开启aof持久化策略,将接收到的每次写操作请求都追加到aof文件中,在redis重启时,会加载aof文件,优先级比rdb高
    appendonly no
    
    # aof文件名
    appendfilename "appendonly.aof"
    
    # 设置aof持久化频率
    # 有三种选择
    # always 每次写都强制调用fsync,这种模式下,redis会相对较慢,但数据最安全
    # everysec编程客栈 每秒启用一次fsync
    # no 不调用fsync()。而是让操作系统自行决定sync的时间。这种模式下,redis的性能会最快
    appendfsync everysec
    
    # 设置当redis在rewrite的时候,是否允许appendsync。因为redis进程在进行AOF重写的时候,fsync()在主进程中的调用会被阻止,也就是redis的持久化功能暂时失效。默认为no,这样能保证数据安全
    no-appendfsync-on-rewri编程客栈te no
    
    # 设置自动进行AOF重写的基准值,也就是重写启动时的AOF文件大小,假如redis自启动至今还没有进行过重写,那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例,则会触发重写。如果设置auto-aof-rewrite-percentage为0,则会关闭此重写功能
    auto-aof-rewrite-percentage 100
    # 设置一个最小大小,是为了防止在aof很小时就触发重写
    auto-aof-rewrite-min-size 64mb

    4、数据安全性

    AOF文件会记录从上一次重写到现在的所有写操作,redis故障恢复后会重新执行这些写操作指令,设置了过期时间的key也会被重新写入并重新设置过期时间,从而恢复到故障前的数据状态

    5、补充

    AOF文件重写可以简单的理解为redis会自动的根据重写机制配置去定时的清理那些冗余的、不再必要的命令,仅保留当前使用中的数据命令,由此可以减少AOF文件的体积,减少磁盘空间使用率以及提高数据恢复的速度。

    总结

    以上为个人经验,希望能给大家一个参考,也希望大家多多支持编程客栈(www.devze.com)。

    0

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    关注公众号