关于Redis 的三种持久化方式你需要了解的事情？

╰半橙微兮° 2023-07-14 10:40 4阅读 0赞

# Redis 持久化 #

## 前言 ##

Rdis的读写都是在内存中进行，所以redis的性能很高。  
持久化可以有效地避免因进程退出而造成数据丢失问题，下次重启的时候利用之前持久化文件可以实现数据恢复。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70]

## 持久化的几种方式 ##

Redis 持久化拥有以下三种方式：

*  快照方式（RDB, Redis DataBase）

> RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发

*  文件追加方式（AOF, Append Only File）

> 记录所有的操作命令，并以文本的形式追加到文件中；

*  混合持久化方式，

> Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能减低数据丢失的风险。

以上三种持久化方案，每一种都有特定的使用场景,具体的我们可以根据自己的需求自行选择。

## RDB持久化 ##

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

RDB的持久化方式有两种：

`一种是手动触发，一种是自动触发`

#### 手动触发 ####

手动触发Redis提供了两个命令 ：`save` 和 `bgsave` 。

*  save 命令

`save` 手动触发会阻塞主线程

在客户端执行`save`命令时候，就会触发持久化，但也会使得Redis主线程阻塞，必须等到RDB持久化完成之后，才会相应客户端的命令，`线上环境不建议使用`。

下图演示使用`save`命令

启动Redis （默认配置是rdb持久化方式），rdb文件时间。

![在这里插入图片描述][20200314132440998.png]

然后使用`save`持久化数据

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 1]  
然后查看持久化后rdb文件的时间  
![在这里插入图片描述][20200314132656647.png]  
说明手动持久化文件成功

*  bgsave 命令

`bgsave`不会阻塞主线程

使用`bgsave`命令时候，Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短，基本不会发生阻塞，与`save`命令相比显然`bgsave`更适合我们持久化数据。

下图表示开始自动持久化数据  
![在这里插入图片描述][20200314133017941.png]

#### 自动触发 ####

如何自动触发 RDB 持久化？

在redis.conf文件中有这么一个配置

![在这里插入图片描述][2020031413551157.png]

什么意思呢？

*  save m n

`save m n` 表示m秒内数据集存在n次修改 时，自动触发`bgsave`命令。

> save 900 1 则表明在 900 秒内，至少有一个键发生改变，就会触发 RDB 持久化。  
> save 300 10 则表明在 300 秒内，至少有10个键发生改变，就会触发 RDB 持久化。  
> save 60 10000 则表明在 60 秒内，至少有10000个键发生改变，就会触发 RDB 持久化。

满足以上任意一个条件，Redis 就会自动触发`bgsvae`命令进行持久化工作。

*  flushall

注意：`flushall` 是把内存中的数据清空，持久化会把原先已经持久化的 .rdb 文件清空。

*  主从同步触发

Redis主从复制时，当从节点执行全量复制操作时，主节点会执行 bgsave 命令，并将 RDB 文件发送给从节点，该过程会自动触发 Redis 持久化。

RDB配置说明

# RDB 保存的条件
    save 900 1
    save 300 10
    save 60 10000
    
    # bgsave 失败之后，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件。
    stop-writes-on-bgsave-error yes
    
    # RDB 文件压缩 
    # Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话，可以设置为关闭此功能，# 这样的缺点是需要更多的磁盘空间来保存文件。
    rdbcompression yes
    
    # 写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
    rdbchecksum yes
    
    # RDB 文件名
    dbfilename dump.rdb
    
    # RDB 文件目录
    dir ./

##### RDB 优缺点 #####

优点

*  RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据 快照。非常适用于备份，全量复制等场景。
 *  与 AOF 格式的文件相比，RDB 文件可以更快的重启。
 *  RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复

缺点

*  RDB方式数据没办法做到实时持久化/秒级持久化，RDB只能保存某个时间间隔的数据，如果在这个期间Redis故障了，就会丢失一段时间的数据。
 *  RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

###### 禁用持久化 ######

save ""

## AOF持久化 ##

AOF（append only file）持久化：以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用 是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF的工作流程操作

> 命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）。

##### 配置AOF #####

默认是 `no`表示关闭 ，`yes`表示开启。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 2]

*  自动触发

持久化配置  
![在这里插入图片描述][20200314142957515.png]

*  always：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据，但会使得Redis的性能降低，但数据几乎是全的，基本不会存在丢失数据问题。
 *  everysec：每秒钟写入一次磁盘，最多丢失一秒的数据，对存取数据和性能折中，可以满足大部分使用场景。
 *  no：不设置写入磁盘的规则，根据当前操作系统来决定何时写入磁盘，一般不采用这种设置。
 *  手动触发

使用`bgrewriteaof`命令可以手动触发aof持久化

![在这里插入图片描述][20200314144048117.png]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 3]

随着时间的推移和数据量变大，aof一直在进行持久化，磁盘日志越来越大，redis重启速度越来越慢，针对这个问题，Redis提供了AOF重写功能。

Redis中的数据是有一定限量的，最多不超过物理内存大小，不可能说Redis中的数据无限增长，导致aof也无限增长，到一定的时候Redis就会采用缓存淘汰算法LRU自动将以部分数据从内存中给清除。

AOF 重写配置  
![在这里插入图片描述][20200314144615269.png]

*  auto-aof-rewrite-min-size：允许 AOF 重写的最小文件容量，默认是 64m 。
 *  auto-aof-rewrite-percentage：AOF 文件重写的大小比例，默认值是 100，表示 100%，也就是只有当前 AOF 文件，比最后一次（上次）的 AOF 文件大一倍时，才会启动 AOF 文件重写。

AOF 重写流程

AOF 是存放每条写命令的，所以会不断变大，达到一定的时候，AOF做rewrite操作，会重新生成一个新的AOF文件。

优缺点

AOF 优点

AOF 持久化保存的数据更加完整，AOF 提供了三种保存策略：每次操作保存、每秒钟保存一次、跟随系统的持久化策略保存，其中每秒保存一次，从数据的安全性和性能两方面考虑是一个折中的选择，也是 AOF 默认的策略，即使发生了意外情况，最多只会丢失 1s 钟的数据；

AOF 采用的是命令追加的写入方式，所以不会出现文件损坏的问题，即使由于某些意外原因，导致了最后操作的持久化数据写入了一半，也可以通过 redis-check-aof 工具轻松的修复；

AOF 持久化文件，非常容易理解和解析，它是把所有 Redis 键值操作命令，以文件的方式存入了磁盘。即使不小心使用 flushall 命令删除了所有键值信息，只要使用 AOF 文件，删除最后的 flushall 命令，重启 Redis 即可恢复之前误删的数据。

AOF 缺点

对于相同的数据集来说，AOF 文件要大于 RDB 文件；

在 Redis 负载比较高的情况下，RDB 比 AOF 性能更好；

RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 更健壮。

## 混合持久化 ##

RDB和AOF持久化各有优缺点，RDB会导致一段时间内的数据丢失，AOF文件会越来越大，会影响Redis的启动速度，为了同时兼顾RDB，AOF的优点，Redis在4.0版本之后提供了混合持久化方式。

混合持久化

> AOF 重写时会把 Redis 的持久化数据，以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式化追加的文件的末尾，如下图所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 4]

开启混合

将`no`改为`yes`即可  
![在这里插入图片描述][20200314151103467.png]

混合持久化优缺点

优点

混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。

缺点：

AOF 文件中添加了 RDB 格式的内容，会使得 AOF 文件的可读性会很差，不容易阅读；  
如果开启混合持久化，就必须使用`Redis 4.0 以及之后版本`。

使用混合持久化的时候可以根据自身业务选择关闭RDB或者AOF，或者关闭持久化。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70]: /images/20230529/8ad39d06e8ab48868dcdf7dfe310fb47.png
[20200314132440998.png]: /images/20230529/0f3e03c51c474fa7af5cc0c57c622dcf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 1]: /images/20230529/347c4d8e051e4933bd357e029799ef95.png
[20200314132656647.png]: /images/20230529/2b2b123c40e5427c945c5f8bfdd88eda.png
[20200314133017941.png]: /images/20230529/386f758cec17421cb8673a401f52e60a.png
[2020031413551157.png]: /images/20230529/fac57d24c5724ee38a67edcbb9e584dc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 2]: /images/20230529/36237227cedd446d9931b170cb527378.png
[20200314142957515.png]: /images/20230529/ebea3bc2c3814e6cbea7b3e99444b4a5.png
[20200314144048117.png]: /images/20230529/0fda8df67b904f3e8b805f10df561df0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 3]: /images/20230529/dd44a3c4d052463b92bb6a6995cf665a.png
[20200314144615269.png]: /images/20230529/5f67ab0d0c964f2180dd79d6cdb5e070.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODM2MTM0Nw_size_16_color_FFFFFF_t_70 4]: /images/20230529/1349d02a31484c25b649b6467787cb44.png
[20200314151103467.png]: /images/20230529/8ef32f685d9540bca680080a4e894763.png