Redis RDB & AOF 两种持久方案的优缺点

Redis RDB & AOF 两种持久方案的优缺点

引用

CSDN

1.

https://blog.csdn.net/zfj321/article/details/145666898

Redis提供了两种主要的数据持久化方案：RDB（Redis Database Backup）和AOF（Append Only File）。这两种方案各有优劣，适用于不同的使用场景。本文将详细对比这两种持久化方式的特点，帮助你更好地选择和使用Redis的持久化功能。

RDB优点

• RDB是一个非常紧凑的单文件快照，可以很好地表示Redis数据在某一时间点的状态。RDB文件非常适合用于备份。例如，你可以每小时归档最新的24个RDB文件，每天保存一个RDB快照持续30天。这允许你在灾难发生时轻松恢复不同版本的数据集。
• RDB非常适合灾难恢复，因为它是一个单一的紧凑文件，可以轻松传输到远程数据中心，或存储到Amazon S3（甚至加密）。
• RDB最大限度地提高了Redis的性能，因为Redis主进程只需要fork一个子进程来完成持久化工作。主进程不会执行任何磁盘I/O操作。
• RDB允许更快地重启大数据集，相比AOF而言。
• 在副本中，RDB支持在重启和故障转移后的部分重新同步。

RDB缺点

• 如果你需要最小化Redis停止工作时的数据丢失风险（例如在电源故障后），RDB可能不是最佳选择。你可以配置不同的保存点来生成RDB（例如，在至少5分钟和100次写入数据集后）。但是你通常会每5分钟或更长时间创建一个RDB快照，因此如果Redis因任何原因未能正确关闭，你应该准备好丢失最近几分钟的数据。
• RDB需要频繁fork()以在子进程中将数据持久化到磁盘。对于大数据集来说，fork()可能需要较长时间，可能会导致Redis在几毫秒甚至一秒内停止服务。AOF也需要fork()，但频率更低，你可以调整日志重写频率而不会影响持久性。

AOF优点

• 使用AOF，Redis的持久性更好：你可以有不同的fsync策略：不fsync、每秒fsync、每次查询fsync。即使使用默认的每秒fsync策略，写入性能仍然很高。fsync使用后台线程执行，主线程会在没有fsync进行时尽力执行写入，因此你最多只能丢失一秒钟的写入数据。
• AOF日志是一个追加日志，没有寻址问题，也没有断电导致的损坏风险。即使日志以未完成的命令结束（例如由于磁盘满或其他原因），redis-check-aof工具也能轻松修复。
• Redis能够自动在后台重写AOF文件，当文件变得太大时。重写是完全安全的，因为Redis继续向旧文件追加，同时创建一个新的完全包含当前数据集所需的最小操作集的文件，一旦新文件准备就绪，Redis切换两个文件并开始向新的文件追加。
• AOF包含一个易于理解和解析的格式的日志，所有操作一个接一个。你可以很容易地导出AOF文件。例如，即使你不小心使用FLUSHALL命令清除了所有数据，只要在重写日志之前，你仍然可以通过停止服务器，删除最后一条命令，然后重新启动Redis来保存你的数据集。

AOF缺点

• AOF文件通常比相同数据集的RDB文件大。
• 根据fsync策略，AOF可能比RDB慢。一般来说，将fsync设置为每秒，性能仍然很高，关闭fsync时，即使在高负载下也与RDB一样快。但是RDB能够提供更高的写入负载下的最大延迟保证。

版本差异（Redis <7.0）

• AOF在重写期间写入数据库可能会使用大量内存（这些写入操作会被缓冲在内存中，并在重写结束时写入新AOF）。
• 所有在重写期间写入的命令都会被写入磁盘两次。
• Redis可能在重写结束时冻结写入和fsync新AOF文件。

适用场景

• RDB适用场景：需要高性能、快速重启、大数据集备份的场景；对数据丢失容忍度较高的场景。
• AOF适用场景：对数据完整性要求高，可容忍稍大文件体积和略低性能的场景。

持久化策略选择

• RDB与AOF可以互补使用：RDB用于基础备份，AOF确保增量数据安全。
• 根据数据容忍度（丢失时间窗口）和性能需求权衡选择。

运维建议

• 监控fork()延迟（尤其大数据集场景）。
• AOF重写期间关注内存与磁盘负载，Redis 7.0+优化了相关性能问题。