Redis持久化

RDB

介绍

       在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里！

       Redis 会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。

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

RDB 保存的是 dump.rdb 文件

Fork

       Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

配置位置

依旧是在 redis.conf 配置文件中

save 900 1       15分钟修改1次
save 300 10		 5分钟修改10次
save 60 10000	 1分钟修改10000次

-- 如果想禁用 RDB 持久化的策略，只要不设置任何 save 指令，或者给 save 传入一个空字符串参数也可以！
save ""   或  直接不写save

PS：其实这种配置文件都比较好理解，只需要把什么的注释翻译过来就可以理解很多了！

如何触发 RDB 快照

       因为redis.conf 配置文件中已经默认设置了触发快照的时间，比如一分钟多少次、五分钟多少次等，每次到了对应的时间后就会执行对应的配置，然后自动生成一个 dump.rdb 文件用于数据备份。

在开发中为了防止数据丢失，我们一般会把自动生成的 dump 文件再次复制一份到另一台机器上，这样就更好的保证了他的数据持久性（因为有时候可能会出现物理问题，也就是机器突然坏了！）

       执行 shutdown 和 exit 后会立刻保存 dump.run 文件，所以我们如果在时间到来之前删除了所有的数据，然后执行 shutdown 和 exit 命令，那么下次获取的时候是获取不到的！

如果我们不想等到设置的时间才进行保存（比如有时候插入很重要的数据时），这个时候我们可以在插入数据之后直接执行 save 命令，这样它就可以马上修改进 dump.rdb 文件中！

Sava：save后只管保存，其它一律不管，全部阻塞。也就是说在执行完 save 后除了保存当前的数据，其它的操作都不会在生效了！

BGSAVE：Redis 会在后台异步进行快照操作，快照的同时还可以响应客户端请求。可以通过 lastsave 命令获取到最后一次成功执行快照的时间。也就是说，在保存的时候我们还是可以执行其他操作的！

如何恢复

       我们在如何触发 RDB 快照的时候说过了，我们会手动复制一份 rdb 文件到其他的机器上，所以我们在机器坏了或系统崩了的情况下丢失的数据可以直接把复制的那一份文件拿回来进行使用！

优势 & 劣势

优势

① 适合大规模的数据恢复。

② 对数据完整性和一致性要求不高。

劣势

① 在一定间隔时间做一次备份，所以如果 redis 意外挂掉的话，就会丢失最后一次快照后的所有修改。

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

如何停止

动态所有停止 RDB 保存规则的方法：

redis-cli config set save ""

小总结

AOF

介绍

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

AOF 保存的是 appendonly.aof 文件

配置位置

依旧是在 redis.conf 配置文件中

如果一个 redis 使用了两种持久化方式，那么就会形成互补的关系。

AOF 启动 & 修复 & 恢复

启动

       Redis 中默认使用的是 RDB 的方式来进行数据备份的，所以我们如果要使用 AOF 的话就需要将配置文件中的 appendonly 修改为 yes！

最好也复制一份到另外一台机器上，保证数据的完整性和安全性！

修复

使用以下命令进行修复

redis-check-aof --fix

恢复

重启 Redis 后重新加载！

以上操作分为正常和异常

注意：appendonly.aof 文件自动生成后，不要去手动修改它里面的内容！一旦没有按照格式编写会导致无法连接到 redis 服务器，所以我们一般都不会去手动修改这个文件！！！！

Rewrite

介绍

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

重写原理

       AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写（也是先写临时文件最后再 rename），遍历新进程的内存中数据，每条记录有一条的 Set 语句。重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。

触发机制

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

优势 & 劣势

优势

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

② 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失

③ 不同步：appendfsync no 从不同步

劣势

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

② aof 运行效率要慢于 rdb,每秒同步策略效率较好，不同步效率和 rdb 相同

小总结

RDB 与 AOF 总结

1. RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

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

3. 只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

4. 同时开启两种持久化方式

   ① 在这种情况下，当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。

   ② RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件。那要不要只使用 AOF 呢？
   作者建议不要，因为 RDB 更适合用于备份数据库( AOF 在不断变化不好备份)，快速重启，而且不会有 AOF 可能潜在的 bug，留着作为一个万一的手段。

性能建议

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

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

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

新浪微博就选用了这种架构！