前言：
Redis 作为一种快速、高效的内存数据库，被广泛应用于缓存、消息队列、会话存储等场景。然而，由于其特性是基于内存的，一旦服务器进程退出，内存中的数据就会丢失。为了解决这一问题，Redis 提供了持久化功能，可以将内存中的数据保存到硬盘上，以便在服务器重启时恢复数据。持久化是 Redis 的关键特性之一，对于确保数据的安全性和可靠性至关重要。本文将深入探讨 Redis 的持久化策略，包括常用的持久化方式以及各自的优缺点。
目录
前言：
RDB：
执行方式：
缺点：
AOF：
工作原理：
执行方式：
总结：
当Redis崩溃之后，Redis中的数据就会丢失掉。在Redis重建缓存的过程中，如果有大量请求访问，就会直接打到MySQL中，有可能会导致MySQL崩溃。
归根结底是因为：我们没有给Redis中的数据做持久化。而Redis本身它是有持久化策略的，那就是RDB和AOF。
RDB：
RDB 的全称是Redis Database Backup file（Redis数据备份文件），也叫做Redis数据快照。
-
工作原理：
- Redis 在指定的时间间隔内（由用户配置），将内存中的数据库状态以快照的形式保存到磁盘上。
- Redis 会 fork 出一个子进程来执行保存操作，父进程继续处理客户端请求。这样可以避免阻塞主进程，保证了服务的正常响应。
-
生成的文件：
- RDB 文件是一个经过压缩的二进制文件，通常以
.rdb为扩展名。 - RDB 文件记录了 Redis 在某个时间点上的数据库状态，包括所有的键值对、过期时间、数据库配置等信息。
- RDB 文件是一个经过压缩的二进制文件，通常以
执行方式：
手动执行RDB：
Redis主进程执行RDB,阻塞其他命令：
SAVERedis子进程执行RDB，主进程仍然可以接收命令：
BGSAVE自动执行RDB：
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
这里官方为我们提供了三种RDB的触发频率：
- 每 3600 秒（1 小时），如果至少有 1 次写操作；
- 每 300 秒（5 分钟），如果至少有 100 次写操作；
- 每 60 秒，如果至少有 10000 次写操作。
BGSAVE的命令流程：
BGSAVE有一个问题：当我们开启子进程去写RDB文件的时候，此时主进程仍然是可以接受用户命令的。在这个过程中就可能会出现脏数据。
缺点：
-
全量备份：
- RDB 是一种全量备份方式，它只会保存生成 RDB 文件时的数据库状态。这意味着如果 Redis 服务器意外崩溃，最后一次保存后的所有数据更改都将丢失。对于一些对数据完整性要求极高的应用，这种全量备份的方式可能不够理想。
-
数据丢失风险：
- RDB 持久化的保存间隔可以设置得很长，例如默认的每小时一次，或者更长。如果 Redis 服务器在两次保存之间崩溃，将会丢失整个时间段内的所有更改，导致数据丢失的风险。
-
性能开销：
- 在执行 RDB 持久化时，Redis 会 fork 出一个子进程来执行保存操作。这个过程中需要消耗一定的系统资源和时间，可能会影响 Redis 服务器的性能。特别是在数据量较大、保存频率较高的情况下，保存操作可能会导致系统负载升高，甚至影响到用户请求的响应时间。
-
不适合实时备份：
- 由于 RDB 是全量备份，生成 RDB 文件的过程可能会消耗大量的时间和资源，因此不适合在实时或高频率的数据备份场景中使用。如果需要实时备份，可能需要考虑其他方式，比如使用 AOF（Append-Only File）持久化方式。
-
可用性和恢复时间：
- 在使用 RDB 持久化时，恢复数据通常需要加载整个 RDB 文件，这可能会导致较长的恢复时间，尤其是当数据量较大时。这会影响 Redis 服务器的可用性，特别是在紧急情况下需要快速恢复服务时。
我们可以简单的理解把RDB理解为定期持久化内存数据库中的所有数据。
AOF：
AOF全程叫做 Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF中，可以看作是命令日志文件。
工作原理：
-
追加写入：
- Redis 将每个写操作以追加的方式记录到 AOF 文件末尾，而不是像 RDB 那样周期性地保存整个数据集的快照。这意味着 AOF 文件包含了重放服务器写操作所需的所有信息。
-
重放恢复：
- 当 Redis 重新启动时，它会按顺序重放 AOF 文件中的写操作，以恢复服务器的状态。通过逐行执行 AOF 文件中的命令，Redis 可以将数据集恢复到最后一次保存时的状态。
-
重写机制：
- 为了避免 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 方式则适用于实时数据的持久化和灾难恢复。合理选择和配置持久化方式，可以根据业务需求和性能要求来平衡数据的安全性和性能。
如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！
