1、概述
1.1、Redis持久化的重要性
- 数据恢复:Redis是一个内存数据库,如果系统或服务宕机,内存中的数据将会丢失。Redis的持久化机制可以把数据保存到磁盘上,以便在系统重启后恢复数据。这是Redis持久化最基本也是最重要的功能。
- 故障恢复:持久化机制可以帮助Redis在出现系统或数据崩溃时,安全地复原所有数据,避免可能出现的数据丢失。这对于维护企业级Web应用系统的稳定性和可用性至关重要。
- 保证数据一致性:通过定期持久化,可以确保即使在数据更新频繁的情况下,也能保持数据的一致性。这对于需要保证数据准确性的应用来说是非常重要的。
- 支持备份和恢复:持久化文件可以定期备份到其他存储设备,这样在遇到灾难性故障时,可以从备份中恢复数据,减少损失。
1.2、持久化对Redis性能的影响
在选择和使用Redis的持久化机制时,需要根据实际的应用场景和需求来权衡持久化和性能之间的关系。例如,可以通过调整持久化的频率、使用更快的磁盘、优化磁盘I/O等方式来减少持久化对Redis性能的影响。同时,也需要关注Redis的监控和调优,及时发现和解决性能问题。
- 写操作的延迟:由于持久化需要将数据写入磁盘,这会导致写操作有一定的延迟。特别是在使用AOF持久化时,每次写操作都需要追加到磁盘上的日志文件,这可能会增加写操作的延迟。
- CPU和内存资源的占用:在进行持久化操作时,Redis需要fork一个子进程来处理持久化任务。这个过程会消耗一定的CPU和内存资源,对Redis的性能有一定的影响。尤其是在大数据量的情况下,fork操作本身可能会消耗较多的系统资源。
- 磁盘I/O的影响:持久化需要将数据写入磁盘,这会受到磁盘I/O性能的影响。如果磁盘性能较差,或者磁盘I/O负载较高,那么持久化操作可能会成为Redis性能的瓶颈。
- 数据恢复的时间:在Redis重启时,需要加载持久化文件来恢复数据。这个过程可能会消耗一定的时间,导致Redis在启动时的性能下降。
1.3、Redis的三种持久化方式概述
Redis提供了三种持久化方式,分别是RDB(Redis DataBase)持久化、AOF(Append Only File)持久化和混合持久化。下面简要概述这三种方式的工作原理和特点:
- RDB持久化:RDB持久化生成的快照文件是一个紧凑压缩的二进制文件,占用空间较小,适用于备份和全量复制等场景。同时,由于快照文件是完整的数据备份,因此恢复速度较快。但是,RDB持久化可能存在数据丢失的风险,因为它只保存了某个时间点的数据快照,无法记录数据的变化过程。
- AOF持久化:AOF持久化可以记录数据的变化过程,因此即使出现宕机等故障,也只会丢失最后一次持久化之后的数据,保证了数据的可靠性。同时,AOF文件是以文本形式存储的,易于阅读和解析。但是,AOF持久化可能会产生较大的I/O开销,并且在数据恢复时可能需要较长的时间。
- 混合持久化:混合持久化结合了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、总结
- RDB持久化模式是全量持久化方式,在N秒后并且满足K条写操作,就会将这个时间段内的所有数据持久化到磁盘中的dump.rdb文件中。
- 尽量不要吧备份文档(dump.rdb)和Redis服务器放在同一台机器上,以防止物理机损坏后备份文件也损坏。
3、AOF持久化
AOF持久化是通过记录Redis服务器接收到的所有写操作命令,并以文本的形式追加到磁盘上的AOF文件中。当Redis重启时,会通过重新执行AOF文件中的命令来恢复数据。
- 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 // 默认
- always:同步写回,每个命令执行完毕后立刻同步回磁盘。这种策略可以确保数据的完整性和安全性,因为即使Redis进程意外宕机,也不会丢失任何数据。但是,由于每次写操作都需要同步写回磁盘,会对Redis的性能产生一定的影响,特别是在高并发场景下。
- everysec:默认值,每隔一秒将缓存区中的命令写入磁盘AOF文件中。可以在一定程度上平衡数据的安全性和性能。但是,如果Redis进程在某一秒内意外宕机,那么这一秒内的数据将会丢失。
- 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文件。
- RDB做全量持久化。
- 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文件的结构和内容变得更加复杂。在管理和维护时可能需要更多的注意和操作。