为什么要持久化

Redis是个基于内存的数据库。那服务一旦宕机，内存中的数据将全部丢失。通常的解决方案是从后端数据库恢复这些数据，但后端数据库有性能瓶颈，如果是大数据量的恢复，1、会对数据库带来巨大的压力，2、数据库的性能不如Redis。导致程序响应慢。所以对Redis来说，实现数据的持久化，避免从后端数据库中恢复数据，是至关重要的。

Redis 提供的2个持久化方式

  • RDB（Redis DataBase）

  • AOF（Append Of File）

    RDB

    RDB 就是 Redis DataBase 的缩写，中文名为快照/内存快照，RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。
    RDB默认就是开启的。

    备份是如何执行的

    Redis 会单独创建（fork）一个子进程来进行持久化，首先会将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。
    RDB 的缺点是最后一次持久化后的数据可能丢失。

    Fork

    Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
    在 Linux 程序中，fork 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”。
    一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

    dump.rdb 文件

    在 redis.conf 中配置文件名称，默认为 dump.rdb。
    rdb 文件的保存路径，也可以修改。默认为 Redis 启动时命令行所在的目录下

    触发方式

    触发rdb持久化的方式有2种，分别是手动触发和自动触发。

    手动触发

  • save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用

  • bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
  • 可以通过 lastsave 命令获取最后一次成功执行快照的时间

bgsave流程图
image.png
具体流程如下：

  • redis客户端执行bgsave命令或者自动触发bgsave命令；
  • 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；
  • 如果不存在正在执行的子进程，那么就fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其他操作；
  • 子进程先将数据写入到临时的rdb文件中，待快照数据写入完成后再原子替换旧的rdb文件；

  • 同时发送信号给主进程，通知主进程rdb持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）。

    自动触发

    以下4种情况自动触发

  • redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；

  • 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
  • 执行debug reload命令重新加载redis时也会触发bgsave操作；
  • 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；

    redis.conf中配置RDB

    快照周期：内存快照虽然可以通过技术人员手动执行SAVE或BGSAVE命令来进行，但生产环境下多数情况都会设置其周期性执行条件。 ```shell

    周期性执行条件的设置格式为

    save

默认的设置为：如果900秒内有1条Key信息发生变化，则进行快照

save 900 1 save 300 10 save 60 10000

以下设置方式为关闭RDB快照功能

save “”

  1. 其他相关设置
  2. ```shell
  4. # RDB文件在磁盘上的名称
  5. dbfilename dump.rdb
  7. # RDB文件的存储路径。默认设置为“./”，也就是Redis服务的主目录
  8. dir /home/work/app/redis/data/
  10. # 如果持久化出错，主进程是否停止写入
  11. #上文提到的在快照进行过程中，主进程照样可以接受客户端的任何写操作的特性，是指在快照操作正常的情况下。
  12. #如果快照操作出现异常（例如操作系统用户权限不够、磁盘空间写满等等）时，Redis就会禁止写操作。
  13. #这个特性的主要目的是使运维人员在第一时间就发现Redis的运行错误，并进行解决。
  14. #一些特定的场景下，您可能需要对这个特性进行配置，这时就可以调整这个参数项。该参数项默认情况下值为yes，如果要关闭这个特性，指定即使出现快照错误Redis一样允许写操作，则可以将该值更改为no。
  15. stop-writes-on-bgsave-error yes
  17. # 是否压缩，该属性将在字符串类型的数据被快照到磁盘文件时，启用LZF压缩算法。Redis官方的建议是请保持该选项设置为yes
  18. rdbcompression yes
  20. # 导入时是否检查
  21. rdbchecksum yes

RDB优缺点

优点

  • 适合大规模的数据恢复
  • 对数据完整性和一致性要求不高更适合使用
  • 节省磁盘空间

  • 恢复速度快

    缺点

  • Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑。

  • 虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。
  • 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。

    AOF

    以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
    Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。 而AOF日志采用写后日志，即先写内存，后写日志。

    AOF持久化流程

  1. 客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
  2. AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；
  3. AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；
  4. Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

image.png

持久化策略

image.png

  • Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
  • Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
  • No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

    redis.conf中配置AOF

    默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下： ```shell

    appendonly参数开启AOF持久化，默认情况下AOF功能是关闭的，将该选项改为yes以便打开Redis的AOF功能

    appendonly no

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

appendfilename “appendonly.aof”

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

dir ./

同步策略

这个参数项是AOF功能最重要的设置项之一，主要用于设置“真正执行”操作命令向AOF文件中同步的策略。

#

什么叫“真正执行”呢？还记得Linux操作系统对磁盘设备的操作方式吗？

为了保证操作系统中I/O队列的操作效率，应用程序提交的I/O操作请求一般是被放置在linux Page Cache中的，然后再由Linux操作系统中的策略自行决定正在写到磁盘上的时机。

而Redis中有一个fsync()函数，可以将Page Cache中待写的数据真正写入到物理设备上，而缺点是频繁调用这个fsync()函数干预操作系统的既定策略，可能导致I/O卡顿的现象频繁 。

appendfsync参数项可以设置三个值，分别是：always、everysec、no，默认的值为everysec。

appendfsync always

appendfsync everysec

appendfsync no

aof重写期间是否同步

always和everysec的设置会使真正的I/O操作高频度的出现，甚至会出现长时间的卡顿情况，这个问题出现在操作系统层面上，所有靠工作在操作系统之上的Redis是没法解决的。

为了尽量缓解这个情况，Redis提供了这个设置项，保证在完成fsync函数调用时，不会将这段时间内发生的命令操作放入操作系统的Page Cache（这段时间Redis还在接受客户端的各种写操作命令）。

no-appendfsync-on-rewrite no

重写触发配置

上文说到在生产环境下，技术人员不可能随时随地使用“BGREWRITEAOF”命令去重写AOF文件。

所以更多时候我们需要依靠Redis中对AOF文件的自动重写策略。Redis中对触发自动重写AOF文件的操作提供了两个设置：auto-aof-rewrite-percentage表示如果当前AOF文件的大小超过了上次重写后AOF文件的百分之多少后，就再次开始重写AOF文件。

例如该参数值的默认设置值为100，意思就是如果AOF文件的大小超过上次AOF文件重写后的1倍，就启动重写操作。

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

加载aof出错如何处理

aof-load-truncated yes

文件重写策略

aof-rewrite-incremental-fsync yes ```

重写机制

AOF会记录每个写命令到AOF文件，随着时间越来越长，AOF文件会变得越来越大。如果不加以控制，会对Redis服务器，甚至对操作系统造成影响，而且AOF文件越大，数据恢复也越慢。为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写机制来对AOF文件进行“瘦身”。

Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。
image.png
AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写 (也是先写临时文件最后再 rename)，redis4.0 版本后的重写，是指把 rdb 的快照，以二进制的形式附在新的 aof 头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ，不写入 aof 文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
如果 no-appendfsync-on-rewrite=no，还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis 要满足一定条件才会进行重写。
auto-aof-rewrite-percentage：设置重写的基准值，文件达到 100% 时开始重写（文件是原来重写后文件的 2 倍时触发）。
auto-aof-rewrite-min-size：设置重写的基准值，最小文件 64MB。达到这个值开始重写。
系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size,
如果 Redis 的 AOF 当前大小 >= base_size +base_size*100% (默认) 且当前大小 >=64mb (默认) 的情况下，Redis 会对 AOF 进行重写。
例如：文件达到 70MB 开始重写，降到 50MB，下次什么时候开始重写？100MB

重写流程

bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行；
主进程 fork 出子进程执行重写操作，保证主进程不会阻塞；
子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失；
子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件；
使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写。

RDB和AOF混合方式

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。


这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。
如下图所示，T1 和 T2 时刻的修改，用 AOF 日志记录，等到第二次做全量快照时，就可以清空 AOF 日志，因为此时的修改都已经记录到快照中了，恢复时就不再用日志了。
image.png
这个方法既能享受到 RDB 文件快速恢复的好处，又能享受到 AOF 只记录操作命令的简单优势, 实际环境中用的很多。

从持久化中恢复数据

数据的备份、持久化做完了，我们如何从这些持久化文件中恢复数据呢？如果一台服务器上有既有RDB文件，又有AOF文件，该加载谁呢？
想要恢复数据，只需要重启Redis，把备份数据文件放在Redis配置的目录里面，默认就是启动目录，恢复数据的流程如下：
image.png

  • redis重启时判断是否开启aof，如果开启了aof，那么就优先加载aof文件；
  • 如果aof存在，那么就去加载aof文件，加载成功的话redis重启成功，如果aof文件加载失败，那么会打印日志表示启动失败，此时可以去修复aof文件后重新启动；
  • 若aof文件不存在，那么redis就会转而去加载rdb文件，如果rdb文件不存在，redis直接启动成功；
  • 如果rdb文件存在就会去加载rdb文件恢复数据，如加载失败则打印日志提示启动失败，如加载成功，那么redis重启成功，且使用rdb文件恢复数据；

那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。