Redis持久化机制以及选择

代码帮工

已于 2024-09-09 19:22:10 修改

阅读量522

点赞数 12

分类专栏： redis 文章标签： java redis 缓存

于 2024-09-09 19:21:13 首次发布

本文链接：https://blog.csdn.net/2201_75622149/article/details/142066948

版权

redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

RDB方式

触发机制

手动触发

使用save命令：会阻塞当前Redis服务器，知道RDB过程完成为主，如果内存数据较多，会造成长时间阻塞，影响其他命令的使用，不建议轻易使用。

使用bgsave命令：Redis进程执行fork指令创建子进程，由子进程实现RDB持久化，有需要时建议使用bgsave命令。

自动触发

使用save相关配置，格式：save m n 表示m秒内数据集存在n次修改时会自动触发bgsave命令。

save 900 1 #900秒内如果超过了1个key被修改则发起快照保存

save 300 10 #300秒内如果超过10个key被修改，则发起快照保存

save 60 10000

优点

RDB快照文件是一个紧凑压缩的二进制文件，非常使用用于备份，全量复制等场景。开发中可以按照每6个小时执行一次bgsave备份。

Redis加载RDB恢复数据远远快于AOF方式

缺点

RDB无法做到实时持久化/秒级持久化，每次bgsave时都需要fork子进程，频繁执行有时间成本。

RDB快照文件不同版本格式不一样，容易引起兼容问题。

AOF方式

AOF与RDB不一样，它是一独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。解决了数据持久化的实时性的问题。

Redis默认是不开启的，需要使用时，需要配置：appendonly yes

AOF 有3种文件同步策略

策略	解释
appendfsync always	收到命令就立即写到磁盘，效率最慢，但是能保持完全的持久化
appendfsync everysec	每秒写入磁盘一次，在性能和持久化方面做了很好的折中
appendfsync no	完全以依赖os，一般同步周期时30秒

优点

AOF方式数据安全性更高，配置得当，最多损失1秒的数据量

在不小心执行flushall命令，也可以通过AOF方式恢复（删除最后一个命令即可）

AOF日志是一个增量日志文件，不会存在断电时出现损坏问题。即使出现问题，redis-check-aof工具也能够轻松修复它。

当AOF变得太大时，Redis能够在后台自动重写AOF

缺点

相同的数量来说，AOF文件体积通常大于RDB文件

数据持久化性能上来说，AOF比RDB慢

RDB-AOF混合方式

混合持久化时结合了RDB和AOF的优点，在写入的时候，先把当前的数据以RDB的形式写入文件的开头，在将后续的操作命令以AOF的格式存入文件。即以RDB作为全量备份，AOF作为增量备份，来提高备份效率。这样既能保证Rdis重启时的速度，又能防止数据丢失的风险，这就是Redis 4.0 之后推出的RDB-AOF混合持久化模式，其作为默认配置来使用。