redis分布式缓存（二）一一 RDB和AOF RDB和AO

RDB和AOF

持久化流程

要有下面五个过程：

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

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

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

在这里只考虑了保存的过程可能发生的故障，其实保存的数据也有可能发生损坏，需要一定的恢复机制，不过在这里就不再延伸了。现在主要考虑的是redis如何来实现上面5个保存磁盘的步骤。它提供了两种策略机制，也就是RDB和AOF。

RDB

RDB(Redis DataBase)方式是在指定的时间间隔内将内存中数据集快照持久化到磁盘以二进制文件dump.rdb进行保存

开启RDB持久化（默认开启）

自定义配置的快照规则：

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如”save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

默认如下配置：

save 3600 1 ：表示3600秒钟内至少1个键被更改则进行快照。

save 300 100 ：表示300秒内至少100个键被更改则进行快照。

save 60 10000 ：表示60秒内至少10000个键被更改则进行快照。

如果不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能或设置为save “” 。

RDB文件保存过程

• redis调用fork,现在有了子进程和父进程。
• 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。
• 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

save、bgsave、自动化

save触发方式

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。具体流程如下：

执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。

save命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

java复制代码127.0.0.1:6379> save
OK

bgsave触发方式

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：

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

Lastsave命令返回最近一次 Redis 成功将数据保存到磁盘上的时间，以 UNIX 时间戳格式表示。

java复制代码127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> lastsave
(integer) 1632295819

自动触发方式

自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，里面有如下配置，我们可以去设置：

1. save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
2. stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难发生了。如果Redis重启了，那么又可以重新开始接收数据了
3. rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。
4. rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
5. dbfilename ：设置快照的文件名，默认是 dump.rdb
6. dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。

save与bgsave区别

因为第三种方式是配置的，所以我们对前两种进行一个对比：

RDB优点

• RDB文件紧凑，全量备份，整个Redis数据库将只包含一个文件，非常适合用于进行备份和灾难恢复。
• 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB缺点

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

如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

AOF

AOF(Append Only File).redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

每当有一个写命令过来时，就直接保存在我们的AOF文件中。

开启AOF持久化

第一步：修改redis.conf文件
将

java复制代码appendonly no
##默认持久化文件名
appendfilename "appendonly.aof"
# appendfsync always  ##每次操作都会立即写入aof文件中
##每秒持久化一次(默认配置)
appendfsync everysec
# appendfsync no   ##不主动进行同步操作，默认30s一次

修改为

java复制代码appendonly yes

第二步：指定redis.conf文件启动

java复制代码[root@172 redis-6.2.5]# ./src/redis-server  /app/redis/redis-6.2.5/redis.conf
[root@172 redis-6.2.5]#

AOF文件保存过程

redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。

保存策略

我们可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）

• appendfsync always ：每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
• appendfsync everysec ：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
• appendfsync no ：完全依赖os，性能最好,持久化没保证

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。

文件重写原理

AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。

• redis调用fork ，现在有父子两个进程
• 子进程根据内存中的数据库快照，往临时文件(新的aof文件) 中写入重建数据库状态的命令
• 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
• 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
• 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

AOF优点

• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
• AOF 文件是一个只进行追加操作的日志文件（append only log），没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损，因此对AOF文件的写入不需要进行seek，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof工具也可以轻易地修复这种问题。
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写，也不会影响客户端的读写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF文件进行追加操作
• AOF 文件有序地保存了对数据库执行的所有写入操作，这个特性非常适合做灾难性的误删除的紧急恢复。 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件， 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭fsync可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间
• AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

RDB和AOF总结

• rdb持久化
  • 是快照同步方式（按照周期性进行数据的持久化）
  • 数据可能在某时间点上宕机后存在数据丢失
  • 持久化数据效率低，二进制方式恢复数据速度快
• aof持久化
  • 是增量日志同步方式（对行为进行操作持久化数据）
  • 数据也会存在某时间节点丢失数据
  • 持久化数据效率高，以命令方式恢复数据速度慢
• 选择
  • 一般来说， 如果想达到数据安全性， 你应该同时使用两种持久化功能。
  • 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
  • 最多只会丢失一秒钟的数据使用AOF

redis分布式缓存系列

• redis分布式缓存（一）一一 redis安装(linux和docker)

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有