redis 持久化

rdb和aof持久化策略可以共存

推荐两种持久化策略都用

redis优先载入aof文件恢复数据

1. rdb (redis database)

快照记录，全量。

节省磁盘空间，恢复速度快。存储间隔粒度大，丢失数据概率大。

1.1

时间段中内存中的数据写入磁盘。快照存储。

fork一个子进程，做持久化。写入/读取临时文件。主进程不进行IO操作。

适合大规模数据恢复，数据恢复完整性差。

RDB文件用于保存和还原Redis服务器所有数据库中的所有键值对数据。对于不同类型的键值对， RDB文件会使用不同的方式来保存它们。RDB文件是一个经过压缩的二进制文件， 由多个部分组成。
 

1.2 RDB文件的创建与载入：

创建RDB文件：有两个Redis命令可以用于生成RDB文件， 一个是SAVE， 另一个是BGSAVE。
SAVE （阻塞） 命令会阻塞Redis服务器进程， 直到RDB文件创建完毕为止，在服务器进程阻塞期间， 服务器不能处理任何命令请求：

redis> SAVE //
等待直到RDB
文件创建完毕
O

BGSAVE （非阻塞）命令会派生出一个子进程， 然后由子进程负责创建RDB文件， 服务器进程（父进程） 继续处理命令请求：

redis> BGSAVE //
派生子进程， 并由子进程创建RDB
文件
Background saving started

载入RDB文件：由rdb.c/rdbLoad函数完成， 这个函数和rdbSave函数之间的关系可用下图表示。
 

 

1.3 RDB文件结构：

1.4 总结

2. aof (append only file)

日志记录，增量。

存储粒度更细，丢失数据概率更低。可读的日志文本。

占用更多磁盘空间，恢复速度慢（因为记录每次写操作，接着要执行），每次读写都同步的话有性能压力，有bug

2.1

以日志形式记录每个写操作，只许追加文件。恢复时根据日志文件将指令执行一次。

与RDB持久化通过保存数据库中的键值对来记录数据库状态不同， AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的， 如下图所示。

RDB持久化保存数据库状态的方法是将msg、 fruits、 numbers三个键的键值对保存到RDB文件中， 而AOF持久化保存数据库状态的方法则是将服务器执行的SET、 SADD、 RPUSH三个命令保存到AOF文件中。

redis对aof文件重写，64m，不至于太大。aof保存的数据更完整。最差丢失2s数据。

频繁IO，rewrite。值得一提的是， 因为AOF文件的更新频率通常比RDB文件的更新频率高， 所以：如果服务器开启了AOF持久化功能， 那么服务器会优先使用AOF文件来还原数据库状态。·只有在AOF持久化功能处于关闭状态时， 服务器才会使用RDB文件来还原数据库状态。

2.2 AOF持久化的实现：AOF持久化功能的实现可以分为命令追加（append） 、 文件写入、
文件同步（sync） 三个步骤。
2.2.1 命令追加: 追加到aof_buf缓冲区的末尾

2.2.2 AOF文件的写入与同步

AOF持久化的效率和安全性

服务器配置appendfsync选项的值直接决定AOF持久化功能的效率和安全性。

·当appendfsync的值为always时， 服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件， 并且同步AOF文件，所以always的效率是appendfsync选项三个值当中最慢的一个， 但从安全性来说， always也是最安全的， 因为即使出现故障停机， AOF持久化也只会丢失一个事件循环中所产生的命令数据。

·当appendfsync的值为everysec时， 服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件， 并且每隔一秒就要在子线程中对AOF文件进行一次同步。 从效率上来讲， everysec模式足够快， 并且就算出现故障停机， 数据库也只丢失一秒钟的命令数据。

·当appendfsync的值为no时， 服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件， 至于何时对AOF文件进行同步， 则由操作系统控制。 因为处于no模式下的flushAppendOnlyFile调用无须执行同步操作， 所以该模式下的AOF文件写入速度总是最快的， 不过因为这种模式会在系统缓存中积累一段时间的写入数据， 所以该模式的单次同步时长通常是三种模式中时间最长的。 从平摊操作的角度来看， no模式和everysec模式的效率类似， 当出现故障停机时， 使用no模式的服务器将丢失上次同步AOF文件之后的所有写命令数据。

2.3 AOF文件的载入与数据还原

 AOF重写：

为了解决AOF文件体积膨胀的问题， Redis提供了AOF文件重写（rewrite） 功能。 通过该功能， Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件， 新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令， 所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。
AOF重写是一个有歧义的名字， 该功能是通过读取数据库中的键值对来实现的， 程序无须对现有AOF文件进行任何读入、 分析或者写入操作。合并多个数据库操作。
2.5 总结

3. Master-Slave Replicate

解决aof频繁的IO，开销大的问题。