Redis持久化的几种方式

Redis持久化的几种方式

前言：使用Redis作为缓存的问题，Redis的读写都是在内存当中的，虽然它的性能较比其他的数据库（MySQL等待）更高，但是它的缺点就是内存当中的数据会随着服务器的重启而丢失。所以为了保证数据不丢失，我们需要将内存中的数据存储在磁盘当中，以便Redis在重启之后可以冲磁盘当中回复原来的数据，而整个过程就叫做Redis的持久化。

1.持久化的几种方式

Redis的持久化有3种方式

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

2.RDB的简介

RDB （Redis DataBase）是将某一时刻的内存快照（snapshot）以二进制的形式写入磁盘中

3.持久化的触发

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

1）手动触发

手动触发的方式有两个：save和bgsave，他们的主要区别就在于是否会阻塞主线程的执行。

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

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

2）自动触发

接下来我们来看一下如何自动触发 RDB 持久化？RDB 自动持久化主要来源于以下几种情况。

• save m n
  save m n 是指在 m 秒内，如果有 n 个键发生改变，则自动触发持久化。参数 m 和 n 可以在 Redis 的配置文件中找到，例如， save601 则表明在 60 秒内，至少有一个键发生改变，就会触发 RDB 持久化。自动触发持久化，本质是 Redis 通过判断，如果满足设置的触发条件，自动执行一次 bgsave 命令。注意：当设置多个 save m n 命令时，满足任意一个条件都会触发持久化。例如，我们设置了以下两个 save m n 命令：

save 60 10
save 600 1

当 60s 内如果有 10 次 Redis 键值发生改变，就会触发持久化；如果 60s 内 Redis 的键值改变次数少于 10 次，那么 Redis 就会判断 600s 内，Redis 的键值是否至少被修改了一次，如果满足则会触发持久化。

• flushall 命令
  用于清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空。
• 主从同步触发
  在 Redis 主从复制中，当从节点执行全量复制操作时，主节点会执行 bgsave 命令，并将 RDB 文件发送给从节点，该过程会自动触发 Redis 持久化。

4.RDB的优缺点

1）RDB的优点

• RDB的内容为二进制的数据，占用内存更小，更紧凑，适合做备份数据；
• RDB对灾难恢复很有用，它是一个紧凑的文件，可以更快的传输到远程的服务器进行数据恢复；
• RDB可以更大程度的提高Redis的运行速度，因为每次持久化，主进程就会fork() 一个进程，进行数据持久化到磁盘当中，Redis主进程并不会执行I/O操作
• 与AOF格式的文件相比，RDB文件可以更快的重启。

2）RDB的缺点

• 因为Redis只能保存某一时间间隔的数据，所以如果Redis意外宕机的话，就会丢失一段时间的数据；
• RDB需要经常fork()一个子进程进行持久化操作，如果数据集很大的话，那么fork()就会很耗时，并且非常的消耗CPU的性能，则可能导致Redis停止为客户端服务。