Redis 持久化

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

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

• RDB（Redis DataBase）

• AOF（Append Of File）

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

Redis持久化之RDB

是什么

官网关于RDB的介绍：

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

备份是如何执行的

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

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

关于fork

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

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

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

RDB持久化流程

dump.rdb文件

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

windows为redis.windows.conf

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

文件存放位置

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

如何触发RDB快照 与 保持策略

配置文件中默认的快照配置

它们分别表示：

• 在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

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

rdbcompression 压缩文件

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

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

rdbchecksum 检查完整性

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

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

rdb的备份

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

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

现在模拟误删的情况：

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

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

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

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

假如默认目录下的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后给空值，表示禁用保存策略

小总结

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文件中的写操作达到数据恢复的目的；

开启AOF

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

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

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

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:

尝试重启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)]

优势

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

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

劣势

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

• 恢复备份速度要慢。

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

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

小总结

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

两者比较(Which one)

用哪个好

官方推荐两个都启用。

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

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

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

官网建议

• 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%大小时重写可以改到适当的数值。