RDB（Redis Database）持久化原理
-
基本思路：
- Redis将内存中的数据定期"快照"保存到硬盘上，生成一个RDB文件。
- RDB文件采用二进制格式，通过遍历内存中的数据，将其序列化并压缩存储，以节省空间。
-
实现方式：
- 周期性备份：Redis提供配置参数（如"每900秒至少有1次写入操作"），支持根据时间和写入频率组合条件触发快照，避免频繁备份或无意义的重复操作。
- 子进程执行：为了不阻塞主进程，Redis通过fork一个子进程来完成快照操作。子进程将内存数据写入临时文件，完成后替换旧的RDB文件。
-
优点：
- 在崩溃或断电后，Redis可以通过加载RDB文件快速恢复数据。
- 文件体积较小，适合冷备份或传输。
-
缺点：
- 数据丢失风险：由于是周期性备份（通常分钟级别），两次快照之间的数据可能丢失。
- 性能开销：生成快照需要遍历全部数据，若数据量大，fork子进程和写入磁盘会消耗较多资源。
-
MySQL的反馈：
- MySQL指出RDB的分钟级备份无法满足高频请求场景（每秒大量请求），丢失数据量可能较多，建议Redis改进。
AOF（Append Only File）持久化原理
-
基本思路：
- Redis模仿MySQL的二进制日志（binlog），将每次的写入命令（如SET、DEL等）记录到一个AOF文件中。
- 重启时，通过重新执行AOF文件中的命令，恢复数据到崩溃前的状态。
-
实现方式：
- 命令记录：Redis将写入命令追加到AOF文件中。
- 缓冲区优化：为避免频繁写盘拖慢性能，Redis引入缓冲区（AOF Buffer），先将命令暂存于内存，择机同步到磁盘（可配置同步策略：总是同步、每秒同步、不强制同步）。
- AOF重写 ：随着时间推移，AOF文件会因记录所有操作而变得臃肿。Redis通过AOF重写（Rewrite）生成一个精简版本，仅保留最终数据状态。
- 重写过程：fork一个子进程，基于当前内存数据生成新AOF文件。
- 数据一致性：重写期间，主进程继续接收新命令，这些命令被暂存到AOF重写缓冲区（Rewrite Buffer），重写完成后追加到新文件中。
-
优点：
- 数据安全性高：AOF记录每条写入命令，数据丢失量极小（取决于同步策略）。
- 可读性：AOF文件是文本格式，便于理解和调试。
-
缺点：
- 文件体积大：未重写时，AOF文件会持续增长，占用更多空间。
- 恢复速度慢：重启时需要逐条执行命令，恢复时间比RDB长。
-
改进与完善：
- Redis通过AOF重写解决文件膨胀问题，并用双缓冲区（AOF Buffer + Rewrite Buffer）确保重写期间数据一致性。
RDB与AOF的对比与选择
- MySQL的提问：在AOF方案完善后，MySQL问Redis："AOF这么好了，RDB还要不要用？"这让Redis陷入沉思。
- 两者的权衡 ：
- RDB适合快速恢复和大范围备份，但可能丢失数据。
- AOF适合高数据安全需求的场景，但恢复较慢且文件管理复杂。
- 实际应用建议 ：
- 单独使用RDB：适用于对数据丢失不敏感但需要快速恢复的场景。
- 单独使用AOF：适用于数据安全性要求高的场景。
- 混合使用：Redis 4.0后支持RDB+AOF混合模式，RDB作为全量快照，AOF记录增量操作，兼顾恢复速度和数据完整性。
Mermaid图示设计
用于直观展示RDB和AOF的工作流程。
图1：RDB持久化流程
内存数据快照 Redis主进程 fork子进程 生成临时RDB文件 替换旧RDB文件 重启时加载RDB文件 恢复内存数据
说明：RDB通过子进程生成快照，保存到磁盘，重启时直接加载，快速恢复。
图2：AOF持久化与重写流程
Redis主进程 AOF Buffer AOF重写缓冲区 AOF文件 子进程 写入命令暂存 择机同步到AOF文件 fork子进程重写AOF 根据内存生成新AOF文件 重写期间新命令存入 重写完成 追加重写缓冲区命令 替换旧AOF文件 重启时执行命令恢复 Redis主进程 AOF Buffer AOF重写缓冲区 AOF文件 子进程
说明：AOF通过记录命令实现持久化，重写过程使用子进程和双缓冲区优化，确保一致性和效率。
图3：RDB与AOF对比
RDB 快照式 快速恢复 可能丢数据 AOF 命令追加 数据安全 恢复较慢 RDB+AOF混合 兼顾速度与安全
说明：对比三种模式的特性，帮助理解选择依据。
总结
RDB通过周期性快照实现快速恢复，但可能丢失数据；AOF通过记录命令保证数据安全，但需重写优化文件大小。两者各有适用场景，实际中可根据需求灵活组合。