前言： 

        Redis 作为一种快速、高效的内存数据库，被广泛应用于缓存、消息队列、会话存储等场景。然而，由于其特性是基于内存的，一旦服务器进程退出，内存中的数据就会丢失。为了解决这一问题，Redis 提供了持久化功能，可以将内存中的数据保存到硬盘上，以便在服务器重启时恢复数据。持久化是 Redis 的关键特性之一，对于确保数据的安全性和可靠性至关重要。本文将深入探讨 Redis 的持久化策略，包括常用的持久化方式以及各自的优缺点。

目录

前言： 

RDB：

执行方式： 

缺点：

AOF：

工作原理：

执行方式：

总结：

---

当Redis崩溃之后，Redis中的数据就会丢失掉。在Redis重建缓存的过程中，如果有大量请求访问，就会直接打到MySQL中，有可能会导致MySQL崩溃。

归根结底是因为：我们没有给Redis中的数据做持久化。而Redis本身它是有持久化策略的，那就是RDB和AOF。

RDB：

RDB  的全称是Redis Database Backup file（Redis数据备份文件），也叫做Redis数据快照。

1. 工作原理：

   • Redis 在指定的时间间隔内（由用户配置），将内存中的数据库状态以快照的形式保存到磁盘上。
   • Redis 会 fork 出一个子进程来执行保存操作，父进程继续处理客户端请求。这样可以避免阻塞主进程，保证了服务的正常响应。

2. 生成的文件：

   • RDB 文件是一个经过压缩的二进制文件，通常以 .rdb 为扩展名。
   • RDB 文件记录了 Redis 在某个时间点上的数据库状态，包括所有的键值对、过期时间、数据库配置等信息。

执行方式： 

手动执行RDB：

Redis主进程执行RDB,阻塞其他命令：

SAVE

 Redis子进程执行RDB，主进程仍然可以接收命令：

BGSAVE

自动执行RDB：

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

这里官方为我们提供了三种RDB的触发频率：

• 每 3600 秒（1 小时），如果至少有 1 次写操作；
• 每 300 秒（5 分钟），如果至少有 100 次写操作；
• 每 60 秒，如果至少有 10000 次写操作。

 BGSAVE的命令流程：

BGSAVE有一个问题：当我们开启子进程去写RDB文件的时候，此时主进程仍然是可以接受用户命令的。在这个过程中就可能会出现脏数据。 

缺点：

1. 全量备份：

   • RDB 是一种全量备份方式，它只会保存生成 RDB 文件时的数据库状态。这意味着如果 Redis 服务器意外崩溃，最后一次保存后的所有数据更改都将丢失。对于一些对数据完整性要求极高的应用，这种全量备份的方式可能不够理想。

2. 数据丢失风险：

   • RDB 持久化的保存间隔可以设置得很长，例如默认的每小时一次，或者更长。如果 Redis 服务器在两次保存之间崩溃，将会丢失整个时间段内的所有更改，导致数据丢失的风险。

3. 性能开销：

   • 在执行 RDB 持久化时，Redis 会 fork 出一个子进程来执行保存操作。这个过程中需要消耗一定的系统资源和时间，可能会影响 Redis 服务器的性能。特别是在数据量较大、保存频率较高的情况下，保存操作可能会导致系统负载升高，甚至影响到用户请求的响应时间。

4. 不适合实时备份：

   • 由于 RDB 是全量备份，生成 RDB 文件的过程可能会消耗大量的时间和资源，因此不适合在实时或高频率的数据备份场景中使用。如果需要实时备份，可能需要考虑其他方式，比如使用 AOF（Append-Only File）持久化方式。

5. 可用性和恢复时间：

   • 在使用 RDB 持久化时，恢复数据通常需要加载整个 RDB 文件，这可能会导致较长的恢复时间，尤其是当数据量较大时。这会影响 Redis 服务器的可用性，特别是在紧急情况下需要快速恢复服务时。

我们可以简单的理解把RDB理解为定期持久化内存数据库中的所有数据。

AOF：

AOF全程叫做 Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF中，可以看作是命令日志文件。

工作原理：

1. 追加写入：

   • Redis 将每个写操作以追加的方式记录到 AOF 文件末尾，而不是像 RDB 那样周期性地保存整个数据集的快照。这意味着 AOF 文件包含了重放服务器写操作所需的所有信息。

2. 重放恢复：

   • 当 Redis 重新启动时，它会按顺序重放 AOF 文件中的写操作，以恢复服务器的状态。通过逐行执行 AOF 文件中的命令，Redis 可以将数据集恢复到最后一次保存时的状态。

3. 重写机制：

   • 为了避免 AOF 文件过大而影响性能，Redis 提供了 AOF Rewrite 机制。AOF Rewrite 会在后台启动一个子进程，该进程会重新生成一个新的 AOF 文件，但新文件的大小通常会比原始文件小得多，因为它只包含重要的写操作指令。重写后的 AOF 文件可以替代原始文件，以节省磁盘空间并提高性能。

执行方式：

AOF默认是关闭的，我们可以通过修改redis.conf配置文件来开启AOF：

AOF文件的名称： 

 AOF执行策略：

官网一共为我们提供了三种执行策略：

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	对性能要求高
everysec	每秒刷盘	性能适中	最多丢失一秒数据
no	操作系统控制	性能最好	可靠性差，可能会丢失大量数据

可以用图来展示AOF的机制 

这里其实就暴漏了AOF的一个问题：可能会记录大量无意义的命令。比如我们记录对一个Key的多次写操作，但是只有最后一次才有意义。

通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。而Redis也会在阈值触发的时候自动重写AOF文件，阈值也可以在redis.conf中进行配置：

总结：

         Redis 的持久化策略是确保数据安全性和可靠性的重要手段之一。通过持久化，Redis 可以将内存中的数据定期写入到硬盘上，从而在服务器重启时能够恢复数据。本文介绍了 Redis 的两种主要持久化方式：RDB（Redis DataBase）和AOF（Append Only File），并分析了它们各自的优缺点。RDB 方式适用于备份和恢复大量数据，而 AOF 方式则适用于实时数据的持久化和灾难恢复。合理选择和配置持久化方式，可以根据业务需求和性能要求来平衡数据的安全性和性能。

如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！