Redis7 实现持久化的三种方式

水深无声 2024-04-28 08:08 2阅读 0赞

## 1、概述 ##

### 1.1、Redis持久化的重要性 ###

1.  **数据恢复**：Redis是一个内存数据库，如果系统或服务宕机，内存中的数据将会丢失。Redis的持久化机制可以把数据保存到磁盘上，以便在系统重启后恢复数据。这是Redis持久化最基本也是最重要的功能。
2.  **故障恢复**：持久化机制可以帮助Redis在出现系统或数据崩溃时，安全地复原所有数据，避免可能出现的数据丢失。这对于维护企业级Web应用系统的稳定性和可用性至关重要。
3.  **保证数据一致性**：通过定期持久化，可以确保即使在数据更新频繁的情况下，也能保持数据的一致性。这对于需要保证数据准确性的应用来说是非常重要的。
4.  **支持备份和恢复**：持久化文件可以定期备份到其他存储设备，这样在遇到灾难性故障时，可以从备份中恢复数据，减少损失。

### 1.2、持久化对Redis性能的影响 ###

在选择和使用Redis的持久化机制时，需要根据实际的应用场景和需求来权衡持久化和性能之间的关系。例如，可以通过调整持久化的频率、使用更快的磁盘、优化磁盘I/O等方式来减少持久化对Redis性能的影响。同时，也需要关注Redis的监控和调优，及时发现和解决性能问题。

1.  **写操作的延迟**：由于持久化需要将数据写入磁盘，这会导致写操作有一定的延迟。特别是在使用AOF持久化时，每次写操作都需要追加到磁盘上的日志文件，这可能会增加写操作的延迟。
2.  **CPU和内存资源的占用**：在进行持久化操作时，Redis需要fork一个子进程来处理持久化任务。这个过程会消耗一定的CPU和内存资源，对Redis的性能有一定的影响。尤其是在大数据量的情况下，fork操作本身可能会消耗较多的系统资源。
3.  **磁盘I/O的影响**：持久化需要将数据写入磁盘，这会受到磁盘I/O性能的影响。如果磁盘性能较差，或者磁盘I/O负载较高，那么持久化操作可能会成为Redis性能的瓶颈。
4.  **数据恢复的时间**：在Redis重启时，需要加载持久化文件来恢复数据。这个过程可能会消耗一定的时间，导致Redis在启动时的性能下降。

### 1.3、Redis的三种持久化方式概述 ###

Redis提供了三种持久化方式，分别是RDB（Redis DataBase）持久化、AOF（Append Only File）持久化和混合持久化。下面简要概述这三种方式的工作原理和特点：

1.  RDB持久化：RDB持久化生成的快照文件是一个紧凑压缩的二进制文件，占用空间较小，适用于备份和全量复制等场景。同时，由于快照文件是完整的数据备份，因此恢复速度较快。但是，RDB持久化可能存在数据丢失的风险，因为它只保存了某个时间点的数据快照，无法记录数据的变化过程。
2.  AOF持久化：AOF持久化可以记录数据的变化过程，因此即使出现宕机等故障，也只会丢失最后一次持久化之后的数据，保证了数据的可靠性。同时，AOF文件是以文本形式存储的，易于阅读和解析。但是，AOF持久化可能会产生较大的I/O开销，并且在数据恢复时可能需要较长的时间。
3.  混合持久化：混合持久化结合了RDB和AOF两种持久化方式的优点，既保证了数据的可靠性，又提高了数据恢复的速度。但是，混合持久化可能会增加持久化文件的复杂性和管理难度。

## 2、RDB持久化 ##

RDB持久化是通过生成数据快照（Snapshot）的方式，将当前Redis进程的数据持久化到磁盘上。触发RDB持久化的方式可以是手动触发（如使用SAVE或BGSAVE命令），也可以是自动触发（如根据配置文件中指定的时间间隔和键值对数量进行触发）。

RDB持久化的方式：定时持久化（Save)、触发持久化（Save、Bgsave）。

### 2.1、RDB持久化的优缺点 ###

（1）优点：

*  数据紧凑：RDB生成的数据快照是一个紧凑的二进制文件，占用空间较小，这对于存储和传输都非常有利。
 *  恢复速度快：由于RDB文件是完整的数据备份，因此在恢复数据时，只需要加载RDB文件即可，恢复速度较快。
 *  适合备份：RDB文件非常适合用于进行备份和灾难恢复，特别是在数据量大且对恢复时间要求较高的场景下。

（2）缺点：

*  数据丢失风险：RDB持久化只能保存某个时间点的数据快照，如果Redis进程在两次快照之间宕机，那么这期间的数据变更将会丢失。因此，RDB持久化可能无法满足对数据完整性要求较高的应用。
 *  fork操作开销大：在生成RDB快照时，Redis需要fork一个子进程来进行持久化操作。这个fork操作可能会消耗较多的CPU和内存资源，对Redis的性能有一定的影响。特别是在大数据量的情况下，fork操作可能会成为性能瓶颈。
 *  版本兼容性问题：由于RDB文件使用特定二进制格式保存，因此在Redis版本更新过程中，可能存在老版本Redis服务无法兼容新版RDB格式的问题，导致数据无法正确恢复。

### 2.2、实现方式 ###

（1）自动触发  
修改Redis配置文件。

SAVE seconds changes
    // 在seconds秒内触发了changes次写操作，就自动触发持久化

（2）手动触发  
在客服端命令行中直接敲命令，redis服务器重启后失效。

SAVE // 在Redis主进程中进行数据持久化，会阻塞Redis服务器。
    BGSAVE // 开辟一个Redis服务（fork）进行同步，不会造成Redis主服务器阻塞。

### 2.3、总结 ###

1.  RDB持久化模式是**全量持久化方式**，在N秒后并且满足K条写操作，就会将这个时间段内的所有数据持久化到磁盘中的dump.rdb文件中。
2.  尽量不要吧备份文档（dump.rdb)和Redis服务器放在同一台机器上，以防止物理机损坏后备份文件也损坏。

## 3、AOF持久化 ##

AOF持久化是通过记录Redis服务器接收到的所有写操作命令，并以文本的形式追加到磁盘上的AOF文件中。当Redis重启时，会通过重新执行AOF文件中的命令来恢复数据。

![在这里插入图片描述][e5a5a7249ee648b48c60a065baa4d5c3.png]

*  Redis默认是没有开启AOF持久化的，需要在配置文件中配置：`appendonly`，改为yes重启服务就可以了。
 *  AOF文件有一个膨胀合并的操作，当AOF文件的大小达到阈值的时候就会进行命令压缩，也就是**AOF重写**。
 *  AOF缓存区会根据**写回策略**将缓存区中的命令写回磁盘AOF文件中。

### 3.1、AOF持久化的优缺点 ###

（1）优点：

*  更高的数据安全性：AOF持久化可以记录Redis服务器接收到的所有写操作命令，因此即使Redis进程意外宕机，也只会丢失最后一次持久化之后的数据，从而保证了数据的可靠性。
 *  易于数据恢复：由于AOF文件以文本形式存储了所有的写操作命令，因此在数据恢复时，只需要重新执行这些命令即可，恢复过程相对简单。
 *  对Redis性能影响较小：AOF持久化在进行写操作时，只是简单地将命令追加到AOF文件中，而不会像RDB持久化那样需要fork子进程进行数据快照的生成，因此对Redis性能的影响较小。

（2）缺点：

*  文件体积较大：由于AOF文件记录了所有的写操作命令，因此随着时间的推移，AOF文件的体积可能会变得非常大，这可能会占用大量的磁盘空间。
 *  恢复速度较慢：在Redis重启进行数据恢复时，需要逐行执行AOF文件中的命令，这可能会导致恢复速度较慢，特别是在AOF文件体积较大的情况下。
 *  可能存在数据不一致的风险：如果AOF文件在写入过程中发生错误或者损坏，可能会导致数据恢复时出现不一致的情况。此外，如果AOF文件的同步策略配置不当，也可能会导致数据丢失。

### 3.2、实现方式 ###

在 Redis 中 AOF 持久化功能默认是不开启的，需要我们修改 redis.conf 配置文件中的以下参数：

appendonly yes
    appendfilename "appendonly.aof"
    appenddirname "appendonlydir"

### 3.3、写回策略 ###

写回策略需要修改配置文件中的**appendfsync**指令。

appendfsync everysec  // 默认

1.  always：同步写回，每个命令执行完毕后立刻同步回磁盘。这种策略可以确保数据的完整性和安全性，因为即使Redis进程意外宕机，也不会丢失任何数据。但是，由于每次写操作都需要同步写回磁盘，会对Redis的性能产生一定的影响，特别是在高并发场景下。
2.  everysec：默认值，每隔一秒将缓存区中的命令写入磁盘AOF文件中。可以在一定程度上平衡数据的安全性和性能。但是，如果Redis进程在某一秒内意外宕机，那么这一秒内的数据将会丢失。
3.  no：由操作系统决定什么时候同步到磁盘中，这种策略可以最大化地提高Redis的性能，因为写回操作完全由操作系统控制，不会受到Redis进程的影响。但是，这也意味着数据的安全性完全依赖于操作系统的写回策略，如果操作系统出现故障或者宕机，可能会导致数据丢失。

### 3.4、AOF重写机制 ###

当AOF文件的大小超过所设置的阈值后，redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。  
可以在redis.conf文件中查看阈值：

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

或者手动使用命令来执行重写机制：`bgrewriteaof`。

## 4、混合持久化 ##

混合持久化是Redis 4.0之后新增的一种方式，结合了RDB和AOF的优点。在写入时，先将当前的数据以RDB的形式写入文件的开头，再将后续的操作命令以AOF的格式存入文件。这样既能保证Redis重启时的速度，又能降低数据丢失的风险。

在同时开启RDB和AOF时，Redis重启的时候只会加载AOF文件，而不会加载RDB文件，AOF文件的优先级比RDB文件的优先级高，只有AOF文件不存在的时候才会读取RDB文件。

![在这里插入图片描述][df781b9fe8234d9bac64a8e44a037fd1.png]

1.  RDB做全量持久化。
2.  AOF做增量持久化。

### 4.1、混合模式的优缺点 ###

（1）优点：

*  结合了RDB和AOF的优点：混合持久化结合了RDB持久化的数据紧凑性和AOF持久化的数据安全性，既保证了数据的可靠性，又提高了数据恢复的速度。
 *  降低了数据丢失的风险：由于混合持久化结合了AOF持久化，因此即使Redis进程在RDB快照生成之后宕机，也可以通过AOF文件来恢复数据，降低了数据丢失的风险。
 *  提高了重启速度：混合持久化在AOF文件的前半部分包含了RDB格式的全量数据，这使得Redis在重启时可以先加载RDB快照，快速恢复到宕机前的状态，然后再通过AOF文件中的增量命令来恢复后续的数据变更，从而提高了重启速度

（2）缺点：

*  AOF文件可读性变差：由于混合持久化在AOF文件的前半部分添加了RDB格式的全量数据，这使得AOF文件的可读性变差，不易于阅读和解析。
 *  版本兼容性问题：混合持久化是Redis 4.0之后引入的新特性，因此在使用混合持久化时，需要确保Redis的版本支持混合持久化。如果Redis版本过低，可能无法正确加载混合持久化生成的AOF文件。
 *  可能增加持久化文件的复杂性：混合持久化生成的AOF文件既包含了RDB格式的全量数据，又包含了AOF格式的增量命令，这使得AOF文件的结构和内容变得更加复杂。在管理和维护时可能需要更多的注意和操作。

[e5a5a7249ee648b48c60a065baa4d5c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/28/bc48f059754a44ada7bd5b7699393369.png
[df781b9fe8234d9bac64a8e44a037fd1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/28/e9bcff5468da4d7cab02ff4dc2734d8b.png