Redis的持久化

红白机
229 阅读10分钟

持久化机制的概念

数据持久化：数据从内存到磁盘中的过程

Redis官方提供了两种不同的持久化方法来将数据存储到硬盘里面分别是:

  • RDB 快照(Snapshot)
  • AOF (Append Only File) 只追加日志文件

1 RDB

1.1 特点

这种方式可以将某一时刻的所有数据都写入硬盘中,当然这也是redis的默认开启持久化方式,保存的文件是以.rdb形式结尾的文件因此这种方式也称之为RDB方式。

快照保存的是一个时刻的所有数据

image.png

1.2快照生成方式

  • 客户端方式: BGSAVE 和 SAVE指令
  • 服务器配置自动触发

1.客户端方式之BGSAVE:

客户端可以使用BGSAVE命令来创建一个快照,当接收到客户端的BGSAVE命令时,redis会调用fork¹来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求。（写时拷贝 COW）

fork: 当一个进程创建子进程的时候,底层的操作系统会创建该进程的一个副本,在类unix系统中创建子进程的操作会进行优化:在刚开始的时候,父子进程共享相同内存,直到父进程或子进程对内存进行了写之后,对被写入的内存的共享才会结束服务

image.png

2.客户端方式之SAVE:

客户端还可以使用SAVE命令来创建一个快照,接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令

image.png

  • 注意: SAVE命令并不常用,使用SAVE命令在快照创建完毕之前,redis处于阻塞状态,无法对外服务

3.服务器配置方式之满足配置自动触发

如果用户在redis.conf中设置了save配置选项,redis会在save选项条件满足之后自动触发一次BGSAVE命令,如果设置多个save配置选项,当任意一个save配置选项条件满足,redis也会触发一次BGSAVE命令 save m n: 在m秒内，如果有n个键发生变化，则自动触发持久化，通过bgsave执行。

image.png

4.服务器接收客户端shutdown指令

当redis通过shutdown指令接收到关闭服务器的请求时,会执行一个save命令,阻塞所有的客户端,不再执行客户端执行发送的任何命令,并且在save命令执行完毕之后关闭服务器

1.3配置生成快照名称和位置

通过配置文件进行修改

 #1.修改生成快照名称
 - dbfilename dump.rdb
 ​
 # 2.修改生成位置
 - dir ./

image.png

2 AOF 只追加日志文件

2.1特点

这种方式可以将所有客户端执行的写命令记录到日志文件中,AOF持久化会将被执行的写命令写到AOF的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次AOF文件所包含的所有写命令,就可以恢复AOF文件的记录的数据集.

image.png

2.2开启AOF持久化

在redis的默认配置中AOF持久化机制是没有开启的，需要在配置文件中开启

1.开启AOF持久化

  • a.修改 appendonly yes 开启持久化
  • b.修改 appendfilename "appendonly.aof" 指定生成文件名称

image.png

2.3日志追加频率

1.always 【谨慎使用】

  • 说明: 每个redis写命令都要同步写入硬盘,严重降低redis速度
  • 解释: 如果用户使用了always选项,那么每个redis写命令都会被写入硬盘,从而将发生系统崩溃时出现的数据丢失减到最少;遗憾的是,因为这种同步策略需要对硬盘进行大量的写入操作,所以redis处理命令的速度会受到硬盘性能的限制;
  • 注意: 转盘式硬盘在这种频率下200左右个命令/s ; 固态硬盘(SSD) 几百万个命令/s;
  • 警告: 使用SSD用户请谨慎使用always选项,这种模式不断写入少量数据的做法有可能会引发严重的写入放大问题,导致将固态硬盘的寿命从原来的几年降低为几个月。

2.everysec 【推荐】

  • 说明: 每秒执行一次同步显式的将多个写命令同步到磁盘
  • 解释： 为了兼顾数据安全和写入性能,用户可以考虑使用everysec选项,让redis每秒一次的频率对AOF文件进行同步;redis每秒同步一次AOF文件时性能和不使用任何持久化特性时的性能相差无几,而通过每秒同步一次AOF文件,redis可以保证,即使系统崩溃,用户最多丢失一秒之内产生的数据。

3.no 【不推荐】

  • 说明: 由操作系统决定何时同步
  • 解释：最后使用no选项,将完全有操作系统决定什么时候同步AOF日志文件,这个选项不会对redis性能带来影响但是系统崩溃时,会丢失不定数量的数据,另外如果用户硬盘处理写入操作不够快的话,当缓冲区被等待写入硬盘数据填满时,redis会处于阻塞状态,并导致redis的处理命令请求的速度变慢。

2.4修改同步频率

修改日志同步频率

修改appendfsync everysec|always|no 指定

image.png

3 AOF文件的重写

3.1 AOF带来的问题

AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件Redis提供了AOF重写(ReWriter)机制。

3.2 AOF重写

用来在一定程度上减小AOF文件的体积

3.3 触发重写方式

1.客户端方式触发重写

  • 执行BGREWRITEAOF命令 不会阻塞redis的服务

2.服务器配置方式自动触发

  • 配置redis.conf中的auto-aof-rewrite-percentage选项
  • 如果设置auto-aof-rewrite-percentage值为100和auto-aof-rewrite-min-size 64mb,并且启用的AOF持久化时,那么当AOF文件体积大于64M,并且AOF文件的体积比上一次重写之后体积大了至少一倍(100%)时,会自动触发,如果重写过于频繁,用户可以考虑将auto-aof-rewrite-percentage设置为更大

image.png

4. 重写原理

注意：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,替换原有的文件这点和快照有点类似。

重写流程

  • redis调用fork ，现在有父子两个进程子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
  • 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
  • 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
  • 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

image.png

4.混合持久化

混合持久化的目的

重启Redis时，我们很少使用RDB来恢复内存状态，因为会丢失数据。我们通常使用AOF日志重放。

但是重放AOF日志性能相对RDB来说要慢很多，这样在Redis实例很大的情况下，启动需要花费很长的时间。

Redis4.0 为了解决这个问题，带来了一个新的持久化选项 ：混合持久化。

开启混合持久化

开启混合持久的前提是开启了AOF

 # aof‐use‐rdb‐preamble yes

混合持久化细节

Redis4.0之后，提供了一个新的持久化选项：混合持久化。

将 rdb 文件的内容和增量的 AOF 日志文件存在一起。

混合持久化本质是通过 AOF 后台重写（bgrewriteaof 命令）完成的，不同的是当开启混合持久化时，fork 出的子进程先将当前全量数据以 RDB 方式写入新的 AOF 文件，然后再将 AOF 重写缓冲区（aof_rewrite_buf_blocks）的增量命令以 AOF 方式写入到文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差

image.png

5 持久化总结

两种持久化方案既可以同时使用(aof),又可以单独使用,在某种情况下也可以都不使用,具体使用那种持久化方案取决于用户的数据和应用决定。

无论使用AOF还是快照机制持久化,将数据持久化到硬盘都是有必要的,除了持久化外,用户还应该对持久化的文件进行备份(最好备份在多个不同地方)。

RDB 优点：

RDB 是一个非常紧凑（compact）的文件，体积小，因此在传输速度上比较快，因此适合灾难恢复。

RDB 可以最大化Redis 的性能：父进程在保存RDB 文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O 操作。

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

缺点：

RDB是一个快照过程，无法完整的保存所以数据，尤其在数据量比较大时候，一旦出现故障丢失的数据将更多。

当redis中数据集比较大时候，RDB由于RDB方式需要对数据进行完成拷贝并生成快照文件，fork的子进程会耗CPU，并且数据越大，RDB快照生成会越耗时。

RDB文件是特定的格式，阅读性差，由于格式固定，可能存在不兼容情况。

AOF　 优点：

数据更完整，秒级数据丢失(取决于设置fsync策略)。

兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容，再者aof文件是明文的，可阅读性较好。

缺点：

数据文件体积较大,即使有重写机制，但是在相同的数据集情况下，AOF文件通常比RDB文件大。

相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB。

由于频繁地将命令同步到文件中，AOF持久化对性能的影响相对RDB较大，但是对于我们来说是可以接受的。

混合持久化 优点：

混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。

缺点：

兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差

\

avatar
文章
阅读
粉丝