Redis持久化策略：RDB和AOF的优缺点和选型

Gavana.

于 2023-12-13 08:54:37 发布

阅读量1.2k

点赞数 23

分类专栏： Redis 文章标签： redis 数据库缓存持久化策略

本文链接：https://blog.csdn.net/taloyerg/article/details/134962894

版权

Redis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Redis是一款高性能的内存数据库，它可以提供多种数据结构和功能，如字符串、列表、集合、散列、有序集合、位图、HyperLogLog、地理空间索引、流等。Redis还支持事务、发布订阅、Lua脚本、Lettuce等特性，使得它可以应用于多种场景，如缓存、消息队列、排行榜、社交网络等。

但是，由于Redis的数据都存储在内存中，这也带来了一些挑战，如数据的持久化和恢复。如果Redis服务器意外宕机或重启，那么内存中的数据就会丢失，这可能会导致业务的不可用或数据的不一致。为了解决这个问题，Redis提供了两种持久化策略：RDB和AOF。本文将介绍这两种策略的原理、优缺点和选型建议，帮助您更好地使用Redis。

RDB持久化

RDB持久化是指Redis定期将内存中的数据集以二进制格式保存到磁盘上的一个文件中，这个文件就是RDB文件。RDB文件是一个压缩的快照，它记录了某个时间点的数据状态，可以用于备份、迁移或灾难恢复。

RDB持久化的触发方式有以下几种：

手动执行`SAVE`或`BGSAVE`命令。`SAVE`命令会阻塞Redis服务器，直到RDB文件创建完毕，期间Redis不能处理任何请求。`BGSAVE`命令会创建一个子进程，由子进程负责创建RDB文件，期间Redis可以继续处理请求，但不能执行`SAVE`或`BGSAVE`命令。
根据配置文件中的`save`选项，当满足一定的条件时，自动执行`BGSAVE`命令。例如，`save 60 10000`表示当60秒内有至少10000个键被修改时，自动执行`BGSAVE`命令。
当Redis执行`FLUSHALL`或`FLUSHDB`命令时，如果开启了RDB持久化，会自动执行`BGSAVE`命令。
当Redis接收到`SIGTERM`信号时，会执行`SAVE`命令，然后退出。
当主从复制时，如果从服务器执行`SYNC`命令或者`PSYNC`命令时，主服务器会执行`BGSAVE`命令，然后将RDB文件和后续的写命令发送给从服务器。

RDB持久化的优点有：

RDB文件是一个紧凑的二进制文件，占用的空间比AOF文件小，适合用于备份和传输。例如，可以将RDB文件备份到远程的存储系统中，或者用于搭建从服务器。
RDB文件的恢复速度比AOF文件快，因为只需要将文件加载到内存中，而不需要逐条执行命令。
RDB持久化的性能损耗比AOF持久化小，因为RDB持久化的频率通常比AOF持久化低，而且RDB持久化是由子进程完成的，不影响主进程的处理能力。

RDB持久化的缺点有：

RDB持久化的最大问题是数据的安全性。由于RDB文件是定期生成的，所以如果Redis服务器在两次快照之间发生故障，那么最近一次快照之后的数据就会丢失。根据不同的业务需求，数据的丢失可能是可以接受的，也可能是致命的。
RDB持久化在创建RDB文件的时候，需要执行`fork`操作，创建一个子进程。如果Redis服务器的数据量很大，那么`fork`操作可能会耗费较多的时间和内存，导致Redis服务器在某些时间点上的性能下降。特别是在高负载的情况下，`fork`操作可能会造成客户端请求的超时或失败。

AOF持久化

AOF持久化是指Redis将每个写命令都记录到一个只追加的文件中，这个文件就是AOF文件。AOF文件的内容是一个按照时间顺序的命令集合，可以用于重放，以恢复数据的状态。

AOF持久化的触发方式有以下几种：

根据配置文件中的`appendfsync`选项，有三种同步策略：

`always`：每个写命令都同步写入到AOF文件，这样可以保证不会丢失任何数据，但是性能会很差。
`everysec`：每秒钟同步一次写入到AOF文件，这样可以保证最多丢失一秒钟的数据，同时性能也比较高，这是默认的策略。
`no`：完全由操作系统决定何时同步写入到AOF文件，这样可以提供最高的性能，但是也可能会丢失不定时长的数据。

当AOF文件的大小超过配置文件中的`auto-aof-rewrite-percentage`和`auto-aof-rewrite-min-size`选项时，Redis会自动执行`BGREWRITEAOF`命令，重写AOF文件，删除冗余的命令，减少文件的大小。`BGREWRITEAOF`命令也会创建一个子进程来完成重写操作，期间Redis可以继续处理请求，但不能执行`BGSAVE`或`BGREWRITEAOF`命令。
手动执行`BGREWRITEAOF`命令，重写AOF文件。这个命令通常在AOF文件过大或者需要手动优化时使用。

AOF持久化的优点有：

AOF持久化的最大优点是数据的安全性。通过合理的同步策略，可以保证不会丢失太多的数据。即使AOF文件出现了写入错误或者损坏，也可以通过`redis-check-aof`工具来修复AOF文件，或者通过`redis-check-rdb`工具来从AOF文件中恢复RDB文件。
AOF文件的内容是可读的文本格式，方便人工查看和分析。AOF文件中的命令也可以直接用于导入导出数据，或者执行部分恢复和回滚操作。

AOF持久化的缺点有：

AOF文件的大小通常比RDB文件大，因为AOF文件记录了所有的写命令，而RDB文件只记录了数据的快照。AOF文件过大会影响重写的效率和恢复的速度，也会占用更多的磁盘空间。
AOF持久化的性能通常比RDB持久化低，因为AOF持久化需要对每个写命令进行同步操作，而RDB持久化只需要定期执行快照操作。特别是在`always`同步策略下，AOF持久化会显著降低Redis的吞吐量。

RDB和AOF的选型

根据不同的业务场景和需求，可以选择以下几种持久化方案：

只使用RDB持久化。这种方案适合数据的安全性要求不高，或者可以容忍一定程度的数据丢失的场景，例如缓存数据。这种方案的优点是性能高，文件小，恢复快，缺点是数据的安全性低，可能会丢失最近一次快照之后的数据。
只使用AOF持久化。这种方案适合数据的安全性要求高，或者不能容忍任何数据丢失的场景，例如订单数据。这种方案的优点是数据的安全性高，可以保证不会丢失太多的数据，缺点是性能低，文件大，恢复慢。
同时使用RDB和AOF持久化。这种方案适合既需要数据的安全性，又需要性能和灵活性的场景，例如用户数据。这种方案的优点是可以兼顾RDB和AOF的优点，缺点是需要维护两种文件，增加了复杂度和开销。

如果同时使用RDB和AOF持久化，那么在重启Redis服务器时，Redis会优先使用AOF文件来恢复数据，因为AOF文件记录了更多的数据。如果AOF文件不存在或者损坏，Redis会使用RDB文件来恢复数据，如果RDB文件也不存在或者损坏，Redis会启动一个空的数据库。