Redis的持久化之RDB和AOF_redis 开启 rdb持久化

来源于：尚硅谷谷周阳

RDB

概念

在指定的时间间隔内将内存中的数据集快照写入磁盘文件，保存到dump.rdb文件。

行话：进行Snapshot快照。
恢复时是将快照文件读到内存里。

原理

Redis会单独创建（fork）一个子线程来进行持久化，会先将数据写入到一个临时文件中，待持久化进程都结束了，再用这个文件替换上次持久化好的文件。整个进程中主进程是不进行IO操作的，这就确保了极高的性能。

何时触发RDB

1、手动触发

• save命令：阻塞当前Redis服务器，直到RDB完成。
• bgsave命令：执行fork操作创建子进程来进行RDB持久化，阻塞只发生在fork阶段，一般时间很短。进行RDB过程中Redis还可以响应客户端请求

2、达到配置文件中的条件（save相关配置）

设置触发RDB的条件：指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
  save <seconds> <changes>
  Redis默认配置文件中提供了三个条件：
  
  save 900 1
  save 300 10
  save 60 10000
  
900s内有一次改变
300s内有10次改变
60s内有10000次改变
以上三个条件满足任一就可触发RDB
1
2
3
4
5
6
7
8
9
10
11
12

3、从节点从主节点执行全量复制操作

两个命令：SAVE命令会阻塞主进程来完成写文件，BGSAVE命令会创建子进程来完成写文件，主进程会继续处理命令。

如何知晓最后一次成功执行的快照

通过lastsave命令

如何恢复RDB

将备份文件（dump.rdb）移动到redis安装目录并启动服务即可

优势

RDB方式要比AOF方式更加高效，适合大规模数据恢复，对数据完整性和一致性要求不高

劣势

RDB的缺点是最后一次持久化后的数据可能丢失。

1、在一定间隔时间左一次备份，如果Redis意外duwn掉的化会丢失最后一次快照之后的修改。
2、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

如何停止

动态停止所有RDB保存规则的方法：
redis-cli config set save “”

AOF

概念和原理

以日志的形式来记录每个写操作，将 Redis执行过的所有写指令记录下来（读操作不记录），只允许追加文件，不允许更改文件，AOF和RDB可以同时存在。如果AOF开启，Redis启动之初会读取该文件重新构建数据，即Redia重启的话就根据文件的内容将写指令从前到后执行一次来完成数据的恢复工作。

AOF保存的是appendonly.aof文件。

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
1
2
3

如果aof文件内有错误的，识别不了的数据，则redis启动不了，此时可以使用

redis-check-aof --fix appendonly.aof
1

如下：

dump文件同理

如何恢复

何时触发AOF

根据设置的同步机制触发。
appendfsync always 同步持久化，每次发生数据变更立即记录到磁盘文件
appendfsync everysec 每秒 异步操作（出厂默认），每秒记录
appendfsync no 从不

aof文件的重写（rewrite）

AOF采取文件追加的方式，文件会越来越大，为避免这种情况，aof文件会进行重写。
当aof文件的大小超过设置的阈值时，redis就会启动aof文件的内容压缩。只保留客回复数据的最小指令集，可使用指令bgrewriteaof
重写的原理：
触发重写时，会fork出一条新的进程来将文件重写（也是先写临时文件，在rename），遍历新进程内存中的数据，每每条记录有一个set语句。重写aof文件的操作并没有读取旧的aof文件，而将整个内存中的数据用命令的方式重写了一个新的aof文件，这点和快照有点类似。

优势

主要解决宕机时RDB丢失最后一次快照的问题。
根据记录写日志的频率不同，优缺点也不同
appendfsync always 同步持久化，每次发生数据变更立即记录到磁盘文件，性能较差但数据完整性好
appendfsync everysec 每秒 异步操作（出厂默认），每秒记录，如果宕机有1秒的数据丢失
appendfsync no 从不

劣势

1、对相同的数据集来说aof文件的大小通常要大于RDB文件的大小
2、aof的运行效率要慢于RDB，每秒同步策略同步效果较好。

同时开启两种持久化方式

AOF持久化开启且存在AOF文件时，优先加载AOF文件来恢复数据。

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

相关配置：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-percentage 100 设置重写的基准值
auto-aof-rewrite-min-size 64mb 设置重写的基准值
redis会记录上次重写的aof文件的大小，默认配置是当aof文件大小是上次重写后大小的一倍，且文件大于64M时触发。

如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构