(Redis设计与实现-4) 持久化

一.RDB

RDB(Redis DataBase)，也常叫作snapshots：是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。 snapshot首先将数据写入临时文件，当成功结束后，将临时文件重名为dump.rdb。

//使用配置文件进行持久化
save 900 1 #900秒内若是超过1个key被修改，则发起快照保存
save 300 10 #300秒内若是超过10个key被修改，则发起快照保存


//使用命令进行持久化
redis-cli -h ip -p port save #用主线程进行持久化，这种方式会阻塞全部client请求
redis-cli -h ip -p port bgsave #另外开启一条子线程进行持久化

二.AOF

AOF(Append-only file):将“操做 + 数据”以格式化指令的方式追加到操做日志文件的尾部，在append操做返回后(已经写入到文件或者即将写入)，才进行实际的数据变动，“日志文件”保存了历史全部的操做过程；当server须要数据恢复时，能够直接replay此日志文件，便可还原全部的操做过程。

(1).同步写入

AOF是文件操做，对于变动操做比较密集的server，那么必将形成磁盘IO的负荷加剧；此外redis提供了3中aof记录同步选项（appendfsync）：

always：每一条aof记录都当即同步到文件，这是最安全的方式，也觉得更多的磁盘操做和阻塞延迟，是IO开支较大。
everysec：每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。若是遇到物理服务器故障，有可能
致使最近一秒内aof记录丢失(可能为部分丢失)。
no：redis并不直接调用文件同步，而是交给操做系统来处理，操做系统能够根据buffer填充状况/通道空闲时间等择机
触发同步；这是一种普通的文件操做方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。

(2).压缩AOF日志文件

AOF文件会不断增大，它的大小直接影响“故障恢复”的时间,并且AOF文件中历史操做是能够丢弃的。AOF rewrite操做就是“压缩”AOF文件的过程，固然redis并无采用“基于原aof文件”来重写的方式，而是采起了相似snapshot的方式：基于copy-on-write，全量遍历内存中数据，而后逐个序列到aof文件中。

//使用配置文件进行持久化
no-appendfsync-on-rewrite no  #在aof-rewrite期间，appendfsync是否暂缓文件同步
auto-aof-rewrite-min-size 64mb  #aof文件rewrite触发的最小文件尺寸(mb,gb)
auto-aof-rewrite-percentage 100  #相对于“上一次”rewrite，本次rewrite触发时aof文件应该增加的百分比。 


//使用命令进行持久化
redis-cli -h ip -p port bgrewriteaof #开启一个子进程来完成rewrite