Redis 持久化

最新推荐文章于 2024-01-05 11:02:23 发布
最新推荐文章于 2024-01-05 11:02:23 发布
阅读量1.2k 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： Redis 文章标签： redis 数据库开发
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/shiyansama/article/details/123858972

本笔记基于bilibili尚硅谷Redis学习视频整理而来

Redis`提供了两种不同形式的持久化方式：

  • RDB（Redis DataBase）

  • AOF（Append Of File）

image-20220329151909245

官网介绍：http://www.redis.io

Redis持久化之RDB

是什么

官网关于RDB的介绍：

image-20220329151949706

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

备份是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

关于fork

  • fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

  • 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了"写时复制技术"

  • 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

RDB持久化流程

image-20220329153005389

dump.rdb文件

可以在redis.conf中设置文件名称，默认为dump.rdb

windows为redis.windows.conf

找到SNAPSHOTTING区域，即可在里面看到dbfilename配置项：

image-20220329153423838

文件存放位置

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下：

image-20220329153538131

image-20220329155043835

如何触发RDB快照 与 保持策略
配置文件中默认的快照配置

image-20220329154004923

它们分别表示：

  • 在900秒内有1个key发生变化，执行save命令
  • 在300秒内有10个key发生变化，执行save命令
  • 在60秒内有10000个key发生变化，执行save命令

可以根据这个规则，自行添加/修改save相关配置。

命令 save VS bgsave

save：save时只管保存，其它不管，全部阻塞；手动保存；不建议。

bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

可以通过lastsave命令获取最后一次成功执行快照的时间

flushall命令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

Save

格式：save 秒钟 写操作次数

RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

可以禁用，不设置save指令，或者给save传入空字符串

stop-writes-on-bgsave-error

image-20220329155528599

当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.

rdbcompression 压缩文件

image-20220329155550109

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

如果不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

rdbchecksum 检查完整性

image-20220329155617669

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，

但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐yes。

rdb的备份

rdb文件可以复制多份，放在自己定义的目录中

有时候我们会因为某些原因比如redis服务突然停止、误删数据库的数据造成数据丢失，那么就可以通过rdb文件来以最大可能恢复原有的数据。

现在模拟误删的情况：

image-20220329160821609

假如默认目录中有以往的rbd文件：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WlsV1TUV-1648649978444)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329161058920.png)]

那么只需要重启Redis服务即可看到之前被删除的数据已经被自动回复过来了：

前提是当前目录下的（默认）dump.rdb还没有被修改

image-20220329161124682

假如默认目录下的dump.rdb已经被修改了但却没来得及重启服务，或者被误删，那么可以从其他存放备份文件的路径中找到以往自己手动备份转移的文件，将该文件移动到默认目录下，名字修改为dump.rdb，重启Redis服务即可。

优势

  • 适合大规模的数据恢复

  • 对数据完整性和一致性要求不高更适合使用

  • 节省磁盘空间

  • 恢复速度快

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iyIX1HsK-1648649978445)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329161444467.png)]

劣势

  • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

  • 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

  • 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

如何停止

动态停止RDBredis-cli config set save ""

save后给空值，表示禁用保存策略

小总结

image-20220329161604040

Redis持久化之AOF

是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

image-20220329164846587

开启AOF

Redis的AOF默认是关闭的，可以在配置文件中找到对应的配置项：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MntDFiBd-1648649978446)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329164523888.png)]

可以在redis.conf中配置文件名称，默认为appendonly.aof

image-20220329164645267

AOF文件的保存路径，同RDB的路径一致。

重启Redis服务，可以看到在默认目录下有aof文件生成：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z8ehXZI4-1648649978447)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329165158297.png)]

原有rdb文件不会被删除

AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据。

所以重启Redis服务后可能会看到如下现象，redis数据库为空：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Dw7KgM3k-1648649978448)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329165323439.png)]

AOF 恢复数据

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是平时拷贝备份文件，需要恢复时可拷贝到Redis工作目录下，启动系统即可加载。

正常恢复：

  • 修改默认的appendonly no，改为yes
  • 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
  • 重启redis然后重新加载

异常恢复：

  • 修改默认的appendonly no，改为yes
  • 如遇到AOF文件损坏，备份被写坏的AOF文件
  • 对原文件，通过redis-check-aof --fix appendonly.aof进行恢复
  • 恢复：重启redis，然后重新加载

这里模拟一下aof文件损坏的过程。

用Typero(或随便一款编辑器)打开aof文件，在后面加入一行字符Hell:

image-20220329170618710

尝试重启Redis服务，会被提示被拒绝连接。

此时使用修复命令：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BvXeqkcF-1648649978449)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329170733847.png)]

可以看到出现问题的位置，和修改前后的大小比较。

重启Redis服务，发现可以连上了：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2kxPzB4X-1648649978449)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329170855771.png)]

AOF同步频率设置

可以在conf文件中何止AOF的同步频率：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wudRHcxf-1648649978450)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329171204597.png)]

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

Rewrite压缩
是什么

AOF采用文件追加方式，文件会越来越大。

为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，某些相同指令集内的参数会被压缩到同一条指令内（比如多条set压缩成一条set），旧的文件在Rewrit成功之前。不会被删除。

简单点来说就是创建一个体积优化版本

可以使用命令bgrewriteaof手动异步执行一次AOF文件重写操作。

重写原理，如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

如果no-appendfsync-on-rewrite=yes，不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

其他配置

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次100MB时开始重写。

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF的 当前大小 >= base_size + base_size * 100% (默认)且 当前大小 >= 64mb(默认)的情况下，Redis会对AOF进行重写。

重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-H5sWkoYO-1648649978450)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329164918174.png)]

优势

image-20220329164925096

  • 备份机制更稳健，丢失数据概率更低。

  • 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

  • 比起RDB占用更多的磁盘空间。

  • 恢复备份速度要慢。

  • 每次读写都同步的话，有一定的性能压力。

  • 存在个别Bug，造成恢复不能。

小总结

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VDsqxqdH-1648649978451)(https://cdn.jsdelivr.net/gh/senluoye/BadGallery@main/image/image-20220329164932671.png)]

两者比较(Which one)

用哪个好

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

官网建议

image-20220329165025953

  • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

  • AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

  • Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

  • 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

  • 同时开启两种持久化方式

  • 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

  • RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

  • 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

  • 性能建议

    • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

    • 如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。

      代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

      只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。

      默认超过原大小100%大小时重写可以改到适当的数值。

Redis中的持久化详解
weixin_67596609的博客
07-14 2368
本篇文章会对Redis的持久化进行详解。主要涉及到的方面有：redis为什么需要持久化、redis怎么进行的持久化、持久化的方式都有哪些、每种持久化方式的优缺点是什么、持久化的流程进行展开详解。希望本篇文章会对你有所帮助。
Redis持久化
最新发布
xike1024的博客
06-19 930
Redis 持久化：解决了内存数据库数据易失性的问题，确保在服务器重启或发生故障时，数据能够得以恢复。
深度剖析Redis持久化机制｜高性能架构师带你掌握RDB、AOF与混合模式的核心原理与生产实践
Zyw907155124的博客
01-05 3093
万字长文详解RDB快照的二进制压缩机制、AOF日志的增量重写策略，以及混合持久化如何实现毫秒级恢复。通过源码级原理剖析+生产环境参数配置指南，揭示： 1️⃣ RDB如何通过写时复制技术实现高效内存快照 2️⃣ AOF重写缓冲区如何保证日志完整性 3️⃣ 混合持久化在Redis4.0+的底层实现奥秘 4️⃣ 不同业务场景下的持久化选型策略
Macbook Pro进行Docker安装Redis并配置Redis持久化
10-20
Macbook Pro进行Docker安装Redis并配置Redis持久化
redis持久化
01-07
redis持久法的方式主要为两种：快照（rdb）；写日志（aof）； rdb原理 rdb实现持久化主要是将当前进程中的数据生成快照保存到硬盘上，在重启的时候读取硬盘上的数据（如果同时配置了aof，将会先执行aof策略，因为...
02-Redis持久化、主从与哨兵架构详解.zip
11-18
Redis是一款高性能的键值对内存数据库，常用于缓存、消息队列以及数据持久化等场景。本资料包主要探讨Redis的三个核心概念：持久化、主从复制和哨兵架构，这些都是确保Redis高可用性和数据安全的重要机制。 首先，...
redis9:持久化
Yisnow.的博客
10-03 198
redis的RDB持久化功能，可以将redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。 1、RDB文件的创建和载入 SAVE命令会阻塞服务器进程直到文件创建完毕为止，期间服务器不能执行任何命令请求。 BGSAVE会派生出一个子进程由子进程负责创建RDB文件，服务器进行继续处理命令请求。 RDB文件的载入工作是在服务器启动时自动执行的。只要检测到RDB文件的存在，会自动载入。 AOF文件的更新频率通常比RDB文件的更新频率高，所以服务器开启了AOF持久化，服务器会优先使用AOF文件还原数据库状
Redis持久化----RDB和AOF 的区别
热门推荐
ljheee的博客
07-28 3万+
关于Redis说点什么，目前都是使用Redis作为数据缓存，缓存的目标主要是那些需要经常访问的数据，或计算复杂而耗时的数据。缓存的效果就是减少了数据库读的次数，减少了复杂数据的计算次数，从而提高了服务器的性能。 一、redis持久化----两种方式 1、redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。 2、RDB，简
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值