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,开销大的问题。