持久化的作用

redis所有数据保存在内存中，对数据的更新将异步地保存到磁盘上。

有两种方式可以选择：

一、RDB（默认）

什么是RDB？

• 通过一条命令将当前redis内存数据完整的<mark>生成一个快照然后写入到RDB文件中</mark>
• RDB文件有自身的一些格式，是采用二进制形式来保存的，当需要对redis数据进行恢复，比如redis做了一次重启，那么就可以将该文件重新载入到redis中，将某个时刻的redis数据备份恢复到redis当中。
• 在主从复制中RDB还充当了<mark>复制的媒介作用</mark>。

触发机制 - 主要三种方式

主要三种方式包括：save(同步)、bgsave(异步)、自动

save命令

• 在客户端执行save命令，redis就会帮我们生成一个RDB文件。
• 执行这个命令有个问题就是它是一个同步命令，如果save命令执行比较慢，其他所有命令都需要排队，也就是说数据量大的时候可能造成redis服务器阻塞。

文件策略是：当存在老的RDB文件时，执行命令会先生成一个临时文件，当命令执行完毕后将老的文件替换掉。

bgsave命令(异步)

• 首先客户端执行 bgsave 命令，它不会像save命令一样去同步生成RDB，而是会在后台单独开启一个线程去执行。

• 即使用了linux的fork()函数生成了主进程的一个子进程，由redis子进程去生成RDB文件，当RDB文件生成完毕后会通知主进程文件已经生成成功了。

注意：fast说明子进程是执行非常快的(大多数情况)，但是极少数情况下fork执行慢的话依然会阻塞redis

自动生成RDB

通过配置实现，达到某些条件情况下自动生成RDB文件。
如图所示的配置代表，如果60s改变了1万次数据，300s改变了10次数据，900s内改变了一条数据，三个条件任意满足一条即会自动生成RDB文件，当然它的自动生成实际是执行了bgsave命令。

自动生成问题

• 如果对数据频繁的进行操作，会经常的进行数据的保存，无法精确的控制（一般不会使用）

两种方式对比

其他触发

有时候会造成自动的创建RDB文件，有下面几种可能：

• 主从之间进行复制时，会需要全量复制，生成RDB文件
• debug reload，即debug级别的重启，不会清空内存的数据，会生成RDB文件
• 使用命令关闭时，会自动保存

总结

• RDB是Redis内存到硬盘的快照，用于持久化
• save通常会阻塞Redis
• bgsave不会阻塞Redis，但是会fork新进程
• save自动配置满足任一条件就会被执行(通常不使用)
• 有些触发机制不容忽视

二、AOF

RDB的问题

耗时、耗性能

• RDB生成过程就是内存中的Redis数据dump到硬盘当中，形成一个RDB文件。
• 因为需要将所有数据进行dump，所以是比较耗时的
• 写比较消耗CPU资源，fork消耗内存。
• 如果数据量很大，写入硬盘也会消耗IO性能。

不可控、丢失数据

• 无论是定时执行save/bgsave命令，还是使用自动生成策略，都存在数据丢失的可能性
  

AOF运行原理

基于日志的原理，客户端执行每条写入命令都会追加到AOF文件中，当然存入命令时肯定是使用AOF特定的格式

恢复：当redis发生宕机之后，就可以使用AOF将redis中的数据进行完整的恢复，而且恢复基本是实时的。因为有记录到每个写入命令，当然根据不同AOF的策略也会决定写入的频率

AOF的三种策略

• 三种策略: always、everysec、no

在记录写入命令时，通常会先存放在缓冲区中，可以提高写入的效率，缓冲区再根据生成策略刷新到AOF文件中。

• always: 每条命令都会fsync到硬盘中，这样redis的写入数据就不会丢失

everysec: 每秒都会刷新缓冲区到硬盘中(默认值)
在高写入量时候会适当保护到硬盘，但是如果redis出现故障，有可能会丢失1秒的数据

no: 根据当前操作系统的规则决定什么时候刷新到硬盘中，不需要我们来考虑

三种策略选择

<mark>通常采用默认配置：everysec，第一种如果redis写入量非常大，硬盘压力也会非常大。</mark>

AOF重写

AOF存在的问题是：随着时间逐步推移，AOF文件也会逐渐变大，那就会出现很多问题，比如如果使用AOF文件来进行恢复会非常慢。

如果文件无限制的增大，无论是对硬盘的管理还是写入命令的速度都会有一定影响，所以redis提供了AOF重写的方式来解决这个问题。

AOF重写作用

其实AOF重写就是将一些过期的、没有用的、重复的以及一些可优化的命令都可以进行化简，化简成一个很小的AOF文件。

从而达到如下目的：<mark>减少硬盘占用量、加速恢复速度</mark>

AOF重写实现两种方式

bgrewriteaof命令(类似bgsave)

本质上：<mark>是从内存中进行重写，而不是对文件重写</mark>

AOF重写配置(自动重写，实际也是执行命令)

• 第一个配置就是说当AOF文件多大时进行重写，
• 第二个就是说下一次增长率是多少进行重写。

比如达到100M进行重写，并且文件增长率为100%，即200M，400M后会再次进行重写。

AOF统计项

AOF重写流程

• 客户端发送bgrewriteaof命令，由redis主(父)进程执行

• 父进程会fork出一个子进程

• 父进程仍然会进行正常的客户端的读写以及3.1和3.2过程
  ① redis仍然会将写命令写入到aof_buf当中，然后去写入到旧的AOF文件当中
  ② 除此之外，redis还会将这期间的写命令写入到aof_rewrite_buf当中

• 子进程去完成AOF重写过程，其实是将内存中的数据进行回溯，然后写到新的AOF文件中
  ① 当新文件生成之后，子进程会发送信号通知父进程
  ② 当新文件生成之后，会将这个buffer(在重写期间新的增长数据)补充到新的AOF文件当中
  ③ 最终会用新的AOF文件来替换老的AOF文件完成AOF重写过程

AOF相关配置

• appendonly: 要使用AOF功能需要设置为yes，默认为no
• appendfilename: AOF文件名
• appendfsync: AOF生成策略
  dir: 保存RDB、AOF文件以及日志文件的目录
• no-appendfsync-on-rewrite: 在AOF重写的时候，是否要做正常的append操作，yes代表不做这个操作
• auto-aof-rewrite-percentage: AOF文件增长率
• auto-aof-rewrite-min-size: AOF文件重写需要的尺寸

RDB VS AOF