随笔录--Redis的持久化机制

最新推荐文章于 2024-07-21 13:20:57 发布

派大滨

最新推荐文章于 2024-07-21 13:20:57 发布

阅读量727

点赞数 7

分类专栏：随笔录文章标签： redis java mybatis python 笔记开发语言

本文链接：https://blog.csdn.net/Bigbin666/article/details/136566951

版权

随笔录专栏收录该内容

141 篇文章 0 订阅

订阅专栏

本文详细解析了Redis的RDB和AOF两种持久化机制，讨论了它们的优缺点，以及RDB-AOF混合模式的应用场景。RDB适合备份和恢复大型数据集，AOF提供更高可靠性但恢复较慢。

摘要由CSDN通过智能技术生成

Redis 的持久化机制主要分为 RDB 和 AOF 两种。

RDB 持久化机制

RDB 持久化机制是指将 Redis 在内存中的数据以快照的形式写入磁盘中，可以手动或自动执行快照操作，将数据集的状态保存到一个 RDB 文件中。

RDB 机制的优点在于：

RDB 机制适合在数据集比较大时进行备份操作，因为它可以生成一个非常紧凑、经过压缩的数据文件，对于备份、恢复、迁移数据都很方便。

RDB 机制在 Redis 重启时比 AOF 机制更快地将 Redis 恢复到内存中。

RDB 机制的缺点在于：

RDB 机制可能会出现数据丢失，因为数据是周期性地进行备份，一旦 Redis 出现问题并且上一次备份之后还没有进行过数据变更，那么这部分数据将会丢失。
RDB 机制会造成一定的 IO 压力，当数据集比较大时，进行备份操作可能会阻塞 Redis 服务器进程。

AOF 持久化机制

AOF 持久化机制是指将 Redis 在内存中的操作命令以追加的形式写入到磁盘中的 AOF 文件，AOF 文件记录了 Redis 在内存中的操作过程，只要在 Redis 重启后重新执行 AOF 文件中的操作命令即可将数据恢复到内存中。

AOF 机制的优点在于：

AOF 机制比 RDB 机制更加可靠，因为 AOF 文件记录了 Redis 执行的所有操作命令，可以确保数据不丢失。
AOF 机制在恢复大数据集时更加稳健，因为 AOF 文件记录了数据的操作过程，可以确保每一次操作都被正确地执行。

AOF 机制的缺点在于：

AOF 机制生成的 AOF 文件比 RDB 文件更大，当数据集比较大时，AOF 文件会比 RDB 文件占用更多的磁盘空间。
AOF 机制对于数据恢复的时间比 RDB 机制更加耗时，因为要重新执行 AOF 文件中的所有操作命令。

综上所述，RDB 适合用于数据集较大、备份、恢复数据和迁移数据等场景，AOF 适合用于数据可靠性要求高、数据恢复稳健等场景。

Redis 的持久化机制主要有两种：RDB（Redis Database）和 AOF（Append Only File）。

1、RDB 持久化

RDB 持久化机制会在指定的时间间隔内对数据集做快照，将快照存储到磁盘中。

RDB 的优缺点：对于数据恢复速度比较快，同时存储的文件也比 AOF 小，缺点是可能会出现数据丢失的情况，因为快照的时间间隔越长，数据丢失的可能性就越大。

2、AOF 持久化

AOF 持久化机制则会将每一次的写操作都追加到一个文件中，这个文件就是 AOF 文件。

AOF 文件保存了 Redis 服务器接收到的所有写命令，当 Redis 重启时，就可以使用 AOF 文件重建数据集。

AOF 的优缺点：数据丢失的可能性比 RDB 低，缺点是文件比 RDB 大，恢复速度比较慢。

3、RDB + AOF 混合使用

除了 RDB 和 AOF 外，Redis 还支持混合持久化机制，即同时使用 RDB 和 AOF 两种持久化机制，以此来发挥它们的优点。

在混合持久化机制中，使用 AOF 持久化机制保存每次写操作，使用 RDB 持久化机制保存指定时间点的数据快照，以此来达到数据恢复速度和数据完整性的平衡。

应用场景：

RDB 适合用于数据集比较大，数据恢复速度比较快的场景，例如备份、灾难恢复等；
AOF 适合用于数据集比较小，数据完整性比较重要的场景，例如金融、电商等行业。

Redis的持久化机制

Reids的持久化机制主要有两种，一种是 RDB 快照，指使用快照的形式将内存中的全部数据写入到磁盘中，存的是非常紧凑经过压缩的数据文件。一种是 AOF 日志，指以追加的形式，一条一条地将操作命令写入到 AOF 日志中。

优缺点：

占用空间方面：
- RDB存的是压缩过的数据集，占用空间更小
- AOF存的是每一条操作命令，占用空间更大
速度方面：
- RDB存储慢：周期性备份，每次都是内存中的全部数据，但恢复时更快
- AOF存储快：追加的形式一条条地写入，每次写入一条指令，但恢复时更慢（需执行全部指令）
安全性方面：
RDB 是周期性备份，可能会丢失没来得及备份的数据
AOF 根据策略而定，可以记录全部数据的操作过程，更可靠
资源消耗方面：
- RDB 会造成 IO 压力，数据集比较大时可能会阻塞正常的服务进程
- AOF 每次记录一条，消耗资源更低

场景：

关闭持久化：数据不敏感，且可以从其他地方重新生成找回。
RDB：数据集较大、备份、恢复数据和迁移数据等场景，可以承受数分钟级的数据丢失。
AOF：适合用于数据可靠性要求高、数据恢复稳健等场景。

补充：

AOF 的启动优先级比 RDB 高

4.0 后，多了一种混合持久化，前半段时 RDB 的全量数据，后半段是 AOF 的增量数据

优点是充分发挥了二者的优点，RDB 提供加载速度，AOF 提供数据可靠性保障

缺点是兼容性差，4.0 之前的版本不兼容，并且前半段的 RDB 可读性较差

追问：

生成 RDB 期间，Redis 可以同时处理写请求吗？

回答：

可以，Redis 使用操作系统的多进程写时复制技术 COW（Copy On Write）来实现快照持久化，保证数据一致性。

在持久化时，会调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进程处理，父进程继续处理客户端请求。当主进程执行写指令修改数据的时候，这个数据就会复制一份副本，子进程读取这个副本数据写到 RDB 文件。既保证了快照的完整性，也允许主进程同时对数据进行修改，避免了对正常业务的影响。

Redis 支持 RDB 持久化、AOF 持久化、RDB-AOF 混合持久化这三种持久化方式。

RDB：

RDB(Redis Database)是 Redis 默认采用的持久化方式，它以快照的形式将进程数据持久化到硬盘中。

RDB会创建一个经过压缩的二进制文件，文件以“.rdb”结尾，内部存储了各个数据库的键值对数据等信息。

RDB持久化的触发方式有两种：

手动触发：通过 SAVE 或 BGSAVE 命令触发 RDB 持久化操作，创建“.rdb”文件；
自动触发：通过配置选项，让服务器在满足指定条件时自动执行 BGSAVE 命令。

其中，SAVE 命令执行期间，Redis 服务器将阻塞，直到“.rdb”文件创建完毕为止。

而 BGSAVE 命令是异步版本的 SAVE 命令，它会使用 Redis 服务器进程的子进程，创建“.rdb”文件。BGSAVE 命令在创建子进程时会存在短暂的阻塞，之后服务器便可以继续处理其他客户端的请求。总之，BGSAVE 命令是针对 SAVE 阻塞问题做的优化，Redis 内部所有涉及 RDB 的操作都采用 BGSAVE 的方式，而 SAVE 命令已经废弃！

RDB 持久化的优缺点如下：

优点：RDB 生成紧凑压缩的二进制文件，体积小，使用该文件恢复数据的速度非常快；
缺点：BGSAVE 每次运行都要执行 fork 操作创建子进程，属于重量级操作，不宜频繁执行，所以 RDB 持久化没办法做到实时的持久化。

AOF：

AOF（Append Only File），解决了数据持久化的实时性，是目前 Redis 持久化的主流方式。AOF 以独立日志的方式，记录了每次写入命令，重启时再重新执行 AOF 文件中的命令来恢复数据。AOF 的工作流程包括：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

AOF持久化的优缺点如下：

优点：与 RDB 持久化可能丢失大量的数据相比，AOF 持久化的安全性要高很多。通过使用 everysec 选项，用户可以将数据丢失的时间窗口限制在1秒之内。
缺点：AOF 文件存储的是协议文本，它的体积要比二进制格式的”.rdb”文件大很多。AOF 需要通过执行 AOF 文件中的命令来恢复数据库，其恢复速度比 RDB 慢很多。AOF 在进行重写时也需要创建子进程，在数据库体积较大时将占用大量资源，会导致服务器的短暂阻塞。