7.持久化

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

RDB（Redis Database）

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

Redis会单独创建（fork）一个子线程来进行持久化，会先将数据写到一个临时文件中，待持久化过程结束，在用这个临时文件替换上次持久化的文件。

整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化的文件可能会消失。

RDB保存的文件是dump.rdb 都是在配置文件中快照中进行配置的

触发机制

• sava的规则满足的情况下，会自动触发

  save 900 1		#在九百秒内执行了1次，会触发
  save 300 10		#在三百秒内执行了10次，会触发
  save 60 10000	#在六十秒内执行了10000次，会触发
  

• 执行flushall命令，会触发RDB规则

• 退出redis，也会产生RDB文件

恢复RDB文件

• 只需要将RDB文件放在redis启动目录即可，redis在启动时会自动检查dump.rdb并将其恢复

• 查看需要存在的位置，并放入其中

  config get dir
  

优点

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

缺点

• 需要一定的时间间隔进程操作！如果redis意外宕机了，这个最后一次修改的数据就没有了
• fork进程的时候，会占用一定的内存空间！

AOF

Append Only File持久化，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

默认是不开启的

如果aof文件有错误的，redis是无法启动的，redis提供了一个修复工具 redis-check-aof --fix appendonly.aof 可进行修复

优点：

• 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
• 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
• AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点：

• AOF 文件比 RDB 文件大，且恢复速度慢。
• 数据集大的时候，比 rdb 启动效率低。

两种方式的对比

• AOF文件比RDB更新频率高，优先使用AOF还原数据。
• AOF比RDB更安全也更大
• RDB性能比AOF好
• 如果两个都配了优先加载AOF