配置文件

  1. save 900 1  # 900 秒内有 1 个key 变化,则存入 RDB 文件
  2. save 300 10
  3. save 60 10000
  5. dbfilename dump.rdb #配置数据文件名称 
  6. dir ./  配置数据文件存放目录

RDB快照形式 （默认)

Redis运行在内存中但是周期性全量持久化到RDB二进制文件中(RDB)

优点：RDB文件紧凑，体积小，网络传输快，适合全量持久化；恢复速度比AOF快很多。与AOF相比RDB最重要的优点之一是对性能的影响相对较小。

缺点：RDB文件数据快照的会造成数据丢失，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

1. save触发方式

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
语法：
redis localhost:6379> save
该命令将在 redis 安装目录中创建 dump.rdb 文件.

2. bgsave触发方式

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
实例
redis localhost:6379> BGSAVE
Background saving started

只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
image.png

  1. Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；(阻塞)

在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

  1. 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
  2. 当子进程写入完所有数据后会用该临时文件(二进制压缩存储)替换旧的RDB文件，至此一次快照操作完成。

3. 自动触发

自动触发是由我们的配置文件来完成的。

AOF持久化 (默认关闭)

aof做增量持久化，存储的是文本协议数据。
image.png
与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好
缺点 是文件大、恢复速度慢, AOF 开启后对性能影响大。

持久化方式配置:
(1)appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用(2)appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐(3)appendfsync no //完全依赖os，性能最好,持久化没保证
appendfsync no:这种模式下,Redis 被关闭、AOF 功能被关闭、系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行） 这三种情况下的SAVE 操作都会引起Redis 主进程阻塞。
appendfsync everysec:在这种模式中，SAVE 原则上每隔一秒钟就会执行一次，因为SAVE 操作是由后台子线程调用的，所以它不会引起服务器主进程阻塞。
appendfsync always:在这种模式下，每次执行完一个命令之后，写磁盘操作都会被执行，同时主进程会被阻塞，不能接受客户端命令请求。

  1. appendonly  yes               #开启AOF持久化功能；
  2. appendfilename appendonly.aof #AOF持久化保存文件名；
  4. appendfsync always      #每次执行写入都会执行同步，最安全也最慢；
  5. #appendfsync everysec   #每秒执行一次同步操作；(默认)
  6. #appendfsync no         #不主动进行同步操作，而是完全交由操作系统来做，每30秒一次，最快也最不安全；
  8. # 自动重写是Redis会记录上次重写的大小，
  9. 若当前文件的大小超过原来文件的一定比例，将进行自动重写；
  10. 以示例说明：基础重写大小是64m，若当前aof文件大小是64m的2倍，将自动进行aof的重写。
  11. # 自动重写比例设置
  12. auto-aof-rewrite-percentage 100
  13. # 自动重写最小大小
  14. auto-aof-rewrite-min-size 64mb

如果再问aof文件过大恢复时间过长怎么办？
你告诉面试官，Redis会定期做aof重写，压缩aof文件日志大小。

△ 混合持久化

aof-use-rdb-preamble 配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。
混合持久化是Redis 4.X之后的一个新特性，
说是新特性其实更像是一种RDB&AOF的结合，持久化文件变成了RDB + AOF，首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份。这样就充分了利用了RDB 加载快，备份文件小等特点，也利用了AOF能尽可能不丢数据这个特性（进一步保证了数据一致性），当然了基本上丢失了AOF的可读性。加载过程就是按部分进行加载的，先按照RDB进行加载，然后把AOF命令追加写入就好了。在大多数场景下RDB + AOF的混合持久化模式其实还是很合适的。

如果对方追问那如果突然机器掉电会怎样？
取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

宕机重启先读取 AOF 文件,后读取 RDB。

Redis数据恢复

恢复

如果需要恢复数据，只需要将备份文件(dump.rdb)移动到 redis 安装目录并启动服
务即可。获取 redis 目录可以使用 config 命令。如下所示：
127.0.0.1:6379> config get dir
1) “dir”
2) “/opt/redis-3.2.0”

参考链接:
作者：爪哇部落格 链接：https://www.jianshu.com/p/cc5ac7d3a2b0
原文链接：https://blog.csdn.net/weixin_36691991/article/details/88736669
https://www.cnblogs.com/rayong/p/6791330.html