Redis持久化

Redis支持异步将内存中的数据写入到硬盘上,同时不影响继续服务

Redis持久化机制目前以后3种，分别为：

1>快照方式（RDB, Redis DataBase）

2>文件追加方式（AOF, Append Only File）

3>混合持久化方式（Redis4版本之后）

第一种快照方式就是 Redis DataBase来存储数据，

Snapshotting(快照)默认方式，将内存数据中以快照的方式写入到二进制文件中，默认为dump.rdb。触发RDB持久化过程分手动触发与自动触发。

Redis 主线程：主线程负责处理客户端发送的命令请求，执行数据操作，处理持久化，以及其他与 Redis 服务器相关的任务。主线程不会因为执行持久化操作而自行阻塞，因为 Redis 使用了异步的持久化机制来确保主线程的高性能和可用性。
BGSAVE 执行时机：BGSAVE 操作的执行时机通常是在满足一定条件下触发的，例如当服务器的内存使用量达到一定阈值，或者根据配置文件中设置的自动持久化策略。当满足了执行条件后，Redis 会自动触发 BGSAVE 操作。
BGSAVE 子线程：当执行 BGSAVE 操作时，Redis 会创建一个子进程来执行持久化操作。这个子进程会复制主进程的内存数据，并在内存中进行持久化操作，然后将持久化后的数据写入到磁盘上的持久化文件中。完成持久化操作后，子进程会自行销毁，不会影响主线程的正常运行。
内存数据的持久化：在 BGSAVE 操作中，子进程会将主线程的内存数据复制一份，并在内存中进行持久化操作，然后将持久化后的数据写入到磁盘上的持久化文件中。这样可以确保在持久化操作期间，主线程仍然可以继续处理客户端请求，保持高性能和可用性。

第二种方式AOF, Append Only File

可以将 AOF 持久化方式理解为备份数据和还原数据的过程：

写操作（备份数据）： 当客户端对 Redis 执行写操作时，例如设置键值对、删除键等，Redis 将这些写操作以追加的方式记录到 AOF 文件中。这个过程可以看作是备份数据的过程，将内存中的数据持久化到磁盘上的 AOF 文件中。
读操作（还原数据）： 当 Redis 服务器启动时，或者执行 BGREWRITEAOF 命令时，Redis 会读取 AOF 文件，并逐行执行其中的命令来还原数据。这个过程可以看作是从 AOF 文件中读取数据，并将其加载到内存中，从而恢复数据到 Redis 数据库中。

对 AOF 的理解

写操作：AOF（Append Only File）是 Redis 的一种持久化方式。它将客户端的写操作以追加的方式记录到一个文本文件中。
读操作：redis 服务器启动的时候，会读取 AOF文件到内存中，并逐行执行其中的 redis 命令来还原数据
优势
- 对 CPU 和内存友好，相较于 RDB，不需要那么多的额外性能来执行持久化操作
- 定期记录客户端的写操作到文本文件中（不是每次都写到磁盘上，而是有一个缓冲区），确保数据的完整性和一致性
劣势
- AOF 文件大小通常比较大。
- 可能存在一些冗余操作，导致在数据恢复时可能较慢。
- 【优化冗余】AOF 文件重写（AOF rewrite）：定期对 AOF 文件进行重写，以减少文件的大小和冗余操作，提高数据恢复的运行效率。

Redis 4.0 之后推出的 RDB-AOF 混合持久化模式，其作为默认配置来使用。

全量备份（RDB）： 当执行备份操作时，Redis 首先会将当前所有的数据以全量备份的方式保存到 RDB 文件中。这个全量备份包含了当前数据的完整快照，可以用于在 Redis 重启时快速恢复数据。
增量备份（AOF）： 紧接着，Redis 会将后续的客户端写操作以增量备份的方式记录在 AOF 文件中。这个增量备份记录了对数据的修改操作，可以保证即使在 Redis 重启时发生故障，也能够恢复到最后一次持久化的状态。
恢复过程： 在 Redis 重启时，先使用 RDB 文件进行快速恢复数据，然后再重新执行 AOF 文件中记录的操作命令，来完成数据的完整恢复。这样一来，既能够保证 Redis 重启的速度，又能够降低数据丢失的风险。

混合持久化模式结合了 RDB 和 AOF 的优点，为 Redis 提供了更为可靠的数据持久化和恢复机制。这种模式在实际应用中被广泛采用，以确保数据的安全和可靠性。

讲了这么多，但最终在生产条件下，推荐的使用方式是混合持久化模式，也就是 Redis 4.0 版本之后提供的默认持久化方式