Redis（4） ——数据持久化

最新推荐文章于 2023-12-10 23:03:18 发布

小盆友你是否很有多问号

最新推荐文章于 2023-12-10 23:03:18 发布

阅读量318

点赞数

分类专栏： Redis 专栏

本文链接：https://blog.csdn.net/qq_43369949/article/details/119815213

版权

Redis 专栏专栏收录该内容

8 篇文章 0 订阅

订阅专栏

Redis（4） ——数据持久化

为什么要持久化？

因为redis的是基于计算机内存存储的，在多数情况之下，服务关闭，电脑关机，断电等行为会导致数据的丢失，持久化就是把redis存到内存的数据提前写到物理硬盘当中，当内存数据丢失的时候呢，能够从硬盘当中恢复

Redis的两种持久化方式

redis自身提供了两种持久化方式，RDB,AOF
RDB：原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化(类似于快照一样)
AOF：持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录

RDB持久化

RDB 有两种触发方式，分别是自动触发和手动触发。
自动触发
在redis.config 下面找到SNAPSHOTTING
在这里插入图片描述
通过save命令来保存（触发bgsave来保存）
save 900 1（900秒redis 执行一次，就拍一次快照）
save 300 10（300秒redis 执行10次，就拍一次快照）
save 60 10000（60秒redis 执行10000次，就拍一次快照）

常见的几个命令
dbfilename（设置快照的名字）
dir（设置快照路径）
rdbcompression（是否对快照进行压缩）
stop-writes-on-bgsave-error（当redis最后一次保存数据失败，遇见错误，是否重启redis）

注意：不需要RDB持久化，直接可以将save “ ” 置空

手动触发
两个命令：save和bgsave
“save”：由于redis是单线程执行当执行save命令的的时候，其他命令不能执行，会导致阻塞，当一个缓存很大的时候，RDB持久化时间过长，严重影响体验，这是不可取的
“bgsave”：创建一个子进程，RDB持久化嫁给子进程，大大提高性能以及体验

RDB 的优点和缺点

优点：

定时的去快照很适合文件的备份
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点：

没法做到实时持久化，定时的持久化，会导致在没达到要求时间的数据修改丢失
bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

AOF持久化

命令执行：config set appendonly yes
AOF 则是通过保存Redis服务器所执行的写命令来记录数据库状态。
在redis.config 下面找到APPEND ONLY MODE
在这里插入图片描述
appendonly：no 表示不用AOF, 开启 AOF 持久化方式，需要将 appendonly 修改为 yes。
appendfilename ：默认的文件名appendonly.aof

appendfsync：aof持久化三种策略的配置；

no表示不执行fsync，速度最快，但是不太安全；
always表示每次写入都执行fsync，效率很低；安全高
everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。

AOF重写

AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

理解：比方说，每次往redis里面添加都会执行sadd这个命令，多次执行就会执行很多歌sadd，重写就是执行一次sadd 然后把之前的value 放在最后面。只需要执行一次sadd。也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。