常见面试问题
- redis有哪几种持久化机制？
- rdb和aof的区别？
- 持久化机制底层原理是怎么样的？
持久化的意义
我们都知道redis是基于内存存储的，那如果redis挂了再重启那内存里面的数据就全丢了，那这个时候我们就需要通过redis的持久化将数据同步到磁盘上，那么就可以保证数据不会全部丢失。所以它的意义主要在于故障恢复。
RDB
RDB(快照):rdb它是保存某个时间点的全量数据快照，其实就是周期性的持久化redis中的数据。
save 900 1 （代表900秒有一次写请求就执行一次快照）
save 300 10 （代表300秒有10次写请求就执行一次快照）
save 60 10000 （代表900秒有60次写请求就执行一次快照）
stop-writes-on-bgsave-error yes（当备份进程出错时主进程就停止接受写操作，为了保证持久化数据一致性的问题）
当我们配置 sava "" 就可以禁用rdb。
手动执行rdb快照可以通过下面两个命令：
-
SAVE:阻塞redis服务器进程，直到rdb文件创建完毕。
-
BGSAVE:fork出一个子进程来创建rdb文件，不会阻塞服务器主进程。
自动触发rdb持久化的方式有如下几个情况：
- 执行shutdown并且没有开启aof持久化
- 执行debug reload
- 主从复制时，主节点自动触发
- 根据配置文件配置的save a b 定时触发（这里save指bgsave）
AOF
AOF(APPEND-ONLY-FILE):aof它是保存写状态，记录下除了查询以外的所有变更指令，AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。
appendfsync always （一旦缓存发生变化就aof）
appendfsync everysec（默认使用这种方式，每秒进行一次aof，推荐使用这个）
appendfsync no（交给操作系统）
RDB和AOF的优缺点
rdb优点（适合冷备份）
- RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备份，可以将这种完整的数据文件发送到一些远程的安全存储上去。（当然aof也可以做冷备份，但是只有一个文件，需要每隔一段时间去copy这个文件）
- 对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。
- RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。（RDB每次写都是直接写内存,一定时候才写磁盘，AOF每次都是写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销的,速度会比RDB慢一些）
rdb缺点
- 内存数据全量同步，数据大的时候会由于I/O影响性能，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
- 当redis挂掉会丢失当前时间至上一次快照的所有数据，这也是rdb最大的缺点。
aof优点
- AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
- AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。
aof缺点
- 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大，恢复时间长。
- AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件。
redis数据的恢复
RDB-AOF混合持久化方式
RDB-AOF混合持久化方式是redis4.0之后提供的新特性，它的优点显而易见，使用BGSAVE做镜像全量持久化，aof做增量持久化，所以一般实际应用中也是建议使用 RDB-AOF混合持久化方式。
