Redis 持久化机制

Redis 是个基于内存的数据库。那服务一旦宕机，内存中数据必将全部丢失。所以丢失数据的恢复对于 Redis 是十分重要的，我们首先想到是可以从数据库中恢复，但是在由 Redis 宕机时（说明相关工作正在运行）且数据量很大情况下，从数据库恢复的话，会为数据库带来巨大的压力，进而导致程序相应缓慢。因此实现数据的持久化，避免从后端数据库中恢复数据，对于Redis 是十分必要的。

此外，Redis 可以通过创建快照来获得存储在内存里面的数据。创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用，其中 Redis 最常用的快照持久化机制分为两种，即 RDB 与 AOF。

1、Redis 持久化机制 RDB

RDB 持久化可以手动执行也可以根据配置定期执行，它的作用是将某个时间点上的数据库状态保存到 RDB 文件中，RDB 文件是一个压缩的二进制文件，通过它可以还原某个时刻数据库的状态。由于RDB文件是保存在硬盘上的，所以即使 Redis 崩溃或者退出，只要 RDB 文件存在，就可以用它来恢复还原数据库的状态。

可以通过 SAVE 或者 BGSAVE 来生成 RDB 文件：

SAVE 命令会阻塞 Redis 进程，直到 RDB 文件生成完毕，在进程阻塞期间，redis 不能处理任何命令请求，这显然是不合适的。
BGSAV E则是会 for k出一个子进程，然后由子进程去负责生成 RDB 文件，父进程还可以继续处理命令请求，不会阻塞进程。

2、Redis 持久化机制 AOF

AOF 和 RDB 不同，AOF 是通过保存 redis服务器所执行的写命令来记录数据库状态的。

AOF 通过追加、写入、同步三个步骤来实现持久化机制。

当 AOF 持久化处于激活状态，服务器执行完写命令之后，写命令将会被追加 append 到 aof_buf 缓冲区的末尾
在服务器每结束一个事件循环之前，将会调用 flushAppendOnlyFile 函数决定是否要将 aof_buf 的内容保存到AOF文件中，可以通过配置 appendfsync 来决定。
- always：aof_buf 内容写入并同步到 AOF 文件
- everysec：将 aof_buf 中内容写入到 AOF 文件，如果上次同步 AOF 文件时间距离现在超过1秒，则再次对 AOF 文件进行同步
- no：将 aof_buf 内容写入AOF文件，但是并不对 AOF 文件进行同步，同步时间由操作系统决定
如果不设置，默认选项将会是 everysec，因为 always 来说虽然最安全（只会丢失一次事件循环的写命令），但是性能较差，而 everysec 模式只不过会可能丢失1秒钟的数据，而 no 模式的效率和 everysec 相仿，但是会丢失上次同步 AOF 文件之后的所有写命令数据。

3、Redis 持久化机制 RDB 与 AOF 的区别

实现方式：RDB 持久化是通过将某个时间点 Redis 服务器存储的数据保存到 RDB 文件中来实现持久化的；AOF持久化是通过将 Redis 服务器执行的所有写命令保存到 AOF 文件中来实现持久化的；
文件体积：由上述实现方式可知，RDB 持久化记录的是结果，AOF 持久化记录的是过程，所以 AOF 持久化生成的 AOF 文件会有体积越来越大的问题，Redis 提供了 AOF 重写功能来减小 AOF 文件体积；
安全性：AOF 持久化的安全性要比 RDB 持久化的安全性高，即如果发生机器故障，AOF 持久化要比 RDB 持久化丢失的数据要少。因为 RDB 持久化会丢失上次 RDB 持久化后写入的数据，而 AOF 持久化最多丢失1s之内写入的数据（使用默认everysec 配置的话）；
优先级：由于上述的安全性问题，如果 Redis 服务器开启了 AOF 持久化功能，Redis 服务器在启动时会使用 AOF 文件来还原数据，如果 Redis 服务器没有开启 AOF 持久化功能，Redis 服务器在启动时会使用 RDB 文件来还原数据，所以 AOF 文件的优先级比 RDB 文件的优先级高。