1. Redis 持久化

 
Redis 持久化官方解释 : Redis persistence | Redis

 
简单来说 持久化技术 就是 将 内存中的数据写入硬盘中 .

 
关于 Redis 持久化 主要使用到两种手段

1. RDB
2. AOF

 
注: 这两种方法是可以混合使用的.

 
图 : 对两种方法的简单理解

 

2. RDB

 

 

光看文字可能还是 很糊涂， 下面通过 代码案例来 彻底了解他 .

 

代码演示:

 

关于 RDB 的操作 有 两种

1. 自动触发
2. 手动触发

 
这里先来看自动触发

 

2.1 自动触发

 
图一 : 修改配置文件

 
图二 :

 
图三 :

 
图四 :

 
图五 :

 

2.2 手动触发

 
当前我们是 5 秒钟 2 次修改 就 自动触发 去生成 dump.rdb 文件 这里数据备份是非常频繁的 ， 在实际生产中 不可能是这样的， 假设 10 分钟 100次 ， 突然有一个 数据非常重要 ， 但是还没有到 100 次 修改 ， 想要立刻的备份 就可以 手动触发 ，让他生成 一份 dump.rdb 文件.

 
关于手动触发涉及到两个命令 :

1. save
2. bgase

 
关于 save 和 bgase 操作 ， 相当于 多开了一个子进程 去完成 dump6379的书写.

 
关于 save 和 bgsave 就是开启一个子进程 去完成备份 ，那么请问这里 为啥 会 出现两个 命令 ?

 
关于 save 和 bgsave 的区别 :

 
在生产中 只允许 使用 bgsave 不允许使用 save ，因为 使用 save 的时候 在主程序 执行 会阻塞 当前 redis 服务器 ，直到 持久化 工作完成执行 save 命令期间 ，Redis 不会处理其他命令 ， 线上禁止使用

 
save 案例

 
bgsave

 
Redis 会在后台异步进行快照操作 ， 不阻塞 快照同时还可以响应客户端请求 ， 该触发方式会 fork 一个子进程 有子进程复制持久化过程.

 
Redis 使用 bgsave 对当前内存中的所有数据做快照 ， 这个操作是子进程在后台完成的 ，这就允许主进程同时可以修改数据.

 
演示 :

 
补充 : 这里我们可以通过 lastsave 命令 获取最后一次成功执行 快照的时间

 
演示 :

 

2.3 RDB 优点

 

 

2.4 RDB 缺点

 

 

2.5 RDB 文件修复

 

 

2.6 总结

 

那些方式会触发 RDB 快照

1. 配置文件中默认的快照配置 (满足就触发)
2. 手动 执行 save / bgsave 命令
3. 执行 flushall / flushdb 命令 也会产生 dump.rdb 文件 ,但是里面是空的无意义
4. 执行 shutdown 且没有设置开启 AOF 持久化
5. 主从复制时 ， 主节点自动触发

 
注意 : 关于 第 5 点 ，在说到 主从复制时 会说到.

 
如果禁用 快照

1. 动态所有停止 RDB 保存规则的方法 : redis-cli config set save “”

2. 配置文件快照禁用 :

RDB 优化配置项

 
小总结 :

 

3. AOF

 

 

3.1 AOF持久化工作流程

 

 

3.2 AOF 缓冲区三种写回策略

 

三种写回策略 :

1. Always : 同步写回 , 每个写命令执行完立刻同步地将日志写回到磁盘
2. everysec ： 每秒写回 , 每个写命令执行完，只是先把日志写道 AOF 文件的内存缓冲区 ， 每个 1 秒把缓冲区的内容写入磁盘
3. no : 操作系统控制的协会，每个协会命令执行完 ，只是先把日志写道 AOF 的内存缓冲区， 由操作系统决定何时将缓冲区内容写回磁盘.

 
关于这三种写回策略 :

 
关于 AOF 的一些配置项

 
图一 :

 
图二 :

 
图三 :

 
注意 : 这里 dir 路径设置有误需要改为 dir /myredis/

 
上面这些配置项 看完 接下来就来看代码案例 :

 
正常数据恢复

 
图一 :

 
图二 :

 
图三 :

 
异常恢复

 
图一 :

 
图二 ：

 

3.3 AOF 优点

 

 
关于 AOF 的优点 简单一句话 : 更好的保护数据不丢失 ， 性能高，可做紧急恢复.

 

3.4 AOF 缺点

 

 

3.5 AOF 重写机制

 
AOF 重写机制是什么 ?

 
由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，

文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

 
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，

只保留可以恢复数据的最小指令集 或者 可以手动使用命令 bgrewriteaof 来触发。

 

一句话 : 启动 AOF 文件的 内容压缩 ，只保留可以恢复数据的最小指令集

 

关于 AOF 的 重写触发机制 :

 

关于 AOF 的重写触发机制有两种 :

1. 自动触发
2. 手动触发

 
图一 :

 
图二 :

 
手动触发 :

 

3.6 AOF 重写原理

 

1: 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
 
2: 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，
 
避免在重写过程中出现意外。
 
3: 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
 
4: 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
 
5: 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

 

3.7 总结

 
AOF 优化配置项 ： 配置文件 APPEND ONLY MODE 模块

 
小总结 :

 

4. 混合持久化

 
配置文件 :

 
通过配置文件 我们可以知道 RDB 和 AOF 是可以同时存在的 ，当 RDB 和 AOF 同时存在时 ，会优先加载 AOF 文件 .

 
面试题 : 数据恢复和加载流程

 
在同时开启 rdb 和 aof 持久化时 ，重启时只会加载 aof 文件 ，并不会加载 rdb 文件.

 
提问 ： 关于 RDB 和 AOF 两种持久化方式 你觉得用那个 ?

 
这里先来看看 RDB 和 AOF 的特征 :

1. RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储
2. AOF持久记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以 redis 协议追加保存每次写的操作到文件末尾.

 
在 RDB 和 AOF 都存在的情况下 ，当 redis 重启的时候 ，会优先载入 AOF 文件来恢复原始数据 , 因为 在通常情况下 AOF 文件保存的数据集 要比 RDB 文件保存

的数据集要完整 .

 
RDB的数据不实时 ， 同时两者服务器重启也只会找 AOF 文件 ，那要不只是用AOF 呢？
 
作者建议不要 (redis 作者) , 因为 DB 更适合用于备份数据库 (AOF 在不断变化不好备份) , 留这 RDB 作为一个万一的手段 .

 
所以 ： 这里推荐使用 RDB 和 AOF 的混合方式.

 
关于 RDB 和 AOF 混合方式的优点 : 既能快速加载又能避免丢失过多的数据.

 
这两种方式混合就有点像 ：鸳鸯锅

 
下面我们就来配置文件中开启混合 :

 

5. 纯缓存模式

 
redis 是一个 基于 key-value 键值对的内存数据库 ，最主要的功能是做缓存 ， 如果 开启 RDB ， AOF 或多或少会分走一些资源 .

 

这里我们想要达到 纯缓存模式 (不要持久化了) 就可以 同时关闭 RDB + AOF , 达到性能的提升.

1. 禁用 RDB ： 在配置文件中 找到 save 将他设置为 “” 即可 .

注意 : 禁用 rdb 持久化模式下 ，我们仍然可以使用命令 save ， bgsave 生成 rdb 文件
 
2. 禁用 AOF ： 在配置文件中 找到 appendonly 设置为 no 即可.

 
注意 : 禁用 aof 持久化 模式下， 我们仍然可以使用命令 bgrewriteaof 生成 aof 文件