目录

# 概念

1. RDB持久化

1.1 备份是如何执行的（RDB过程）

1.2 配置文件信息

1.3 RDB持久化操作

1.4 RDB优势

1.5 RDB劣势

1.6 RDB做备份

2. AOF持久化

2.1 AOF开启及使用

2.2 异常恢复

2.3 配置文件操作

2.4 AOF持久化流程

2.5 优点

2.6 劣势

---

# 概念

• redis持久化概念

  redis是我们的内存数据，存在内存中的，但是redis也可以写道硬盘中去，这个过程就叫持久化；

• RDB与AOF的优先级

  AOF和 RDB 同时开启，系统默认取 AOF的数据（数据不会存在丢失）；

1. RDB持久化

• 概念

  就是在指定的时间间隔中将内存中的数据集快照写入到磁盘中（硬盘是磁盘的一种），比如每个10秒写入一次，再过10秒写入一次等；

1.1 备份是如何执行的（RDB过程）

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

• Fork：

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

  在 Linux 程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了“写时复制技术”；

  一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程；

dump.rdb文件：

1.2 配置文件信息

配置文件存在：vim /etc/redis.conf

一、stop-writes-on-bgsave-error yes（当redis无法写入磁盘，直接关闭redis写操作，推荐yes）

二、rdbcompression yes（对于存储到磁盘中的快照，设置是否进行压缩存储）

对于存储到磁盘中的快照，设置是否进行压缩存储。如果是，redis会采用LZF算法进行压缩；

如果不想消耗CPU进行压缩，可以设置为关闭此功能，推荐yes；

三、rdbchecksum检查完整性（存储快照后让redis使用CRC64算法进行数据校验）

推荐yes；

四、Save秒钟（写操作次数）

• 在 Redis 的配置文件中，save 命令用于配置数据库的 RDB（Redis Database）持久化策略。它定义了在特定时间间隔内，如果发生了一定数量的键改变，Redis 将触发持久化操作，将数据保存到磁盘中。

这三条配置定义了 Redis 在以下条件下触发持久化的规则：

1. save 900 1:
   • 时间间隔: 900秒（15分钟）。
   • 键改变数量: 至少1个键。
   • 解释: 如果在900秒内，至少有1个键发生了变化（被修改、删除或新增），Redis 将触发一次持久化操作，将数据保存到磁盘。
2. save 300 10:
   • 时间间隔: 300秒（5分钟）。
   • 键改变数量: 至少10个键。
   • 解释: 如果在300秒内，至少有10个键发生了变化，Redis 将触发一次持久化操作，将数据保存到磁盘。
3. save 60 10000:
   • 时间间隔: 60秒（1分钟）。
   • 键改变数量: 至少10000个键。
   • 解释: 如果在60秒内，至少有10000个键发生了变化，Redis 将触发一次持久化操作，将数据保存到磁盘。

• 运行原理

  Redis 会在后台持续监视键的变化。如果在指定的时间间隔内键的变化次数达到设置的数量，Redis 就会创建一个 RDB 快照。这个快照包含当前数据库状态的一个副本并将其写入磁盘，以便于恢复数据。配置多个 save 条目可以根据不同的条件灵活地触发持久化操作。

• 配置的意义和影响

  • 灵活的持久化策略: 不同时间间隔和键改变数量的配置使得 Redis 能够灵活处理持久化操作。在频繁变化的情况下（如 save 60 10000），它能快速保存数据；而在变化较少的情况下（如 save 900 1），则不会频繁触发持久化，减少性能开销。
  • 数据持久化: 这些配置确保了 Redis 的数据能够定期持久化到磁盘中，以防止数据丢失。
  • 性能权衡: 更频繁的持久化会导致更多的磁盘 I/O，从而影响性能；而较少的持久化则可能在崩溃时导致更多的数据丢失。

五、save VS bgsave

• save：

  工作机制：

  • 同步操作: save 是一个同步操作，阻塞当前 Redis 实例，直到保存过程完成。
  • 数据持久化: 它会生成一个 RDB (Redis Database) 快照文件，将当前的内存数据保存到磁盘。

  优缺点：

  • 优点: 操作简单，适合在 Redis 启动期间使用，确保启动时的数据被持久化。
  • 缺点: 由于是同步操作，期间 Redis 将不能处理其他请求，可能导致性能问题，尤其在数据量大时。

  典型使用场景：

  • 紧急保存: 在进行数据恢复操作之前确保数据不丢失。
  • 开发和调试: 当需要手动触发保存数据以查看具体状态时。

  示例：SAVE

• bgsave：

  工作机制：

  • 异步操作: bgsave 是一个异步操作，Redis 主进程会 fork 一个子进程来执行数据持久化。
  • 数据持久化: 子进程会生成一个 RDB 快照文件，将当前的内存数据保存到磁盘，而主进程继续处理客户端的请求。

  优缺点：

  • 优点: 不阻塞 Redis 主进程，允许 Redis 继续处理其他请求，适合在运行时定期保存数据。
  • 缺点: fork 操作在数据量大时可能会占用较多的系统资源，并且对系统内存开销较大。

  典型使用场景：

  • 定期备份: 在运行时定期进行数据备份，减少持久化对性能的影响。
  • 大规模应用: 适合需要频繁持久化数据且不希望阻塞请求处理的大规模应用。

  示例：BGSAVE

• 主要区别总结

特性	save	bgsave
操作模式	同步	异步
阻塞行为	阻塞	非阻塞
系统资源	较少	较多
执行时机	手动	手动或自动配置
性能影响	高	低

1.3 RDB持久化操作

设置key：

写入后查询（证明做了持久化操作）：

1.4 RDB优势

适合大规模的数据恢复；

对数据完整性和一致性要求不高更适合使用；

节省磁盘空间；

恢复速度快；

1.5 RDB劣势

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

虽然 Redis.在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；

在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话就会丢失最后一次快照后的所有修改；

1.6 RDB做备份

我们在移除前先做一个插入操作，以上操作后重新启动redis，在删除dump文件后，进入复制的文件中查看，这时候就有之前设置的3个key了（save 20 3）这个是备份恢复过程；

2. AOF持久化

• 概念

  （Append Only File：在redis中的另一种持久化的方式）

  以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行-次以完成数据的恢复工作；

2.1 AOF开启及使用

开启后就会有默认文件：appendonly yes

使用（在开启完后在redis中set入值，这时候文件的大小发生了变化 ）

2.2 异常恢复

修改默认的 appendonly no，改为 yes；

如遇到 AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof 进行恢复；

作用：备份被写坏的 AOF 文件；

恢复：重启 redis，然后重新加载；

2.3 配置文件操作

1. AOF同步步率设置

appendfsync always：始终同步，每次Redis的写入都会立刻记入日志；虽然性能较差，但数据完整性比较好；

appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失；

appendfsync no：redis不主动进行同步，把同步时机交给操作系统；

2. rewrite压缩

• rewrite是什么：

  AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩 ， 只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof；

• 重写原理，如何实现重写：

  AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写（也是先写临时文件最后rename），redis4.0 版本后的重写，是指上就是把 rdb 的快照，以二级制的形式附在新的 aof头部，作为已有的历史数据，替换掉原来的流水账操作；

3. no-appendfsync-on-rewrite ：AOF 是否继续同步数据到磁盘

在 Redis 中，no-appendfsync-on-rewrite 配置选项，与 AOF（Append Only File）持久化和 RDB（Redis Database）持久化的相互作用相关。这个选项控制了在执行 RDB 快照的同时，AOF 是否继续同步数据到磁盘；

no-appendfsync-on-rewrite 的值为 no 时（默认情况）：

• AOF 重写期间继续 ****fsync: 在进行 RDB 持久化（快照）或 AOF 重写时，Redis 将继续按照 appendfsync 配置进行 fsync 操作，将 AOF 缓冲区中的数据同步到磁盘。
• 保持 AOF 持久化的完整性: 即使在进行快照或 AOF 重写期间，也不会延迟或暂停 AOF 文件的同步操作，确保 AOF 文件的实时性和数据完整性。

no-appendfsync-on-rewrite 的值为 yes 时：

• AOF 重写期间暂停 ****fsync: 在进行 RDB 持久化或 AOF 重写时，Redis 会暂停 fsync 操作。这意味着在持久化操作期间，AOF 文件的数据不会实时同步到磁盘。
• 降低磁盘 I/O 负载: 通过暂停 fsync，可以减轻磁盘 I/O 负载，减少系统压力和潜在的性能影响，适合 I/O 密集型应用或磁盘性能有限的环境。

2.4 AOF持久化流程

（1）客户端的请求写命令会被append追加到 AOF 缓冲区内；

（2）AOF缓冲区根据 AOF持久化策略[always,everysec,no]将操作sync 同步到磁盘的AOF文件中;

（3）AOF文件大小超过重写策略或手动重写时，会对 AOF 文件rewrite 重写，压缩AOF 文件容量；

2.5 优点

备份机制更稳健，丢失数据概率更低；

可读的日志文本，通过操作 AOF文件，可以处理误操作；

2.6 劣势

比起 RDB 占用更多的磁盘空间；

恢复备份速度要慢；

每次读写都同步的话，有一定的性能压力；

存在个别 Bug，造成不能恢复；