Redis持久化

Redis有两种持久化方式：“快照（RDB）文件”和“追加文件（AOF文件）”。

RDB

基本原理

RDB的工作原理是Redis会创建一个子进程，然后子进程将数据写入到临时RDB文件中。当子进程完成写入RDB文件时，它将替换旧的RDB文件。

优点

• RDB文件非常简洁，相比后来的AOF方法。您可以设置一个时间点来归档RDB文件，这样我们就可以轻松地将数据恢复到归档时间点。
• RDB的性能也非常好。当需要持久化时，会创建一个子进程来完成持久化工作，而不影响主进程。
• 与AOF方式相比，当数据量较大时，RDB的启动速度会比AOF更快。

缺点

• RDB 更有可能丢失数据。 RDB通常设置为持久化的频率。如果Redis由于某种原因挂掉了，那么自上次持久化以来这段时间的数据将会丢失。
• 同一种RDB格式，由于Redis版本不同，会存在版本兼容性问题。不同版本的Redis生成的RDB文件有可能不兼容。
• 无法实现实时持久化。即使手动触发，仍然需要创建子流程来处理，频繁执行效率也不会很高。

相关配置

在Redis配置文件中，我们可以在「SNAPSHOTTING」节点下找到相关内容来查找RDB配置信息。

保存点

可以配置保存点，让Redis在几秒内数据发生N次变化时保存快照文件。其格式如下：

保存时间（秒）更改次数

例如，如果30秒内配置更改100次，则会保存快照文件。

节省 30 100

同时我们可以配置多种保存策略。默认配置文件示例中配置了三个。如果我们想禁用快照保存策略怎么办？有两种方法。第一个是注释掉所有的保存策略，第二个是在最后添加一个配置。配置信息如下：

保存“”

错误处理

默认情况下，如果Redis持久化失败，将停止接收数据。目的是让用户知道此时RDB持久化已经失败。该配置信息如下：

停止写入bgsave错误是

如果您想禁用此功能，请将值设置为 false。

数据压缩

默认情况下，Redis 使用 LZF 来压缩数据。但该功能会消耗一定的CPU性能。如果需要关闭该功能，只需将其设置为 false 即可。

rdb压缩是

数据验证

在Redis5及以上版本中，Redis会在生成的RDB文件末尾添加CRC64校验码。您可以使用此检查代码来检查文件是否完整，但此配置会消耗CPU性能。如果你想追求极致的性能，可以将其关闭。

rdbchecksum 是

转储文件

RDB文件的文件名和目录可以通过以下两种配置来设置：

# RDB 文件名 
dbfilename dump.rdb
# RDB 文件目录 
dir ./

手动触发

默认情况下，Redis会根据我们配置的保存点触发RDB持久化。如果我们想手动触发，可以使用以下两种方法。

保存

使用save命令会同步生成RDB快照文件，这意味着在持久化过程中所有其他客户端请求都将被阻塞。因此，不建议在生产环境中使用该命令。

bgsave

从名字上就可以看出，这个命令会在后台保存RDB文件。调用该命令后，立即返回“OK”信息。 Redis会创建一个子进程来处理它，然后恢复客户端的服务。

AOF

通过上面的方法，我们知道快照方法并不是那么可靠，因为它有一个快照真空期。如果我们的服务挂了或者Redis服务被杀了，那么RDB文件最后一次持久化时间到服务器挂掉这段时间的数据就会丢失。与RDB相比，AOF提供了更可靠的持久化方法。每当 Redis 收到修改数据的命令时，它都会通过追加的方式将该命令写入 AOF 文件中。当重新启动Redis时，AOF中的命令被重写并执行一次，数据被恢复。

优点

• 比RDB方法更可靠。默认情况下，您可以设置每秒一次 fsync，这意味着最多丢失一秒的数据。
• AOF通过追加写入的方式写入数据。即使发生紧急情况，也不会造成文件定位或损坏问题。
• 由于 AOF 文件是通过追加写入方式记录的，当 AOF 文件过大时，Redis 会在后台进行重写。
• AOF将操作命令一一写入文件中，轻松恢复数据。比如我们flush所有数据，只要我们的AOF文件没有被重写，我们就可以删除flushall命令，然后重启服务。

缺点

• 在相同的数据集下，AOF文件的大小一般会比RDB文件大。
• 在某些fsync策略下，AOF会比RDB慢。通常设置为每秒一次以获得更好的性能。

相关配置

在Redis配置文件中搜索“APPEND ONLY MODE”节点的相关配置，找到AOF配置信息。

启用 AOF

我们可以通过以下配置来开启或关闭AOF功能。默认情况下，该值为 false。

仅附加是

文件名和目录

可以通过配置文件中的"appendfilename"设置AOF文件的名称，通过"dir"可以设置文件的目录。需要注意的是，「dir」的配置是与RDB共享的。

appendfilename "appendonly.aof"

可靠性

Redis 调用 fsync 的频率有以下三个选项可以选择：

• 「appendfsync always」 每次将新命令附加到 AOF 时调用 fsync。最慢，但最安全。
• 「appendfsync everysec」 每秒调用一次 fsync，相对安全，最多可能丢失 1s 的数据。
• 「appendfsync no」永远不要主动调用fsync，交给系统处理。这种方法速度最快，但安全性一般。

#appendfsync 总是
appendfsync 每秒
#appendfsync 没有

记录重写

随着修改操作次数的不断增加，AOF文件会变得越来越大。 AOF会执行重写操作。例如，我们不断地增加一个计数器10,000倍。其实我们可以把10000次的命令改为每次增加10000次，这样命令就减少到1次了。 Redis提供了后台重建AOF文件的功能，可以通过以下两个选项配置重写的触发条件：

自动aof重写百分比100
自动aof重写最小大小64mb

Redis 会记住上次重写后的 AOF 文件大小。如果当前AOF文件超过上一个文件大小的百分比，就会触发重写。同时，必须设置文件的最小值，以防止在很小的时候超过百分比时被覆盖。如果需要禁用重写功能，可以将该百分比设置为0来禁用重写。

自动aof重写百分比0

重写时无附加fsync

该配置的作用是在后台进行AOF重写时将fsync设置为no。
当 AOF 的 fsync 配置为 "everysec" 或 "always" ，且后台运行 RDB 保存或 AOF 重写时，会消耗大量磁盘性能。 。在某些linux配置下，aof同步到磁盘执行fsync会被阻塞很长时间。
目前没有解决办法。为了缓解这个问题，可以将此配置设置为「no」，以防止在执行save或aof重写时在主线程进行fsync。这意味着「appendfsync」为0，这很可能会导致数据丢失。如果您遇到延迟问题，可以将此值设置为 “是”。如果您需要更多地确保数据完整性，则应将其设置为“false”。

重写时无附加fsync 否

aof-负载截断

该配置的作用是加载文件或报告错误并在AOF文件末尾被截断时退出。

aof-负载截断是

如果值为yes，将加载文件并打印log以通知用户。如果不是，服务将拒绝启动。我们需要使用「redis-check-aof」工具修复AOF文件并重启。

RDB-AOF 混合方法

Redis 4.0版本添加了新的混合持久化方法。混合持久化方式结合了RDB和AOF持久化方式，将数据写入到AOF文件中。这样做的好处是可以结合RDB和AOF的优点，快速加载数据，同时避免过多的数据丢失。默认情况下，如果启用了 AOF，则该配置也默认启用。

aof-use-rdb-前导码是

总结

对于RDB和AOF持久化方式来说，它们各有优缺点。我们应该根据自己的实际业务情况选择合理的持久化方案。关于配置角色的更多信息，我们可以参考Redis中给出的示例配置文件注释和官网文档信息。