目录

一、什么是持久化，为什么要持久化？

 二、RDB

 2.1 配置文件

2.2 自动触发

2.3 手动触发

2.4 RDB优缺点

2.5 如何修复dump.rdb文件

2.6   哪些情况会触发快照  && 如何禁用RDB？

 三、AOF

3.1  什么是AOF？

 3.2  AOF的三种写回策略

 3.3  AOF的配置

 3.4   AOF演示

 3.5 AOF恢复

3.6  AOF数据备份的优缺点

3.7  AOF的重写机制

四、RDB和AOF混合存在  与  纯缓存模式

4.1   RDB和AOF混合存在

 4.2 纯缓存模式

---

一、什么是持久化，为什么要持久化？

持久化就是把内存中的内容写进到磁盘当中。

因为如果数据是在内存当中的话，一旦断电（服务器宕机），那么数据都打到mysql上，这将是灾难的。

现在持久化的方式就两种：RDB和AOF

 二、RDB

 什么是RDB？

 2.1 配置文件

7之前的配置

 7之后的配置

 可以看到，7之后对频次要求更高了

2.2 自动触发

我们先看一下默认的自动触发条件：

 修改配置：

这里的修改我们分成了三步：

1、我们可以在5秒内修改两次，来观察下效果：

flushall     /   flushdb命令也会直接生成dump文件，单生成的文件是空的

而且，在执行shutdown的时候，也会立刻生成一个dump文件。

我们再来观察下恢复的情况：

备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，

以防生产机物理损坏后备份文件也挂了

2.3 手动触发

当我们有一个比较重要的数据进来的时候，这时候还没有满足频次的要求呢，但是我们也想要保存他，为了满足这一要求，我们就可以采用手动触发的方式来进行。

生产上只能用bgsave，绝对不能和用save

因为用save会阻塞redis服务器，直到持久化任务完成，相当于解决了一个问题，但又产生了一个新的问题，这是不行的

 而bgsave会在后台异步进行快照操作，不阻塞快照的同时还可以想要客户端请求该触发方式会fork一个子进程由子进程复制持久化过程

2.4 RDB优缺点

优势

（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

劣势：

（1）可能会出现数据丢失：比如说还没有满足修改频次要求的时候，服务器宕机了，那么就会丢失最近一次的数据。

（2）Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑，可能会导致服务请求延时

2.5 如何修复dump.rdb文件

2.6   哪些情况会触发快照  && 如何禁用RDB？

哪些情况会触发快照？

1、符合自动触发条件

2、手动触发：save    bgsave

3、使用flushall  或者  flushdb的时候，但生成的rdb文件是空的，没有什么意义。

4、使用shutdown且没有开启AOF持久化

5、主从复制的时候，主节点自动触发

如何禁用RDB？

1、命令型修改（就这一次）：

 2、配置文件修改：

 三、AOF

3.1  什么是AOF？

• 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
• 默认情况下，redis是没有开启AOF的
• 开启AOF 功能需要设置配置 ： appendonly yes

 3.2  AOF的三种写回策略

 3.3  AOF的配置

生成路径配置：

 保存名称的配置：

redis 7之前，只有一个AOF文件，redis7之后引入了Mult Part AOF的设计，一共有三个文件

 3.4   AOF演示

生成持久化文件：

 3.5 AOF恢复

正常恢复：

和RDB的恢复一样，很简单的测试

 异常恢复：

情景展示：

那么遇到这种情况该怎么修复呢？

这和我们的RDB修复的情况很类似，也是用到了/usr/local/bin   下面的文件进行的

 修复完成之后，我们再次启动就正常了。

3.6  AOF数据备份的优缺点

优势

• 更好的保护数据不丢失、性能高、可做紧急恢复
• AOF有  “减肥”  机制，当AOF文件过大的时候，能够在后台自动重写（减肥）。
• 当不小心执行了fluhall命令后，我们也可以通过将incr文件的最后一条flushall删除就行了。

劣势

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
• aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

3.7  AOF的重写机制

一句话概括就是：

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，就是“减肥计划”

重写案例：

 触发条件：

 触发演示：

 我们首先肯定要修改触发条件，默认的64M我们肯定是实现不了的。

我们先来看下自动触发：

 手动触发：

重写原理：

四、RDB和AOF混合存在  与  纯缓存模式

4.1   RDB和AOF混合存在

混合存在时候的流程：

 我们应该是用到混合存在的手段，而不是单独用其中一个，就像鸳鸯锅一样

 4.2 纯缓存模式

我们要知道，redis最主要的工作就是缓存的工作，是为了来保护mysql的，开启持久化功能的时候势必会让redis分心，

有时候在高并发、高性能的缓存服务器条件下，我们会为了效率，关闭持久化功能，只是让redis进行缓存功能

关闭功能的手段：         我们只是禁用了自动触发的部分，但是我们还是可以手动触发