Redis持久化-RDB、AOF原理与配置细节

一、前言

Redis持久化有两种方式，分别是RDB(Redis Database)和AOF(Append Only File)。在运行过程中，redis以数据结构的形式将数据维持在内存中，持久化主要是为了数据恢复，当redis崩掉或重启时，redis能读取持久化到硬盘中的数据到内存来恢复之前的状态。否则，内存中的数据丢了就没了。

持久化：将内存中的数据保存硬盘中，使数据持久存在

二、RDB(Redis Database)

1. 原理简介

RDB是每隔一段时间把当前内存中的所有数据集写入硬盘的一个文件中，当redis启动时会从这个文件中读取数据。RDB是redis的默认持久化方式。RDB在配置文件中的区域为SNAPSHOTTING。

2. 常用配置信息

redis配置文件为redis.conf，apt安装的redis配置文件路径在/etc/redis下。

1) 保存间隔(save)

默认设置有三种保存触发机制：

• 每900秒内有1次写操作
• 每300秒内有10次写操作
• 每60秒内有10000次写操作

举个例子，我在2分钟内写了13次，则在300秒时保存到本地。

Redis除了自动保存，还可以通过save命令手动保存。同时，SHUTDOWN，FLUSHALL这些操作之前也会调用自动保存到本地。

2) 持久化备份文件名(dbfilename)

默认为dump.rdb

3) 保存文件是否压缩(rdbcompression)

默认是压缩的。当缓存中数据很多时，形成的dump.rdb文件会比较大，为了减小文件大小，即在保存时按一种算法压缩文件，这样会增大些许CPU消耗。如果选择no，则可提升部分CPU性能。

4) 保存时校验文件(rdbchecksum)

默认是yes，在保存时校验rdb文件是否合法，当然，这会消耗CPU性能。也可以关闭来提升CPU性能。

5) bgsave出错时终止工作(stop-writes-on-bgsave-error)

补充：save为阻塞写入。阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
bgsave为非阻塞式写入，fork出一个子进程，子进程负责保存工作。所以redis主服务还是可以继续处理请求。但fork子进程对内存消耗较大。

在bgsave过程出错时，默认停止工作。这样能保证良好的数据一致性，如果设置成no，则bgsave出了问题后继续工作，在数据一致性不重要的环境下可以使用。

6) 持久化文件存放目录(dir)

这个好像和redis版本有关，我的版本默认路径是/var/lib/redis，有的版本是./，就是在运行目录下。所以我的dump.rdb的文件路径是/var/lib/redis/dump.rdb。同时，aof日志文件也是在这个目录下存放。

3. 优缺点

优点：

1. rdb持久化对主进程读写影响很小，因为它是fork出一个子进程来负责保存操作，写完后用新的rdb文件替换原来的旧rdb文件，可以说在任何时候dump.rdb总是完整的。
2. 适合大规模的数据恢复。
3. rdb能记录redis在不同时间点的数据集，很适合冷备份。

缺点：

1. fork子进程过程需要消耗内存量非常大，redis内存消耗几乎要翻倍
2. 如果出现宕机，丢失的数据比较多，因为rdb是每隔一段时间备份一次，间隔时间较长，一般为5分钟，所以宕机最后5分钟左右的数据未能保存到磁盘。

可能有的朋友有疑惑，为什么不把rdb备份的频率增加，比如1分钟一次而不是5分钟一次，这样丢失的数据就会少些了？因为rdb保存的过程要fork子进程，需要大量消耗内存，所以保存频率过快对性能的损耗很大。

三、AOF(Append Only File)

1. 原理简介

为了弥补RDB数据丢失过多的缺点，诞生了新的持久化技术AOF，它是在短的时间间隔内将用户的操作以Append-Only模式来追加到一个日志文件中，启动redis时直接还原这个日志文件的所有的操作就可到达之前的状态。

2. 常用配置信息

1) 是否开启AOF(appendonly)

默认不开启，如果要使用AOF功能，则切换为yes。
开启了AOF功能后，会在dir目录下多一个日志记录文件。写操作会被记录在这个文件中(读操作不影响数据库，就不用记了)，redis还原数据时再读取这个文件来执行里面的所有操作。

当RDB和AOF都开启时，redis会按照两者的策略正常产生dump.rdb和appendonly.aof文件，但启动时只会读取appendonly.aof来恢复数据。

2) AOF日志文件名(appendfilename)

默认为appendonly.aof。所以我的aof文件路径为/var/lib/redis/appendonly.aof(dir为/var/lib/redis)

3) AOF保存策略(appendfsync)

有三种保存策略，默认保存策略是每秒保存一次(everysec)。

保存方式	数据一致性	效率
每次写操作后保存	数据一致性最高，基本不会丢失数据	效率极低，CPU消耗巨大
每秒保存一次	数据一致性较高，最多丢失1s数据	效率较高
不自动保存	如果没手动保存，可能会丢光数据	未知

4) 重写条件设置(auto-aof-rewrite-*)

因为AOF日志文件是记录了每一个写操作，所以文件慢慢会变得很大。这时就要对日志文件进行重写了，比如以下代码：

set k1 1
incr k1
incr k1
incr k1
incr k1
incr k1
incr k1

其实可以重写为：

set k1 7

设置重写条件有两个参数，auto-aof-rewrite-percentage指的是新的文件大小比之前文件大小多多少百分比，默认是100，意思就是新的文件大小是原来的两倍大。
另一个参数是auto-aof-rewrite-min-size，指的是新文件大小要大于这个值，默认为64MB。这两个条件要同时满足才能触发重写操作，只满足其中一个，比如新文件大小比旧文件多了两倍，但不满足大于64MB，redis会认为这个文件仍然很小，不值得消耗CPU对它进行重写。

3. 优缺点

优点：

1. 数据完整性、一致性很高，可以精确到秒。
2. AOF以append-only的方式写入文件，效率很高。
3. appendonly.aof中记录的数据可读性比较高。

缺点：

1. appendonly.aof文件是记录每条操作日志，占用空间大。
2. 数据恢复比较慢。

四、RDB和AOF文件的修复

如果RDB和AOF文件写入过程中出了问题，可以用redis自带的修复指令修复。
比如在aof中写入日志时写一半突然宕机了，所以最后就是一段乱码，这时调用修复工具就可以将乱码去除。

redis-check-aof --fix appendonly.aof
redis-check-rdb --fix dump.rdb

五、RDB和AOF总结

• Redis默认开启RDB备份，AOF需要手动开启
• dump.rdb比appendonly.aof文件更小
• RDB恢复速度比AOF更快
• AOF的数据完整性、一致性秒杀RDB
• 如果只用redis当数据缓存，可以不开启持久化功能。
• 如果想让redis持久化，则两者都应开启。RDB做冷备和aof文件出错时的后盾。

（文章如有错误或不足之处请及时指出，谢谢大家啦！）