Redis学习笔记--持久化RDB和AOF

持久化简介：

Redis是内存kv字典数据库，内存在断电后数据会丢失，所以有数据持久化的需求，持久化是将数据从内存落入磁盘中，主要的方式是RDB和AOF（默认使用RDB），当然也可以关闭Redis的持久化。

 

RDB：

简介：

RDB是Redis Database的缩写，在指定的时间间隔内将内存的数据集快照写入磁盘中，也就是Snapshot内存快照。快照的实现类似照片记录的方式，就是把某一时刻的内存中的全量快照数据和状态以文件的形式放入到磁盘中，这样一来即使断电或宕机后内存数据丢失，也可以用磁盘中的快照文件来恢复数据，恢复时将硬盘快照文件读回内存里即可，以此提供更好的数据保障。这个快照文件就是RDB（dump.rdb）。

配置：

RDB的配置方式在不同的版本中是不一样的，相较之后在7以后的版本中配置项会更加丰富

6.0.16及以下版本：

 

6.2及以上版本：

 

在redis.conf中修改配置时，可以修改save的触发间隔和频次、RDB文件存储位置(需要提前创建好文件夹)、RDB文件名称（默认dump.rdb）

下图是将save的间隔改成了5秒钟之内发生过1次修改就触发一次全量快照操作

save是指全量快照的触发间隔，示例中是5秒钟内发生一次数据修改就会触发全量快照操作，切记这里是时间间隔，如果超出这个间隔的修改会被算到下一个时间周期内，无论执行什么命令（即使是flushdb，shutdown）只要是在时间间隔内的都会触发全量快照操作，因为要保证数据的一致性。

dbfilename是指RDB快照文件的名称，可以自行修改

dir是指RDB快照文件存储位置，可以自行修改，但要提前创建好文件夹

 

恢复：

在Redis重启时会在dir指定的RDB文件目录下读取dbfilename配置的数据文件将数据恢复到内存中。

dump.rdb文件一定要和redis隔离开来各自存储，以防止生产机器损坏后数据无法恢复。需要用定时任务来做固定时间间隔的rdb文件备份或者通过网络传输存储到其它介质中。

 

优缺点：

优点：

1、占用空间小，因为rdb文件是以紧凑的文件格式来存储的，便于异地备份时的网路传输。

2、适合大规模数据恢复，RDB是一个快照文件，在数据恢复时可以直接加载整个RDB文件到内存，速度相较AOF回快很多，因为AOF恢复是通过重放大量的写操作日志来恢复数据的。

3、适合做定期数据备份，RDB文件是某个时间点的完整快照，非常适合定期备份，并将其存储在不同的介质中，这些备份可以用于数据恢复、灾难恢复以及数据迁移等场景。

4、对Redis性能影响小，因为RDB的生成是由Redis的主进程fork出一个字进程来完成的，子进程共享主进程的内存数据，不需要主进程暂停服务来进行持久化操作，只有在fork子进程的瞬间会有短暂卡顿，客户端几乎无感

缺点：

1、数据可能丢失，由于RDB是快照的持久化方式，它正能保存某个时间点的数据，如果Redis在两次RDB之间发生了故障，例如：宕机、断电等等，那么上次快照之后的到故障前的数据修改都会丢失，例如，你设置每 15 分钟进行一次 RDB 快照，而在第 10 分钟时服务器崩溃，那么这 10 分钟内的数据变化将无法恢复。这种数据丢失的风险在对数据完整性要求极高的应用场景中是一个严重的问题，如金融交易系统。

2、fork的开销，虽然主进程fork子进程瞬间操作的阻塞时间很短，但是数据量非常大的情况下，fork会消耗大量系统资源，特别是在内存资源紧张的情况下，会拖慢整个系统，出现短暂的卡顿。而且生成RDB文件的时候需要遍历整个数据集写入磁盘，此时数据量会被放大两倍，可能会影响到下一次快照的按时执行导致数据备份不及时。

3、不适合实时持久化，RDB不是实时将数据写入磁盘而是按照一定的时间间隔生成快照，所以对于实时持久化要求很高的场景并不适用。

 

修复：

默认的RDB文件叫dump.rdb，也可以在配置中改成其它名称，这个文件在备份的时候可能会出现文件破损的情况，这个时候就需要用到bin目录下的redis-check-rdb来修复.rdb文件了。如果修复失败只能认倒霉了，数据就彻底丢失没法恢复了。

 

触发时机：

1、配置文件中默认的快照配置，例如：save 60 1 代表每6秒发生1次修改就会触发快照操作

2、手动触发，save/bgsave命令

3、flushall/flushdb情况数据的操作也会触发RDB备份，但是没有意义，清空后是没有数据的

4、主从复制时，主节点自动触发

 

禁用快照：

建议在配置文件中修改并重启redis使其生效，例如：将save 60 1 改成save "" 这RDB就被禁用了。

 

 

AOF：

简介：

Append Only File，从英文可以知道是通过文件追加的形式来实现数据备份的，将Redis执行过的写操作记录下来追加到文件末尾，只允许追加不可以改写之前的文件，在数据恢复时Redis会读取appendonly.aof文件重新构建数据，也就是把文件中的操作在当前数据库中重新执行一遍来实现数据的恢复，也可以叫做重放数据。AOF默认是关闭的，需要调整配置文件手动开启。

如果理解了RDB的数据丢失的缺点后就可以理解AOF是对RDB数据备份的一种补充。

 

配置：

只需要在配置文件redis.conf中将appendonly改为yes即可，默认是关闭的。

同步策略，默认使用erverysrc

这些配置在redis6及以前和redis7略有不同

下图是redis6的配置

 

下图是redis7的配置

 

数据本分及恢复流程：

1、客户端操作Redis，向Redis发送请求。

2、Redis在执行完命令后会异步的将操作命令写入内存中的AOF缓存区中进行保存，当缓存区中的的命令达到一定量后会触发写入磁盘操作，这样可以避免频繁的磁盘IO操作，较少IO开销

3、AOF缓存区根据同步文件的三种回写策略，将命令写入到磁盘的AOF文件中

4、随着磁盘AOF文件写入的增多，AOF文件会膨胀，AOF会对命令进行合并（AOF重写），从而达到压缩AOF文件的目的，减少AOF文件的大小。

5、Redis在重启后会从AOF中载入命令来重放写操作，达到恢复数据的效果。

 

同步策略：

1、Allways，同步写回，每个命令执行完成立刻同步的将AOF缓存区的文件写入到磁盘中，这个策略可以保证数据不丢失，但会增加磁盘IO，降低性能，是快的极端

2、everysec，每秒写回，每个命令执行完成后，先将命令写入内存的AOF缓存区，每隔1秒把缓存区中的内容写入磁盘中。这个策略比较这种，是默认的写回策略

3、no：看操作系统，由操作系统来控制AOF文件写入磁盘的时机，每个命令执行完成后，只是先把操作写入到内存的AOF缓存区，最终又操作系统来决定何时将内存缓存区中的数据写回磁盘，这个策略比较佛系，是慢的极端

 

优缺点：

优点：

1、数据安全性高：AOF以日志的形式记录Redis的每一个写操作，可以配置不同的同步策略（参考同步策略），即使发生故障，最多只会丢失1秒内的数据，保障了数据安全性。

2、日志易读性好：AOF文件是一个存文本文件，记录每一个Redis的写命令，方便进行分析和修复，例如，可以通过编辑AOF文件来手动删除或修复一些错误的命令。

3、数据完整性好：AOF文件记录了所有写操作，在做数据恢复时可以保证数据的完整性（相较RDB存在save间隔丢数据而言）

 

缺点：

1、AOF文件体积大：AOF文件会不断追加写操作，时间长了文件会变得越来越大，会占用大量的磁盘空间而且还影响数据恢复的速度。

2、性能开销大：Redis的同步策略会影响Redis的性能，即使是默认的everysec策略，每秒同步也会带来一定的性能开销

3、恢复速度慢：相较.rdb文件而言，.aof文件较大，在数据恢复时，需要执行更多的命令来重建数据。

 

修复：

这个文件在备份的时候可能会出现文件破损的情况，这个时候就需要用到bin目录下的redis-check-aof来修复.aof文件了。一般来说是可以正常修复的，如果修复失败只能认倒霉了，数据就彻底丢失没法恢复了。

如果不小心执行力flushall/flushdb命令将数据清空了，只需要vim/vi打开.aof文件将最后一行flushall/flushdb命令删除后保存，然后重启Redis即可恢复原有数据。

 

重写机制：

AOF持久化是通过追加命令并记录到.aof文件中来完成的，随时时间的推移.aof文件会越来越大，占用服务器的内存和磁盘空间也会变大，数据恢复时间也会变长。为了解决这个文件Redis提供了.aof文件的重写机制，当AOF文件的大小达到配置文件中所设置的峰值时，Redis会自动的启动AOF的文件压缩操作，只保留可以恢复数据的最小指令集，类似合并同类型，也可以手动使用命令bgrewriteaof来触发。也就是说AOF文件的重写不是通过对原有文件的整理，而是直接读取服务器现有kv键值对，然后用一条命令去代替之前记录的这个键值对的命令，生成一个新的文件去替换原有的AOF文件。

 

AOF和RDB比对：

1、数据安全性：AOF的数据安全性高于RDB。AOF可以通过配置不同的同步策略来控制数据丢失的风险，而RDB只能通过调整save的时间间隔来减少数据丢失，但仍然无法保证两次快照之间的数据丢失。

2、性能影响：RDB的性能是优于AOF的，RDB在fork子进程时会有短暂的阻塞和卡顿，基本对主进程没有太多影响。而AOF的同步策略会带来一定的开销，尤其是使用always时会严重影响写入性能。

3、文件大小和恢复速度：RDB文件紧凑，体积小，数据恢复速度更快，而AOF是文件追加的形式记录命令的，时间长了文件会变大，数据恢复的时候速度也要慢于RDB。

4、使用场景：如果对数据丢失零容忍（如金融或交易系统）则需要使用AOF，如果可以接受数据丢失，对数据恢复速度和Redis性能有要求则使用RDB，实际应用中一般RDB和AOF都会开启。

 

RDB和AOF的混合开启：

RDB适合做全量数据持久化

AOF适合做增量数据持久化

RDB是默认开启的，AOF的需要手动开启。它两是可以一起开启的，同时开启以AOF为优先，因为AOF保存的数据以RDB更完整，所以使用AOF，如果两个都开启在重启Redis后，优先加载AOF文件，如果没有AOF才会加载RDB，如果RDB都没有就正常启动，不做数据恢复操作了。

 

纯缓存模式：

在配置文件中关闭RDB配置save "" 并且关闭AOF配置 appendonly on 的时候就属于纯缓存模式了，这个模式一般在生产环境中不太多见。