Redis多种持久化方式(详解版)

Redis持久化概念：

•Redis 的读写都是在内存中，所以它的性能较高，但在内存中的数据会随着服务器的重启而丢失，为了保证数据不丢失，我们需要将内存中的数据存储到磁盘，以便 Redis 重启时能够从磁盘中恢复原有的数据，而整个过程就叫做 Redis 持久化。
在这里插入图片描述

Redis持久化的几种方式：

Redis 持久化拥有以下三种方式：
       •快照方式（RDB, Redis DataBase将某一个时刻的内存数据，以二进制的方式写入磁盘；
       •文件追加方式（AOF, Append Only File），记录所有的操作命令，并以文本的形式追加到文件中；
       •混合持久化方式Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能减低数据丢失的风险。

RDB概念：

•RDB（Redis DataBase）是将某一个时刻的内存快照（Snapshot），以二进制的方式写入磁盘的过程。

RDB持久化的触发：

•RDB 的持久化触发方式有两类：一类是手动触发，另一类是自动触发。

1. 手动触发：

•手动触发持久化的操作有两个： save 和 bgsave，它们主要区别体现在：是否阻塞 Redis 主线程的执行。

save命令：

•save 命令：在客户端中执行 save 命令，就会触发 Redis 的持久化，但同时也是使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用。

bgsave命令：

•bgsave 命令： bgsave（background save）即后台保存的意思，它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化，整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了，相对于整个流程都阻塞的 save 命令来说，显然 bgsave 命令更适合我们使用。

2. 自动触发：

  •RDB 自动持久化主要来源于以下几种情况：
       •save m n： save m n 是指在 m 秒内，如果有 n 个键发生改变，则自动触发持久化。参数 m 和 n 可以在 Redis 的配置文件中找到，例如，save 60 1 则表明在 60 秒内，至少有一个键发生改变，就会触发 RDB 持久化。自动触发持久化，本质是 Redis 通过判断，如果满足设置的触发条件，自动执行一次 bgsave 命令。 注意：当设置多个 save m n 命令时，满足任意一个条件都会触发持久化。
       •flushall： flushall 命令用于清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空。

配置说明：

# RDB 保存的条件
save 900 1
save 300 10
save 60 10000

# bgsave 失败之后，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件。
stop-writes-on-bgsave-error yes

# RDB 文件压缩
rdbcompression yes

# 写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes

# RDB 文件名
dbfilename dump.rdb

# RDB 文件目录
dir ./

重要参数：

       •save 参数它是用来配置触发 RDB 持久化条件的参数，满足保存条件时将会把数据持久化到硬盘。默认配置说明如下：
              •save 900 1：表示如果900 秒内至少有 1 个 key 值变化，则把数据持久化到硬盘；
              •save 300 10：表示如果300 秒内至少有 10 个 key 值变化，则把数据持久化到硬盘；
              •save 60 10000：表示如果60 秒内至少有 10000 个 key 值变化，则把数据持久化到硬盘。
       •rdbcompression 参数它的默认值是 yes 表示开启 RDB 文件压缩，Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话，可以设置为关闭此功能，这样的缺点是需要更多的磁盘空间来保存文件。
       •rdbchecksum 参数它的默认值为 yes 表示写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

配置查询：

•Redis 中可以使用命令查询当前配置参数。查询命令的格式为：config get xxx ，例如，想要获取 RDB 文件的存储名称设置，可以使用 config get dbfilename
在这里插入图片描述

RDB优缺点：

       •RDB 优点：
              •RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件；
              •RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复；
              •RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作；
              •与 AOF 格式的文件相比，RDB 文件可以更快的重启。
       •RDB 缺点：
              •因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据；
              •RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上。如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟。

AOF概念：

•AOF（Append Only File）意思是是附加到文件，AOF是将Redis每个键值对操作都记录到文件（appendonly.aof）中。

AOF持久化查询和设置：

•查询 AOF 启动状态：使用 config get appendonly 命令
•第一行为 AOF 文件的名称，最后一行表示 AOF 启动的状态，yes 表示已启动，no 表示未启动。
在这里插入图片描述

       •开启 AOF 持久化
              •Redis 默认是关闭 AOF 持久化的，想要开启 AOF 持久化，有以下两种方式：
              •通过命令行的方式；
              •通过修改配置文件的方式（redis.conf）。

命令行启动 AOF：

•命令行启动 AOF，使用 config set appendonly yes 命令，如下图所示：
在这里插入图片描述
•命令行启动 AOF 的优缺点：命令行启动优点是无需重启 Redis 服务，缺点是如果 Redis 服务重启，则之前使用命令行设置的配置就会失效，需要重新设置。

配置文件启动 AOF

•Redis 的配置文件在它的根路径下的 redis.conf 文件中，获取 Redis 的根目录可以使用命令 config get dir 获取，如下图所示：
在这里插入图片描述

•只需要在配置文件中设置 appendonly yes 即可，默认 appendonly no 表示关闭 AOF 持久化。配置文件启动 AOF 的优缺点：修改配置文件的缺点是每次修改配置文件都要重启 Redis 服务才能生效，优点是无论重启多少次 Redis 服务，配置文件中设置的配置信息都不会失效。

AOF触发持久化：

自动触发：

       •有两种情况可以自动触发 AOF 持久化，分为是：满足 AOF 设置的策略触发和满足 AOF 重写触发，AOF 持久化策略，分为以下三种：
              •always：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据；
              •everysec：每秒钟写入一次磁盘，最多丢失一秒的数据；
              •no：不设置写入磁盘的规则，根据当前操作系统来决定何时写入磁盘，Linux 默认 30s 写入一次数据至磁盘。
      •这三种配置可以在 Redis 的配置文件（redis.conf）中设置，如下代码所示：

# 开启每秒写入一次的持久化策略
appendfsync everysec

手动触发：

•在客户端执行 bgrewriteaof 命令就可以手动触发 AOF 持久化，如下图所示：
在这里插入图片描述