Redis基础（三）Redis持久化：RDB与AOF

什么是Redis持久化？

Redis是键值对的内存数据库，它将数据存储在内存里。客户端发送命令到服务器，再由服务器到内存里查找数据。

一旦Redis服务器进程退出，存储在内存里的数据就会丢失。

为了解决这个问题，Redis提供了持久化机制，即将数据保存到磁盘里，以便Redis服务器进程初始化或重启后重新加载数据，避免数据丢失。

Redis提供两种持久化方案，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB持久化

RDB采用快照的方式来实现持久化，把数据库数据保存到RDB文件里，也可以通过RDB文件还原数据库数据。

开启RDB持久化的方式

RBD是Redis默认的持久化方案，可以通过三种方式来生成RDB文件：SAVE、BGSAVE和自动触发，其中前两种是主动操作，后一种是被动操作，由Redis服务器控制。

SAVE

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完成，在服务器进程阻塞期间，服务器不能处理任何命令请求。

redis> Save // 等待直到RDB文件创建完成

OK

BGSAVE

和SAVE命令直接阻塞服务器进程不同，BGSAVE命令会fork一个子进程来负责创建RDB文件，服务器进程继续处理命令请求。

redis> BGSAVE // fork子进程，并由子进程创建RDB文件

Background saving started

自动触发

Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。用户可以通过save选项设置多个条件，只要满足其中任意一个条件，服务器就会执行BGSAVE命令。

save 900 1 // 服务器在900秒内，至少1次修改

save 300 10 // 服务器在300秒内，至少10次修改

save 60 10000 // 服务器在60秒内，至少10000次修改

AOF持久化

除了RDB外，Redis还提供了AOF。与RDB通过保存数据库快照不同，AOF是通过保存命令来记录数据库数据的。默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：

# appendonly参数开启AOF持久化

appendonly no

# AOF持久化的文件名，默认是appendonly.aof

appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的

dir ./

# 同步策略

# appendfsync always

appendfsync everysec

# appendfsync no

# 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

AOF持久化实现

AOF需要记录Redis的每个命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

命令追加

当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

文件写入和同步

关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种策略：

appendfsync always：将aof_buf缓冲区中的所有内容写入并同步到AOF文件。
appendfsync everysec：将aof_buf缓冲区中的所有内容写入到AOF文件，如果上次同步AOF文件的时间距离现在超过1秒，那么两次对AOF文件进行同步，并且这个同步操作是由一个线程专门负责执行的。
appendfsync no：将aof_buf缓冲区中的所有内容写入到AOF文件，但并不对AOF文件进行同步，何时同步由操作系统来决定。

关于AOF的同步策略是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：

为了提高文件写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。

这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

AOF重写

AOF会记录每个Redis命令到AOF文件，随着时间越来越长，AOF文件会变得越来越大。如果不加以控制，会对Redis服务器，甚至对操作系统造成影响，而且AOF文件越大，数据恢复也越慢。

为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写功能来对AOF文件进行“瘦身”。Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。

RDB和AOF对比

关于RDB和AOF的优缺点，官网上面也给了比较详细的说明redis.io/topics/pers…

RDB

优点：

RDB快照是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做数据的备份，灾难恢复；
可以最大化Redis的的性能，在保存RDb文件，服务器进程只需要fork一个子进程来完成RDB文件的创建，父进程不需要做IO操作；
与AOF相比，恢复大数据集的时候会更快；

缺点：

RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，根据配置可能要几分钟才快照一次，如果服务器宕机，那么就可能丢失几分钟的数据；
Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时；

AOF

优点：

数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）；
AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复；

缺点：

对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢；
根据所使用的fsync策略，AOF的速度可能会慢于RDB。不过在一般情况下，每秒fsync的性能依然非常高；

RDB和AOF如何选择

通常来说，应该同时使用两种持久化方案，以保证数据安全。

如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化。
如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可。
如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启。

当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整。

参考资料