Redis从入门到放弃（6）：持久化

文章目录

• 1、引言
• 2、RDB持久化

• 2.1、手动触发
• 2.2、自动触发

• 3、AOF持久化

• 3.1、触发方式
• 3.2、AOF重写

• 4、混合持久化
• 5、RDB与AOF的优缺点对比

• 5.1、RDB
• 5.2、AOF

1、引言

Redis作为一种高性能的内存数据存储系统，常被用作缓存、会话存储、消息队列等多种应用场景。然而，由于其数据存储在内存中，一旦发生意外或服务器重启，数据就会丢失。为了保障数据的持久性和安全性。

Redis提供了多种持久化方案：

• RDB（Redis DataBase）：按指定的时间间隔执行数据集的时间点快照。
• AOF（Append Only File）：记录服务器收到的每个写入操作。
• RDB + AOF：您还可以在同一实例中组合 AOF 和 RDB。

本文将探究以上三种持久化技术的工作原理、优缺点以及适用场景。

2、RDB持久化

RDB是Redis的默认持久化方式。它通过定期或手动执行快照将内存中的数据保存到磁盘上（dump.rdb）。触发RDB持久化过程分为手动触发和自动触发。

• 手动触发：可通过SAVE和BGSAVE命令完成。
• 自动触发：通过redis.conf文件增加save配置项完成，本质还是执行得BGSAVE命令。

那么SAVE和BGSAVE两个命令有什么区别呢？

SAVE：主线程操作，同步执行，会阻塞其它命令的执行。执行[save]命令时，RDB快照生成如果时间过长，后续请求会被阻塞，客户端新发送所有命令都会被拒绝。因此在生产环境中要谨慎使用该命令，避免影响服务的正常运行。

BGSAVE：写时复制，异步执行，不会阻塞其它命令的执行，会fork一个子进程进行操作，但这样比较消耗内存。主进程依旧保持与客户端的连接，正常执行读写命令。

2.1、手动触发

SAVE命令使用方法：

127.0.0.1:6379> SAVE

BGSAVE使用方法：

127.0.0.1:6379> BGSAVE

2.2、自动触发

RDB自动触发指的是通过在Redis的配置文件中设置特定的条件，使得Redis能够在满足这些条件时自动进行RDB持久化，而无需手动干预。这样可以确保数据定期地被保存到磁盘上，从而避免过多的数据丢失。

在Redis的配置文件redis.conf中，可以使用save配置项来设置RDB自动触发的条件。

save <seconds> <changes>

其中<seconds>表示多少秒内发生了<changes>次写操作，就会触发一次自动的RDB持久化。

可以设置多个save规则，每个规则独占一行，Redis会按照配置的顺序进行判断。例如：

save 900 1
save 300 10
save 60 10000

上述配置的意思分别是：在900秒内发生了至少1次写操作、在300秒内发生了至少10次写操作、在60秒内发生了至少10000次写操作时，Redis会自动触发RDB持久化。

3、AOF持久化

AOF持久化（Append Only File）以追加日志的形式记录Redis每个写操作并写入到一个文件中，即【appendonly.aof】文件。

AOF持久化过程可以简述如下：

1. 写入操作记录：当Redis执行写操作时（如SET、INCR等），写入命令会追加到aof_buff（缓冲区）中。
2. 文件同步：AOF缓冲区会根据配置定期进行同步到磁盘。
3. AOF重写：为了避免AOF文件过大，Redis会定期进行AOF重写，达到压缩文件得目的。

3.1、触发方式

在redis.conf配置文件中，开启配置（默认不开启）：

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

持久化频率配置：

appendfsync always    # 每个写命令都同步，新的命令追加到aof文件，慢但安全

appendfsync everysec  # 每秒同步一次，丢失概率小

appendfsync no        # 从不主动同步，交给操作系统决定何时同步

3.2、AOF重写

当满足触发条件时，Redis会扫描整个实例的数据，重新生成一个AOF文件来完成一些多余命令的过滤，从而削减了文件大小。

重写流程：主进程fork出一个子进程进行AOF文件的重写，子进程重写完毕后，主进程把子进程重写期间，其他客户端产生的写请求，追加到AOF文件中，替换旧文件。

重写是如何缩减文件大小的，如：

• 进程内已经超时的数据不再写入文件。
• 旧的AOF文件含有无效命令，如del key1、hdel key2等。重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
• 多条写命令可以合并为一个。

AOF有两种触发方式：

• 手动触发：直接调用bgrewriteaof命令。
• 自动触发：redis.config配置如下

auto-aof-rewrite-percentage 100    # 百分比，AOF文件的增长率达到

auto-aof-rewrite-min-size 64mb     # AOF文件大小达到多少

上述配置的含义是，当AOF文件大小增长到当前AOF文件大小的100%时，Redis会自动触发AOF重写操作；同时，AOF文件大小至少达到64MB时，才会执行AOF重写。

4、混合持久化

在Redis4.0后新增了一种混合模式：RDB+AOF，将两者的优点进行整合，混合方式采用AOF方式记录数据的变化，采用RDB的方式进行二进制文件存储。也就是在写入的时候先把数据以RDB的形式写入文件的开头，再将后续的写命令以AOF格式追加到文件中。

redis.conf开启配置如下：

# 混合持久化开关
aof-use-rdb-preamble yes

5、RDB与AOF的优缺点对比

5.1、RDB

优点：

• 性能高：对Redis的性能影响较小，适用于要求高性能的场景。
• 适用于备份：生成的快照文件紧凑且压缩，适合用于备份和灾难恢复。

缺点：

• 数据丢失：定期生成快照，如果Redis发生故障，最后一次快照后的数据会丢失。
• 不适用于大规模数据：对于大规模数据集，可能导致长时间阻塞。

5.2、AOF

优点：

• 更高的数据安全性：记录每个写操作，数据更可靠，适用于要求数据实时持久性的场景。
• 数据可读性：AOF文件以易读的文本格式记录，方便查看和理解。

缺点：

• 相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB
• AOF文件较大：随着写操作的增加，AOF文件会变得庞大。

综合来看，对于不同的应用场景，可以根据需求选择适合的持久化方式。RDB持久化适用于要求高性能和定期备份的场景；AOF持久化适用于要求数据实时持久性和较高数据安全性的场景；混合持久化则可以在兼顾数据实时性和备份需求的同时，提供更好的性能和数据保护。在配置持久化时，建议根据具体业务需求，综合考虑数据安全性、性能、存储空间等因素，选择合适的持久化策略。