# Redis持久化

# 1、持久化流程

Redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，也容易发生丢失。这时Redis为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

redis的数据可以保存在磁盘上，那么这个流程是什么样的呢？主要有下面五个过程：

客户端向服务端发送写操作(数据在客户端的内存中)。
数据库服务端接收到写请求的数据(数据在服务端的内存中)。
服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。
操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中。
磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。

以上五个步骤是我们理想下的一个正常的保存流程，但是在大多数情况下，我们的机器等等都会有各种各样的故障，这里划分了两种情况：

Redis数据库发生故障，只要在上面的第三步执行完毕，那么就可以持久化保存，剩下的两步由操作系统替我们完成。
操作系统发生故障，必须上面5步都完成才可以。

所以我们现在考虑的是redis如何来实现上面5个保存磁盘的步骤。它提供了两种策略机制，也就是RDB和AOF

# 2、RDB

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。

# 2.1、优点

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。这种文件非常适合用于进行备份：比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。
RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
适合大规模的数据恢复
对数据完整性和一致性要求不高

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

# 2.2、缺点

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率，但是，因为RDB 文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少 5 分钟才保存一次 RDB 文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

Rdb 保存的是 dump.rdb 文件

# 2.3、快照规则

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。

比如"save m n"。表示m秒内数据集存在n次修改时，自动触发bgsave。

配置位置及SNAPSHOTTING解析（在第三章的相关配置中有介绍）

默认如下配置：

# 900秒（15分钟）内至少1个key值改变，才会进行保存（则进行数据库保存--持久化）
save 900 1

# 300秒（5分钟）内至少10个key值改变，才会进行保存（则进行数据库保存--持久化）
save 300 10

# 60秒（1分钟）内至少10000个key值改变，才会进行保存（则进行数据库保存--持久化）
save 60 10000

1
2
3
4
5
6
7
8

我们可以修改触发条件机制：

save 120 10 # 120秒内修改10次则触发RDB

RDB 是整合内存的压缩过的Snapshot(快照)，RDB 的数据结构，可以配置复合的快照触发条件。

默认：

1分钟内改了1万次
5分钟内改了10次
15分钟内改了1次

如果想禁用RDB持久化的策略，只要注释掉所有的 save，或者给save传入一个空字符串参数也可以。

若要修改完毕需要立马生效，可以手动使用 save 命令！立马生效 !

其余配置文件解析：

Stop-writes-on-bgsave-error：如果配置为no，表示你不在乎数据不一致或者有其他的手段发现和控制，默认为yes。

rbdcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用 LZF算法进行压缩，如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。

rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。默认为yes。

# 2.4、触发RDB快照

1、配置文件中默认的快照配置，建议多用一台机子作为备份，复制一份 dump.rdb

2、命令save或者是bgsave

save 时只管保存，其他不管，全部阻塞，执行该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止

(图片来自慕课网)

bgsave，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间。

3、执行flushall命令，也会产生 dump.rdb 文件，但里面是空的，无意义 !

4、退出的时候也会产生 dump.rdb 文件。

具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

# 2.5、修复

1、将备份文件（dump.rdb）移动到redis安装目录并启动服务即可

2、CONFIG GET dir 获取目录

127.0.0.1:6379> config get dir
dir
/usr/local/bin

1
2
3

RDB 在恢复大数据集时，速度比 AOF 的恢复速度要快。

# 3、AOF (Append Only File)

全量备份总是耗时的，Redis为我们提供了一种更加高效的持久化方式，即AOF（appendonlyfile）。此方式工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。默认情况下Redis没有开启AOF方式的持久化。

开启AOF持久化后，每执行一条更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

Aof保存的是 appendonly.aof 文件

# 3.1、开启方式

appendonly no # 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种方式在许多应用中已经足够用了

appendfilename "appendonly.aof" # appendfilename AOF 文件名称

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

No-appendfsync-on-rewrite #重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性

Auto-aof-rewrite-min-size # 设置重写的基准值

Auto-aof-rewrite-percentage #设置重写的基准值

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 3.2、AOF 启动/修复/恢复

正常恢复：

启动：设置Yes，修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录（config get dir）
恢复：重启redis然后重新加载

异常恢复：

启动：设置Yes
故意破坏 appendonly.aof文件！
修复： redis-check-aof --fix appendonly.aof进行修复
恢复：重启 redis 然后重新加载

# 3.3、AOF 重写

AOF 采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。！

重写原理：

AOF 文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再 rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，这点和快照有点类似！

触发机制：

手动触发

AOF重写可以由用户通过调用BGREWRITEAOF手动触发。

自动触发

服务器在AOF功能开启的情况下，会维持以下三个变量：

aof_current_size（记录当前AOF文件大小的变量）
aof_rewrite_base_size（记录最后一次AOF重写之后AOF文件大小的变量）
aof_rewrite_perc（增长百分比变量）

每次当serverCron函数（服务器周期性操作函数）执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：

没有BGSAVE命令（RDB持久化）/AOF持久化在执行。
没有BGREWRITEAOF在进行。
当前AOF文件大小要大于server.aof_rewrite_min_size（默认为1MB）或者在redis.conf配置的auto-aof-rewrite-min-size。
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）。

当前面三个条件已经满足，并且当前AOF文件大小比最后一次AOF重写的大小大一倍就会触发自动AOF重写。

# 4、总结

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。
RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有 AOF可能潜在的Bug，留着作为一个万一的手段。

RDB 和 AOF ，我应该用哪一个？

一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能。

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化，但我们并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。