Redis 的持久化（RDB、AOF）

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能！

一、RDB（Redis DataBase）

什么是RDB？RDB是在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

1、配置位置及SNAPSHOTTING解析

# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
save 900 1
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
save 300 10
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 60 10000
stop-writes-on-bgsave-error yes # 持久化出现错误后，是否依然进行继续进行工作
rdbcompression yes         # 使用压缩rdb文件 yes：压缩，但是需要一些cpu的消耗。no：不压缩，需要更多的磁盘空间
rdbchecksum yes         # 是否校验rdb文件，更有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗
dbfilename dump.rdb     # dbfilenamerdb文件名称
dir ./                     # dir 数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录

如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。若要修改完毕需要立马生效，可以手动使用 save 命令！立马生效 !

2、触发RDB快照条件

1. 配置文件中默认的快照配置，建议多用一台机子作为备份，复制一份 dump.rdb

2. 运行命令 save 或 bgsave

   • save：只管保存，其他不管，全部阻塞。
   • bgsave：Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

3. 执行flushall命令，也会产生 dump.rdb 文件，但里面是空的，无意义 !

4. 退出的时候也会产生 dump.rdb 文件！

3、如何恢复快照

1. 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
2. CONFIG GET dir 获取目录

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"
127.0.0.1:6379>

4、RDB 持久化方式的优点和缺点

优点：

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高

缺点：

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

二、AOF（Append Only File）

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

1、配置位置及APPEND ONLY MODE解析

参数详解：

• appendonly： 默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失。Append Only File 是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据的命令都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里。默认值为no。

• appendfilename ： appendfilename AOF 文件名称

• appendfsync everysec： appendfsync aof持久化策略的配置。

    1. no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
    2. always表示每次写入都执行fsync，以保证数据同步到磁盘。
    3. everysec表示每秒执行一次fsync，可能会导致丢失这1s数据(默认)。
  

• no-appendfsync-on-rewrite： 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。

• auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

• auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

• aof-load-truncated：aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。

2、AOF 启动/修复/恢复

正常恢复：

1. 启动：设置Yes，修改默认的appendonly no，改为yes
2. 将有数据的aof文件复制一份保存到对应目录（config get dir）
3. 恢复：重启redis然后重新加载

异常恢复：

1. 启动：设置Yes
2. appendonly.aof 文件损坏！
3. 修复： redis-check-aof —fix appendonly.aof 进行修复
4. 恢复：重启 redis 然后重新加载

3、AOF持久化方式的优点和缺点

优点：

1. 每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
2. 每秒同步： appendfsync everysec 异步操作，每秒记录 ，如果一秒内宕机，有数据丢失
3. 不同步： appendfsync no 从不同步

缺点：

1. 相同数据集的数据而言，aof 文件要远大于 rdb文件，恢复速度慢于 rdb。
2. Aof 运行效率要慢于 rdb，每秒同步策略效率较好，不同步效率和rdb相同。

三、总结

• RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
• AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加 保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

• 同时开启两种持久化方式：

  • 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
  • RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

• 性能建议：

  • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
  • 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
  • 如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时宕掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。