Redis的两种持久化机制

1、持久化机制

client--->redis(内存)--->内存数据-数据持久化--->磁盘

两种方法

• 快照（Snapshot）
• AOF（Append Only File）只追加日志文件

2、快照

2.1 特点

这种方式可以将某一时刻的所有数据写入到硬盘中，这也是redis的默认开启持久化方式，保存的文件是以.rdb结尾的文件，因此这种方式也被称为RDB方式。官方的说法叫快照持久化。

2.2 快照生成方式

• 客户端方式：BGSAVE和SAVE指令

• 服务器配置自动触发

  客户端方式1：BGSAVE
  客户端可以使用BGSAVE命令来创建一个快照，当接收到客户端的这个命令后，redis会调用fork操作来创建一个子进程，然后子进程负责把这个快照写入到磁盘中，而父进程继续处理命令请求
  
  什么是fork：fork是linux系统的调用：在当前进程中，fork一个子进程，子进程最初与主进程是共享一份内存区域的。由于主进程不断进行数据的写操作，与子进程存在并发冲突问题。此时，redis采用写时复制技术（cow）：
  当主进程写操作时，首先会复制一份将要涉及写操作的内存页。然后主进程在新复制的内存页上进行写操作，原有内存页继续供子进程持久化。
  

  

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

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

  

  服务器配置自动触发:
  如果用户在redis.conf中设置了save配置选项，redis会在save选项条件满足之后自动触发一次BGSAVE命令，如果设置多个save配置选项，每当任意一个save配置选项条件满足，redis也会触发一次BGSAVE命令
  

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

3.AOF方式——只追加日志文件

3.1 特点

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

3.2 开启AOF持久化

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

3.3 日志追加频率

1.always[谨慎使用]
说明：每个redis命令都要同步写入硬盘，严重降低redis速度，这种方式可以将发生系统崩溃时丢失的数据减少到最少，但是由于这种方式要对硬盘进行大量的写入操作，所以redis处理命令的速度会受到硬盘性能的限制。机械硬盘在这种频率下200左右个命令/s ;固态硬盘（SSD）大概几百万个命令/s;使用SSD用户请谨慎使用always选项,这种模式不断写入少量数据的做法有可能会引发严重的`写入放大`问题,导致将固态硬盘的寿命从原来的几年降低为几个月。

2.everysec[推荐默认]
说明：每秒执行一次同步，将多个写命令同步到磁盘。即使系统崩溃也最多丢失一秒的数据。

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

3.4 修改同步频率

修改appendfsync everysec|always|no 指定

3.5 AOF文件的重写

3.5.1 出现的问题

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

3.5.2 AOF重写

用来在一定程度上减少AOF文件的体积，并且保证数据不丢失

3.5.3 触发AOF重写的方式

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设置为更大

3.5.4 重写原理

开启AOF持久化后生成一个appendonlydir文件夹，这个文件夹下有如下三个文件

从Redis 7.0.0 开始，Redis使用了多部分AOF 机制。也就是将原来的单个AOF文件拆分为基础文件（最多一个）和增量文件（可能不止一个）。基本文件表示重写AOF 时存在的数据的初始（RDB 或 AOF 格式）快照。所有这些文件都放在一个单独的目录中，并由清单文件跟踪。

重写过程：在触发AOF重写后，redis调用fork创建一个子进程，子进程根据此时的数据状态生成快照，同时主进程会创建一个新的增量文件用来继续处理客户端传来的命令请求，子进程将这个快照文件以命令的形式写入临时文件，当快照往临时文件写完后，通知主进程把新的增量文件和子进程生成的基础文件构建成临时清单，并将其持久化，redis对清单文件进行原子交换，使AOF重写的结果生效，生成一个新的基础文件，并且创建一个新的aof增量文件来接收命令。

4.持久化总结

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

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