Redis学习笔记系列(八)——Redis持久化

6. Redis持久化

由于Redis是内存数据库，如果Redis实例宕机或者服务器断电，则重启后，Redis中的数据会全部丢失。因此，Redis为了防止该情况，提供了两种持久化的方案——RDB和AOF，将内存中的数据保存到磁盘中，避免数据的丢失。

6.1 RDB持久化

RDB持久化方案，指的是将某一时刻Redis实例的状态拍一个快照，以二进制文件的形式保存至磁盘中。在 Redis 重启动时， RDB 程序可以通过载入 RDB 文件来还原数据库的状态。这个过程可以手动执行，也可以在redis.conf文件中配置，定期执行。
RDB持久化通过SAVE和BGSAVE命令将Redis的状态保存为一个二进制文件，而Redis实例启动的时候，会自动加载RDB二进制文件，已恢复数据库的状态。下面，介绍下SAVE和BGSAVE两者的异同点。

• 相同点：
  两个命令都会调用 rdbSave() 函数。该函数负责将内存中的数据库数据以 RDB 格式保存到磁盘中， 如果 RDB 文件已存在， 那么新的 RDB 文件将替换已有的 RDB 文件。
• 不同点：
  SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕。
  BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。

BGSAVE可以在不阻塞主进程的情况下完成数据的备份。可以通过redis.conf中设置多个自动保存条件，只要有一个条件被满足，服务器就会执行BGSAVE命令。示例：

# 900s内有1次修改便执行RDB
save 900 1
# 300s内有10次修改便执行RDB
save 300 10
# 60s内有10000次修改便执行RDB
save 60 10000

6.2 AOF持久化

AOF持久化是以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。AOF持久化功能是默认关闭的，如需打开，需要将配置文件redis.conf中appendonly no 修改为 appendonly yes。

注意：如果服务器在启动时， 打开了 AOF 功能， 那么程序优先使用 AOF 文件来还原数据。 只有在 AOF 功能未打开的情况下， Redis 才会使用 RDB 文件来还原数据。

开启AOF之后，在进行Redis写操作的时候就会自动将命令保存到文件(默认appendonly.aof)中。写文件的频率可以通过appendfsync项进行配置，有以下三种策略：

• always：将缓存区的内容总是即时写到AOF文件中。
• everysec：将缓存区的内容每隔一秒写入AOF文件中。
• no ：写入AOF文件中的操作由操作系统决定，一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。

Redis默认使用的是everysec，这是兼顾性能和安全性的保存方案，只会丢失最多2s的数据，性能又不会太差。

AOF重写

AOF文件通过同步 Redis 服务器所执行的命令， 从而实现了数据库状态的记录， 但是， 这种同步方式会造成一个问题： 随着运行时间的流逝， AOF 文件会变得越来越大。因此，AOF重写功能会首先读取数据库中现有的键值对状态，然后根据类型使用一条命令来替代之前的键值对多条命令。因此，重写工作是针对数据库的当前值来进行的，程序既不读写、也不使用原有的 AOF 文件。

注意，AOF是一个后台进程，不会阻塞服务端处理客户端的请求，这样做带来的好处是：

1. 子进程进行 AOF 重写期间，主进程可以继续处理命令请求。
2. 子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。

但是，这又带来了一个新的问题——在AOF重写的过程，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。因此Redis还设置了一个AOF重写缓冲区，这个缓冲区在子进程被创建开始之后开始使用，这个期间，所有的命令会被存两份，一份在AOF缓冲空间，一份在AOF重写缓冲区，当AOF重写完成之后，子进程发送信号给主进程，通知主进程将AOF重写缓冲区的内容添加到AOF文件中。

AOF主进程重写AOF过程

换言之， 当子进程在执行 AOF 重写时， 主进程需要执行以下三个工作：

1. 处理命令请求。
2. 将写命令追加到现有的 AOF 文件中。
3. 将写命令追加到 AOF 重写缓存中。

这样一来可以保证：

1. 现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。
2. 所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。

当子进程完成 AOF 重写之后， 它会向父进程发送一个完成信号， 父进程在接到完成信号之后， 会调用一个信号处理函数， 并完成以下工作：

1. 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
2. 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。

6.3 RDB VS AOF

• RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。
• AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 但更完整。

6.4 相关配置选项

# 注释掉 `save` 这一行配置项就可以让保存数据库功能失效
# 设置redis进行数据库镜像的频率。
# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 900 1
save 300 10
save 60 10000

# 当rdb持久化出现错误后，是否依然进行继续进行工作，
# yes：不能进行工作，
# no：可以继续进行工作，
# 可以通过info中的rdb_last_bgsave_status了解RDB持久化是否有错误
stop-writes-on-bgsave-error yes

# 使用压缩rdb文件
# yes：压缩，但是需要一些cpu的消耗
# no：不压缩，需要更多的磁盘空间
rdbcompression yes

# 是否校验rdb文件
rdbchecksum yes

# rdb文件的名称
dbfilename dump.rdb

# 数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir /var/lib/redis

# 默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。
# 但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化。
# Append Only File是另一种持久化方式，可以提供更好的持久化特性。
# Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，
# 每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendonly yes

# aof文件名
appendfilename "appendonly.aof"

# aof持久化策略的配置
# no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
# always表示每次写入都执行fsync，以保证数据同步到磁盘。
# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec

# 在aof重写或者写入rdb文件的时候，会执行大量IO。
# 此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，
# no-appendfsync-on-rewrite字段设置为默认设置为no。
# 如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，
# 这样对持久化特性来说这是更安全的选择。
# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,
# 等rewrite完成后再写入。Linux的默认fsync策略是30秒。可能丢失30秒数据。
no-appendfsync-on-rewrite no

# aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，
# 即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，
# 自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100

# 设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

# aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。
# 重启可能发生在redis所在的主机操作系统宕机后，
# 尤其在ext4文件系统没有加上data=ordered选项(redis宕机或者异常终止不会造成尾部不完整现象)。
# 出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。
# 如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。
# 如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes

写在最后

如果你觉得我写的文章帮到了你，欢迎点赞、评论、分享、赞赏哦，你们的鼓励是我不断创作的动力～