Redis持久化

两种存储方式：RDB（Redis DataBase）和AOF（Append Only File）

一、RDB（Redis DataBase）

1、RDB介绍

RDB是指在指定的时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot快照。而它要恢复的时候，是将快照文件直接读到内存中。

Redis会单独创建（Fork ）一个子进程来做持久化。这个进程会把数据写入到一个临时的文件中，等到持久化的过程全部都结束以后，再把这个临时文件替换之前已经持久化好的文件，也就是真正的持久化文件。在这个过程中，主进程不进行任何的IO操作，这样就可以确保redis持久化的性能。

如果需要恢复大量的数据，并且对数据的完整性并不敏感，那么RDB（Redis DataBase）的方式会比AOF（Append Of File）要更加高效。RDB的缺点是最后一次持久化后的数据有可能会丢失。（eg：如果redis关闭的时候，正在进行一次持久化过程。那么就可能导致此次持久化失败，最后一次持久化的数据丢失）

.rdb是一个非常紧凑的文件。

2、Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据数值都和原进程是一样的，但是是一个全新的进程，并作为原进程的子进程（类似于克隆人，而人经常认为克隆人是自己的孩子）。

3、RDB保存的是dump.rdb文件

如果使用了的FLUSHALL，SHUTDOWN等操作的时候，会立刻生成dumb.rdb文件。如果需要立即生成镜像，使用“save”命令即可。

4、配置位置

1）RDB策略

配置结构：save <秒><改变次数>

三者得其一，就会开始执行RDB操作。

 

2）dbfilename  默认rdb的名称

 

3）stop-writes-on-bgsave-error

如果在save的时候出现了错误，就要停止写入（write）工作。

如果配置成no，代表并不在乎数据不一致或者有其它的手段来发现和控制数据不一致的问题。

 

4）rdbcompression

对于存储到磁盘的快照，可以设置是否启动压缩算法。如果是的话，redis会采用LZF算法进行压缩。

如果不想消耗CPU来进行压缩，可以关闭此功能。

 

5）rdbchecksum

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会消耗大约10%的性能。如果希望性能最大化，则可以关闭这项功能。

5、如何触发RDB快照

1）按照配置文件自动触发

2）使用save命令或者bgsave命令

    save时只管进行保存，其它的全部阻塞。

   bgsave时，Redis会在后台异步执行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次执行快照执行成功的时间。

3）执行flushall命令，会产生空的dump.rdb文件，无意义。

 

6、如何恢复

1）将备份的dump.rdb文件移动到redis安装目录（或者是配置的文件移动到配置的目录）即可

2）CONFIG GET dir 获取目录

7、RDB的优势

1）适合大规模的数据恢复

2）对数据完整性和一致性要求不高

8、RDB的劣势

1）在一定时间内做一次备份，如果redis意外down掉了，就会丢失最后一次快照后的所有修改。

2）Fork的时候，内存中的数据被克隆了一份，大致两倍的膨胀性需要考虑内存空间。

9、如何停止

redis-cli config set save

二、AOF（Append Only File）

 1、简介

AOF是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（不记录读操作），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一遍，以完成数据的恢复工作。

启动redis就会生成一个.aof文件。

AOF和RDB的持久化策略可以同事解决问题。

如果AOF和RDB共同存在，则优先启动AOF文件。如果AOF文件出现错误，则redis无法启动。

2、配置文件

1）appendonly

是否开启AOF功能。默认为关闭

2）appendfilename

默认的AOF生成的文件名称

3）appendfsync

数据同步策略配置，默认everysec。

always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能比较差，但是数据的完整性比较好。

everysec：默认推荐设置，异步操作，每秒记录，如果一秒内出现宕机，则这一秒钟内的数据会丢失。

no：不开启， Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上

4）no-appendfsync-on-rewrite

重写的时候，是否可以运用Appendsyne，默认是no，保证数据安全性

5）auto-aof-rewrite-percentage/auto-aof-rewrite-min-size

当现在的aof文件比初始化这个aof文件大100%的时候，并且文件大小大于64mb，那么则触发AOF的重写机制。

 

 

4、AOF启动/修复/备份

1）正常恢复：开启AOF，讲.aof文件复制到dir下，然后重启redis。

2）异常恢复：备份被写坏的AOF文件，执行 redis-check-aof文件，加上--fix命令。然后重启redis。

 

5、rewrite重写

1）什么是重写：

    AOF采用文件追加方式，文件会越来越大。为了避免这种情况，产生了重写机制。当AOF的文件大小超过了设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。

2）重写的原理

    AOF文件持续增长而过大时，会fork出一条新的进程来将文件重写（先创建一个临时文件，再rename），遍历新进程的内存中数据，每条记录有一条set语句。然后重写aof文件的操作，并没有读取旧的aof文件。

   世纪白话：就是创建一个新的进程，把现在内存里的数据做为初始化数据，全部写成一个set的语句，生成一个新的aof文件。这个aof文件和旧文件没有任何关系。这个新的aof文件等于是把以前所有多余的新增、删除、修改全部去掉，只保留最后的结果。理论上分析旧的aof文件也可以得到这个效果，但是效率肯定不如直接从内存中读取数据高。

3）触发机制

redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M的时候触发。

 

6、优势

1）每秒同步：everysec 

2）每修改同步：always

3）不同步: no

7、劣势

1）相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。

2）AOF运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

三、如何选择

1）RDB持久化方式能够在置顶的时间间隔对数据进行快照存储。

2）AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3）只做缓存：如果只希望数据在服务器运行的时候存在，则不需要开启任何持久化方式。

4）官网建议：同时开启两种持久化方式

    在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始数据，因为在通常情况下，AOF文件要比RDB文件的完整性更好。当RDB文件不实的时候，两者同时存在的话，也只会找AOF文件。

   但是RDB更适合做数据库的备份（AOF在不断变化， 不容易备份）和快速重启，而且不会有AOF可能潜在的BUG，可以做为保险来使用。

5）性能建议：

由于在两者同时存在的情况下，RDB被用做后备，所以只保留save 900 1这一个配置即可。

如果硬盘许可，应该尽可能的减小rewrite的频率，64mb可以设置到5G以上。而100%可以根据情况适当改写。