如何让 Redis 更持久？本文教你！

我们从配置文件中的两个配置参数入手，首先是 save 配置。

这个指令是由 Redis 主进程来执行RDB，会阻塞所有命令

我们在配置文件中找到有关于 sava 的配置

1、

dbfilename dump.rdb

该配置项的作用便是用来定义 rdb 文件名（需要注意该名称不能定义为路径，只能定义为文件名称）

当我们执行完 save 命令后，便可在 redis 文件夹中看到一个 dump.rdb   文件

2、

save  

该配置项的作用是用来定义多长时间内发生多少次变化便会执行 bgsave，如果是 save "" 则表示禁用 RDB。

我们接下来打开 save 配置进行测试

dbfilename dump-test.rdb  # 文件名为 dump-test.rdb

save 3600 1  # 在 3600 秒内发生一次更改，便会执行 bgsave

我们通过 redis-cli 进入操作

然后我们退出后便可在当前目录下看到刚刚生成的 dump-test.rdb 文件

说明我们配置是生效的，接着我们直接重启 Redis ，看是否还存在我们刚刚保存的数据

看到我们的数据，就说明 redis 持久化成功了。然后我们把刚刚生成的  dump-test.rdb 文件删除后重启 redis

这可以说明Redis 启动时是靠 .rdb 来恢复文件数据的。那我们上面一直说到的 bgsave，那 bgsave 又是如何执行的呢？

我们在前面有说过两个概念 fork 和 cow，不知道是否还有印象，这两个概念便是关键~！

bgsave 开始的时候会 fork 主进程得到一个新的子进程，而 子进程 是 共享 主进程的内存数据的。子进程会将数据写到磁盘上的一个临时的 .rdb 文件中，当子进程写完临时文件后，会将原来的 .rdb文件替换掉。这个就是 fork 的核心，那什么是 cow 呢？cow 全称 copy-on-write 技术，当主进程执行读操作的时候是访问共享内存的，而主进程执行写操作的时候，则会拷贝一份数据，执行写操作。

具体流程如下：

这种持久化方式有什么优点呢？

• 方便持久化，只有一个 dump.rdb 文件

• 容灾性好，可以将文件保存到安全的磁盘中

• 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，将 IO 最大化，保证 Redis 的高性能

缺点也是有的：

• 数据安全性低，RDB 是间隔一段时间来持久化 （save） ，如果持久化期间 Redis 发生故障，那么就会造成数据丢失，所以这种方式适用于数据要求不是很严谨的情况下使用

• 保存时间长，如果数据量很大，保存快照的时间就会很长，会占用磁盘空间

优劣均沾，斟酌使用

点击关注公众号，Java干货****及时送达

二、AOF

AOF 全称 Append Only File (追加文件)。作用便是 Redis 处理的每一个写命令都会记录在 AOF 文件中，可以看做是命令日志文件。

该功能默认是关闭的，我们可以在 redis.conf 文件中查看有关于 AOF 相关的配置项

1、

appendonly yes   # 开启 AOF 日志记录功能，默认是关闭的

2、

appendfilename “appendonly.aof”  # AOF 文件的名称

以上两个配置项便是用来开启 AOF 日志记录，那么还有个额外的配置项也需要了解

3、

appendfsync everysec   # AOF 命令记录的频率

该配置项有三个可选值

| 配置项 | 刷盘时机 | 优点 | 缺点 |

| — | — | — | — |

| Always | 同步刷盘 | 可靠性高，几乎不会丢失数据 | 性能影响较大 |

| everysec | 每秒刷盘 | 性能适中 | 最多丢失1秒的数据 |

| no | 操作系统控制 | 性能最好 | 可靠性较差，可能丢失大量的数据 |

有了解 Mysql 中 relay log 日志的同学，就不会对这种模型很陌生。

原理：它是将写命令追加到 AOF 文件的末尾，使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机，这是因为对文件进行写入并不会马上将内存同步到磁盘上，而是先存储到缓存区中，然后由操作系统决定什么时候同步到磁盘。

我们开启 AOF 记录功能查看下：

可以看出我们的每一个操作都已经记录到 AOF 文件中，我们这边通过重启 Redis 也一样能获取到刚刚存储的数据，说明持久化是有生效的~

如果你还在到处找面试题，不如上这个Java面试库面试小程序。

我们看到上面的 AOF 记录文件是不是觉得很规整？但是在线上环境中越规整反而不好，因为这文件主要是给机器看的，而不是跟我们看的，因此我们最好能够进行压缩。

为了解决AOF文件体积不断增大的问题，用户可以向Redis发送 bgrewriteaof命令，这个命令会通过 通过移除AOF文件中的冗余命令 来重写（rewrite）AOF文件，使AOF文件的体积变得尽可能地小。bgrewriteaof的工作原理和 bgsave 创建快照的工作原理非常相似：Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF持久化中也同样存在。

既然存在手动触发压缩，那也存在自动触发压缩，这就得说到配置文件中的两个配置项

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

该配置项的意思为当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）的时候，Redis将执行bgrewriteaof命令。

总结下，它的优点如下：

• 数据安全。AOF 持久化可以配置 appendfsync 属性中的 always，每进行一次写命令操作就会记录到 AOF 文件中一次

• 一致性。通过 append 模型写文件，即使中途服务器宕机，也可以通过 redis-check-aof 工具来解决数据一致性问题

缺点如下：

• AOF 文件比 RDB 文件大，而且恢复速度慢

• 数据集大的时候比 RDB 文件启动效率低

同样是优劣均沾，斟酌使用

三、两者区别

分别介绍了两者，我们回顾一下两者有什么区别？

| 方面 | RDB | AOF |

总结

机会是留给有准备的人，大家在求职之前应该要明确自己的态度，熟悉求职流程，做好充分的准备，把一些可预见的事情做好。

对于应届毕业生来说，校招更适合你们，因为绝大部分都不会有工作经验，企业也不会有工作经验的需求。同时，你也不需要伪造高大上的实战经验，以此让自己的简历能够脱颖而出，反倒会让面试官有所怀疑。

你在大学时期应该明确自己的发展方向，如果你在大一就确定你以后想成为Java工程师，那就不要花太多的时间去学习其他的技术语言，高数之类的，不如好好想着如何夯实Java基础。下图涵盖了应届生乃至转行过来的小白要学习的Java内容：

请转发本文支持一下

熟悉求职流程，做好充分的准备，把一些可预见的事情做好。

对于应届毕业生来说，校招更适合你们，因为绝大部分都不会有工作经验，企业也不会有工作经验的需求。同时，你也不需要伪造高大上的实战经验，以此让自己的简历能够脱颖而出，反倒会让面试官有所怀疑。

你在大学时期应该明确自己的发展方向，如果你在大一就确定你以后想成为Java工程师，那就不要花太多的时间去学习其他的技术语言，高数之类的，不如好好想着如何夯实Java基础。下图涵盖了应届生乃至转行过来的小白要学习的Java内容：

请转发本文支持一下

[外链图片转存中…(img-japr3c7E-1718918944487)]

[外链图片转存中…(img-YDzSxinN-1718918944488)]