0%

记录redis的RDB、AOF持久化

发表于 2017-05-08 更新于 2020-05-18 分类于 redis

Redis是个支持持久化的内存数据库，redis需要经常将内存中的数据同步到磁盘来保证持久化。

快照（Snapshotting）默认持久化方式

配置

snapshotting：       
save 900 1          #900秒内如果超过1个key被修改，则发起快照保存
save 300 10         #300秒内如果超过10个key被修改，则发起快照保存
save 60 10000

工作原理

Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

　　

优点

RDB是个非常紧凑的文件，保存了redis在某个时间点上的数据集，使得我们可以通过定时备份RDB文件来实现Redis数据库备份和灾难恢复，也可以将其传送到其他的数据中心用于保存。
RDB可以最大化redis的性能，执行RDB持久化时只需要fork一个子进程，并由子进程进行持久化工作，父进程不需要处理任何磁盘I/O操作。
RDB在恢复大数据集时比AOF要快，启动效率要高许多。
RDB文件是经过压缩（可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

缺点

每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。
快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，有一些数据丢失的风险。
client的save通知redis做一次快照持久化不推荐。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有client的请求，这种方式会阻塞所有client请求，所以不推荐使用。

日志追加方式（append-only file）方式

配置

aof：
appendonly yes         #启动aof持久化方式有三种修改方式
#appendfsync always    #收到写命令就立即写入到硬盘，效率最慢，但是保证完全持久化
#appendfsync everysec  #每秒种就写入一次硬盘，在性能和持久化方面做了折中
#appendfsync no        #完全依赖操作系统，性能最好，但是持久化没保证，不知道何时持久化

工作原理

redis调用fork ，现在有父子两个进程
子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

优点

该机制可以带来更高的数据安全性，即数据持久性。
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数据的重建。

缺点

对于相同数量的数据集而言，AOF文件通常要大于RDB文件，持久化文件会变的越来越大。
根据同步策略的不同，AOF在运行效率上往往会慢于RDB。