一、RDB持久化
1. 工作原理
RDB持久化通过定期将内存中的数据快照（snapshotting）写入磁盘文件来实现。当Redis满足配置文件中指定的条件时，会触发一个后台保存操作，生成一个二进制格式的RDB文件（通常名为dump.rdb）。这个过程中，Redis会使用操作系统的写时复制（Copy-On-Write, COW）技术来避免对主进程的阻塞。
具体步骤如下：
- 调用fork()函数：Redis会创建一个子进程来执行持久化操作，而父进程继续处理客户端请求。
- 子进程生成RDB文件：子进程将内存中的数据写入到一个临时RDB文件中。
- 替换旧文件：当临时文件写入完成后，Redis会用新文件替换旧的RDB文件。
2. 触发机制
RDB持久化可以通过自动或手动方式触发：
- 自动触发：通过配置文件中的save指令设置，例如save 900 1表示900秒内如果至少有1个key的值变化，则生成RDB文件。
- 手动触发：执行SAVE或BGSAVE命令。SAVE会阻塞Redis服务器直到保存操作完成，而BGSAVE则会在后台异步执行。
3. 优势和劣势
优势：
- 高效：持久化过程由子进程完成，对主进程性能影响小。
- 紧凑：RDB文件是二进制格式，体积较小，便于备份和传输。
- 恢复速度快：加载RDB文件比AOF文件更快，适合大数据量的恢复。
劣势：
- 数据可能丢失：因为是间隔一定时间进行的，如果Redis意外崩溃，会导致最后一次持久化之后的数据丢失。
- 不适合实时备份：无法做到秒级持久化。
二、AOF持久化
1. 工作原理
AOF持久化通过记录每次写操作到日志文件中来实现数据持久化。当Redis执行写命令时，该命令会被追加到AOF文件的末尾。当Redis重启时，会重新执行这些命令来恢复原始数据集的状态。
具体步骤包括命令追加、文件写入和文件同步：
- 命令追加：写命令被追加到AOF文件的数据缓冲区（aof_buf）。
- 文件写入：在每个事件循环结束前，将aof_buf中的内容保存到AOF文件中。
- 文件同步：根据配置文件的appendfsync参数设置，同步策略可以是always（每次写入都同步）、everysec（每秒同步一次）或no（由操作系统控制同步时机）。
2. AOF重写
由于AOF文件会随着写操作的增加而不断增大，Redis提供了AOF重写机制来压缩文件。重写过程中，Redis会创建一个子进程来生成一个新的AOF文件，只包含恢复当前数据集所需的最小命令集合。
3. 优势和劣势
优势：
- 数据安全性高：几乎不丢失数据，因为每次写操作都会被记录。
- 可读性高：AOF文件是纯文本文件，易于理解和修改。
劣势：
- 写入性能略低：每次写操作都需要追加到文件，相对于RDB性能有所下降。
- 占用磁盘空间大：AOF文件通常比RDB文件大。
三、数据恢复应用
1. RDB恢复
- 准备Redis服务器：停止当前运行的Redis实例。
- 复制RDB文件：将有效的RDB文件（如dump.rdb）复制到Redis数据目录。
- 启动Redis服务器：Redis会自动加载RDB文件中的数据并恢复到数据库中。
2. AOF恢复
- 准备Redis服务器：停止当前运行的Redis实例。
- 复制AOF文件：将有效的AOF文件（如appendonly.aof）复制到Redis数据目录。
- 启动Redis服务器：Redis会自动加载AOF文件中的写操作并恢复数据。
如果同时启用了RDB和AOF，Redis会优先使用AOF文件来恢复数据，因为AOF文件通常包含更详细的写操作日志，更能确保数据的完整性和一致性。
四、总结
Redis的RDB和AOF持久化机制各有特点和用途。RDB适用于对性能要求高、数据恢复精度要求不高的场景，而AOF则适用于数据一致性要求较高的场景。在实际应用中，建议根据具体需求选择合适的持久化方式，甚至可以同时使用两者来确保数据的安全性和完整性。随着Redis版本的不断更新，还引入了混合持久化模式，将RDB和AOF的优势结合，进一步提高了数据持久化的效率和安全性。
