Redis持久化机制

最新推荐文章于 2024-10-08 19:52:31 发布

smile坊

最新推荐文章于 2024-10-08 19:52:31 发布

阅读量325

点赞数

分类专栏： redis 文章标签： redis 数据库 java

本文链接：https://blog.csdn.net/qq_52896771/article/details/129111474

版权

redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Redis工作时数据都存储在内存中，万一服务器断电，则所有数据都会丢失。针对这种情况，Redis采用持久化机制来增强数据安全性。说白了就是把内存里的数据保存到硬盘上。

1.RDB

①机制描述

在满足特定触发条件时把内存中的数据本身作为一个快照保存到硬盘上的文件中。Redis默认开启RDB机制。

②触发时机

[1]基于默认配置

save 900 1
save 300 10
save 60 10000

含义

配置	含义
save 900 1	900秒内至少有一次修改则触发保存操作
save 300 10	300秒内至少有10次修改则触发保存操作
save 60 10000	60秒内至少有1万次修改则触发保存操作

[2]使用保存命令

save或bgsave

[3]使用flushall命令

这个命令也会产生dump.rdb文件，但里面是空的，没有意义

[4]服务器关闭

如果执行SHUTDOWN命令让Redis正常退出，那么此前Redis就会执行一次持久化保存。

③相关配置

配置项	取值	作用
save	""	禁用RDB机制
dbfilename	文件名，例如：dump.rdb	设置RDB机制下，数据存储文件的文件名
dir	Redis工作目录路径	指定存放持久化文件的目录的路径。<br>注意：这里指定的必须是目录不能是文件名

④思考

RDB 机制能够保证数据的绝对安全吗？

- 机制本身并不能保证绝对安全
- 但是作为总体机制的一部分，RDB（或AOF）机制能够起到它独特的作用；整体机制综合来看是可靠的

2.AOF

①机制描述

根据配置文件中指定的策略，把生成数据的命令保存到硬盘上的文件中。一个AOF文件的内容可以参照下面的例子：


*2
$6
SELECT
$1
0
*3
$3
set
$3
num
$2
10
*2
$4
incr
$3
num
*2
$4
incr
$3
num
*2
$4
incr
$3
num

生成上面文件内容的Redis命令是：

set num 10
incr num
incr num
incr num

②AOF基本配置

配置项	取值	作用
appendonly	yes	启用AOF持久化机制
	no	禁用AOF持久化机制[默认值]
appendfilename	"文件名"	AOF持久化文件名
dir	Redis工作目录路径	指定存放持久化文件的目录的路径。<br>注意：这里指定的必须是目录不能是文件名
appendfsync	always	每一次数据修改后都将执行文件写入操作，是最安全的方式但是速度缓慢。
	everysec	每秒执行一次写入操作。折中。
	no	由操作系统在适当的时候执行写入操作，Redis性能最好，数据保存次数最少。

当 AOF 和 RDB 机制并存时，Redis 会优先采纳 AOF 机制。使用 AOF 持久化文件恢复内存中的数据。而 AOF 刚刚开启时 appendonly.aof 持久化文件中没有任何数据。拿空的 appendonly.aof 持久化文件恢复内存，就会导致以前所有数据都丢失。

③AOF重写

对比下面两组命令：

AOF重写前	AOF重写后
set count 1 incr count incr count incr count	set count 4

AOF重写前

AOF重写后

set count 1

incr count

set count 4

两组命令执行后对于count来说最终的值是一致的，但是进行AOF重写后省略了中间过程，可以让AOF文件体积更小，缩短数据恢复时间。而Redis会根据AOF文件的体积来决定是否进行AOF重写。参考的配置项如下：

配置项	含义
auto-aof-rewrite-percentage 100	文件体积增大100%时执行AOF重写
auto-aof-rewrite-min-size 64mb	文件体积增长到64mb时执行AOF重写

实际工作中不要进行频繁的AOF重写，因为CPU、内存资源和硬盘资源二者之间肯定是CPU、内存资源更加宝贵，所以不应该过多耗费CPU性能去节省硬盘空间。另外数据恢复也不是高频操作，所以节约数据恢复时间价值也不是非常大。

3.持久化文件损坏修复

Redis服务器启动时如果读取了损坏的持久化文件会导致启动失败，此时为了让Redis服务器能够正常启动，需要对损坏的持久化文件进行修复。这里以AOF文件为例介绍修复操作的步骤。

- 第一步：备份要修复的appendonly.aof文件
- 第二步：执行修复程序

/usr/local/redis/bin/redis-check-aof --fix /usr/local/redis/appendonly.aof

- 第三步：重启Redis

注意：所谓修复持久化文件仅仅是把损坏的部分去掉，而没法把受损的数据找回。

4.扩展阅读：两种持久化机制的取舍

①RDB

[1]优势

适合大规模的数据恢复，速度较快

[2]劣势

会丢失最后一次快照后的所有修改，不能绝对保证数据的高度一致性和完整性。Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑，但上述成立有条件，Linux也有优化手段

②AOF

[1]优势

选择appendfsync always方式运行时理论上能够做到数据完整一致，但此时性能又不好。文件内容具备一定可读性，能够用来分析Redis工作情况。

[2]劣势

持久化相同的数据，文件体积比RDB大，恢复速度比RDB慢。效率在同步写入时低于RDB，不同步写入时与RDB相同。

③RDB和AOF并存

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

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)、快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

④使用建议

如果Redis仅仅作为缓存可以不使用任何持久化方式。

其他应用方式综合考虑性能和完整性、一致性要求。

RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。如果不开启AOF，仅靠Master-Slave Replication 实现高可用性能也不错。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构。