Redis：RDB和AOF持久化机制

Redis持久化备份数据的方式有两种：RDB(Redis DataBase) 、 AOF(Append Only  File)。

RDB和AOF两种持久化机制的介绍

RDB：持久化机制，对Redis中的数据执行周期性的持久化，复制当时内存数据的全量快照（每隔一定时间对内存中的数据持久化到磁盘中）

AOF：持久化机制，将每条写入命令作为日志，以append-only的模式写入一个日志文件中，在Redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。

 

RDB持久化机制的优缺点

优点：

• RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。
• RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
• 相对AOF持久化机制来说，直接基于RDB数据文件来重启和恢复Redis进程，更加快速。

缺点：

• 数据完整性较差：一般来说RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦Redis进程宕机，那么会丢失最近5分钟的数据
• RDB每次在fork子进程来执行RDB快照文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。

 

AOF持久化机制的优缺点

优点：

• AOF可以更好的保护数据不丢失，一般每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒的数据。
• AOF日志文件已append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
• AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。

缺点：

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件大。
• AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成美妙fsync一次日志文件。

 

 

RDB和AOF选择的依据

• 一般来说，如果想达到足以媲美PostgreSQL的数据安全性，应该同时使用两种持久化方式。
• 有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。
• 如果可以承受输分钟内的数据丢失，可以只使用RDB持久化。