[大数据]02.Redis持久化

Redis持久化概述

Redis 的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。

Redis为持久化提供了两种方式：

• RDB：在指定的时间间隔能对你的数据进行快照存储。
• AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

由于AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AOF是目前主流的持久化方式，不过RDB持久化仍然有其用武之地。

下面依次介绍RDB持久化和AOF持久化；

RDB持久化

RDB是默认的持久化方式，按照一定的策略周期性的将内存中的数据生成快照保存到磁盘。

每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

1. 工作原理：

• Redis调用fork()，产生一个子进程。
• 子进程把数据写到一个临时的RDB文件。
• 当子进程写完新的RDB文件后，把旧的RDB文件替换掉。

2. 触发机制

RDB触发持久化分为手动触发和自动触发

1. save 命令（手动触发）

当客户端向Redis server发送save命令请求进行持久化时，由于Redis是用一个主线程来处理所有，save命令会阻塞Redis server处理其他客户端的请求，直到数据同步完成。save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求，因此线上环境不推荐使用

1. bgsave命令（手动触发）

与save命令不同，bgsave是异步执行的，当执行bgsave命令之后，Redis主进程会fork 一个子进程将数据保存到rdb文件中，同步完数据之后，对原有文件进行替换，然后通知主进程表示同步完成。

1. 自动触发

除了手动触发RDB持久化，Redis内部还存在自动触发机制，

在配置中集中配置 save m n 的方式，表示 m秒内数据集存在n次修改时，系统自动触发bgsave 操作。

3. RDB自动持久化配置

save 3600 1  # 3600秒内至少有一个key改变，数据就会进行持久化操作
save 300 100 # 300秒内如果写入了130个，就先持久化最新的100个，然后计时器重置，从101个起计算，知道
save 60 10000 

# 时间策略
save 900 1  
save 300 10
save 60 10000

1) “save 900 1”表示如果900秒内至少1个key发生变化（新增、修改和删除），则重写rdb文件；
2) “save 300 10”表示如果每300秒内至少10个key发生变化（新增、修改和删除），则重写rdb文件；
3) “save 60 3600”表示如果每60秒内至少10000个key发生变化（新增、修改和删除），则重写rdb文件。

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /etc/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes
rdb持久化策略比较简单，下面解释一下：

save 900 1表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 300 10表示300s内有10条写入，就产生快照
下面的类似，那么为什么需要配置这么多条规则呢？因为Redis每个时段的读写请求肯定不是均衡的，为了平衡性能与数据安全，我们可以自由定制什么情况下触发备份。所以这里就是根据自身Redis写入情况来进行合理配置。

stop-writes-on-bgsave-error yes这个配置也是非常重要的一项配置，这是当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统，可以禁止此项配置， 否则请开启。

rdbcompression yes 用于配置是否压缩RDB文件，建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。

rdbchecksum yes 是否开启RDB文件的校验，在写入文件和读取文件时都起作用；关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现

dbfilename dump.rdb RDB文件名

dir ./ RDB文件和AOF文件所在目录

当然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行写上：save ""

4. 执行流程图

RDB执行流程图

1. Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof（后面会详细介绍该命令）的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。

2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令

3. 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令

4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换

5. 子进程发送信号给父进程表示完成，父进程更新统计信息

6. 客户端发送shutdown指令，系统会先执行save指令将数据持久化，然后再关闭服务器

7. 主从架构：从服务器向主服务器发送sync命令来执行复制操作时，主服务器会执行bgsave操作

5. 数据恢复 & Redis启动加载数据

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据；

只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

所以Redis的内存数据如果很大，会导致数据恢复时间比较长，因此线上实践更倾向于限制单个Redis的内存不能太大，同时结合Redis Cluster集群使用多节点部署

Redis启动日志中可以看到自动载入的执行：

RDB载入过程

Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

优点：

对于大规模数据恢复，且对于数据恢复的完整性不是非常敏感，则RDB比AOF更加高效，fork子进程性能最大化

节省磁盘空间，紧凑的压缩二进制文件

回复更加高效，启动性能更高

缺点：

生成快照时间问题，最后一次 持久化后的数据会丢失

fork子进程开销问题

消耗较大的空间，内存的数据会被复制一份

redis在fork时使用了写时拷贝技术

AOF持久化（Append Only File）

RDB快照并不是很可靠。如果你的电脑突然宕机了，或者电源断了，又或者不小心杀掉了进程，那么最新的数据就会丢失。而AOF文件则提供了一种更为可靠的持久化方式。每当Redis接受到会修改数据集的命令时，就会把命令追加到AOF文件里，当你重启Redis时，AOF里的命令会被重新执行一次，重建数据。

1.工作原理

由于需要记录Redis的每条写命令，因此AOF不需要触发， AOF的执行流程包括：

• 命令追加(append)：将Redis的写命令追加到缓冲区aof_buf；

• 文件写入(write)和文件同步(sync)：根据不同的同步策略将aof_buf中的内容同步到硬盘；

• 文件重写(rewrite)：定期重写AOF文件，达到压缩的目的。

  

  AOF执行流程

2. AOF 持久化配置

默认不开启，启动Redis默认先读取aof
# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
appendfsync always # 始终同步，每次Redis的写入都会立刻记入日志；性能较差但是数据完整性较好
appendfsync everysec  # 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
appendfsync no  # redis不主动进行同步，把同步时机交给操作系统
    
# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100 # 文件大小超过指定的百分比
auto-aof-rewrite-min-size 64mb  # 文件大小超过指定值就进行重写

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

3. AOF同步策略

同步步骤分为两步：

• Redis收到写命令后首先会追加到AOF缓冲区aof_buf，而不是直接写入文件系统，因为AOF缓冲区是内存提存的，写入速度极高，可以避免每次写入命令到硬盘，导致硬盘IO成为Redis的负载瓶颈
• 通过调用系统函数 fsync() 把AOF缓冲区的数据真正写到磁盘里面持久化。由于数据是先存储在缓冲区内存里面，如果碰到断电，宕机那么缓冲区里面的数据没来得急落盘就会丢失，因此我们必须有一个相对可靠的机制保证数据落盘。

Redis写命令写入磁盘的命令是通过appendfsync来配置的。
appendfsync 三个取值代表三种落盘策略:

• always：命令写入aof缓冲区后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈。
• no：命令写入aof缓冲区后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
• everysec：命令写入aof缓冲区后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

4. AOF文件重写(rewrite)

随着写操作的不断增加，AOF文件会越来越大。例如你递增一个计数器100次，那么最终结果就是数据集里的计数器的值为最终的递增结果，但是AOF文件里却会把这100次操作完整的记录下来。而事实上要恢复这个记录，只需要1个命令就行了，也就是说AOF文件里那100条命令其实可以精简为1条。所以Redis支持这样一个功能：在不中断服务的情况下在后台重建AOF文件。

AOF重写会先读取dump的文件

set a 1
set b 2

->
set a 1 b 2

AOF重写流程：

AOF重写流程

关于文件重写的流程，有两点需要特别注意：

(1)重写由父进程fork子进程进行；

(2)重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

对照上图，文件重写的流程如下：

1. Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。前面曾介绍过，这个主要是基于性能方面的考虑。
2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。

3.1) 父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。

3.2) 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

1. 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。

5.1) 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。

5.2) 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

5.3) 使用新的AOF文件替换老文件，完成AOF重写。

重写触发：

1. 手动触发：直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。
2. 自动触发：通过配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size来完成

auto-aof-rewrite-percentage 100 ：Redis会记住自从上一次重写后AOF文件的大小（如果自Redis启动后还没重写过，则记住启动时使用的AOF文件的大小）。如果当前的文件大小比起记住的那个大小超过指定的百分比，则会触配置发重写。

auto-aof-rewrite-min-size 64mb：同时需要设置一个文件大小最小值，只有大于这个值文件才会重写，以防文件很小，但是已经达到百分比的情况。

要禁用自动的日志重写功能，我们可以把百分比设置为0：

auto-aof-rewrite-percentage 0： 禁用日志重写功能

5. 数据恢复 & Redis启动加载数据

前面提到过，当AOF开启时，Redis启动时会优先载入AOF文件来恢复数据；

只有当AOF关闭时，才会载入RDB文件恢复数据。

当AOF开启，且AOF文件存在时，Redis启动日志：

优点：

备份机制更稳健，丢失数据概率更低

可读的日志文本，通过操作AOF文件，可以处理误操作

自动重写机制

缺点：

比RDB占用更多的磁盘空间

恢复速度慢

每次写都同步，有一定的性能压力

存在个别Bug，造成不能恢复

持久化方案选择

1. RDB和AOF的优缺点

RDB和AOF各有优缺点：

RDB持久化

• 优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。
• 缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

• 与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。

2. 性能与实践

通过上面的分析，我们都知道RDB的快照、AOF的重写都需要fork，这是一个重量级操作，会对Redis造成阻塞。因此为了不影响Redis主进程响应，我们需要尽可能降低阻塞。

• 降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
• 控制Redis最大使用内存，防止fork耗时过长；
• 使用更牛逼的硬件；
• 合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。

在线上我们到底该怎么做？我提供一些自己的实践经验。

• 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据，可以关闭持久化，如果丢失数据可以通过其它途径补回；
• 自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；
• 单机如果部署多个实例，要防止多个机器同时运行持久化、重写操作，防止出现内存、CPU、IO资源竞争，让持久化变为串行；
• 可以加入主从机器，利用一台从机器进行备份处理，其它机器正常响应客户端的命令；
• RDB持久化与AOF持久化可以同时存在，配合使用。

技术选择

1. 同时开启

Redis先加载AOF文件来恢复原始数据，因为AOF数据比RDB更完整，但是AOF存在潜在的bug，如把错误的操作记录写进了AOF，会导致数据恢复失败，所以把RDB作为后备的数据。

为了性能考虑，可以只在slave上开启RDB，并且15min备份一次，如果为了避免AOF rewrite的io以及阻塞，可以再Redis你集群中不开启AOF，靠集群的备份机制来保证可用性，在启动时选择较新的RDB文件，

2.混合模式

Redis4. 0 开始支持该模式 。

解决的问题：在重启时通常是加载 AOF 文件，但加载速度慢 。因为RDB数据不完整，所以加载AOF

开启方式：aof-use-rdb-preamble true

开启后，AOF在重写时会直接读取RDB中的内容 。

运行过程：通过bgrwriteaof完成 ，不同的是当开启混合持久化后

• 子进程会把内存中的数据以RDB的方式写入AOF中
• 把重写缓冲区中的增量命令以AOF方式写入到文件
• 将含有RDB个数和AOF个数的AOF数据覆盖旧的AOF文件

新的AOF文件中，一部分数据来自RDB文件，一部分来自Redis运行过程时的增量数据

3.动态切换

从RDB切换到AOF：

• 为最新的dump.rdb文件创建一个备份
• 将备份放到一个安全的地方

cp dump.rdb dump.rbd.bak

• 执行以下两条命令：

# 开启AOF
redis-cli config set appendonly yes
# 关闭RDB
redis-cli config set save ""

• 确保命令会被正确的最佳到AOF文件的末尾
• 执行的第一条命令开启了AOF功能：Redis会阻塞直到初始AOF文件创建完成为止，之后redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾

4.Redis容灾备份

使用脚本加定时器，实现定时备份持久化的数据文件