当前位置：首页 > 问答 > 正文

Redis怎么配置才能实现数据不丢失，永久保存那些东西的方案讲解

Redis作为一个内存数据库，所有数据默认都保存在内存里，内存的特点是读写速度极快，但一旦服务器断电或进程崩溃，内存中的数据就会全部丢失，这与我们熟悉的MySQL等将数据直接写入硬盘的数据库有根本区别，所谓的“永久保存”，实质上是如何将内存中的数据持久化到硬盘上,并在需要时能够从硬盘恢复回来。

Redis官方提供了两种主要的持久化机制，分别是RDB和AOF，你可以选择只使用其中一种，或者结合使用,以达到不同的数据安全级别。

第一种方案：RDB（快照）方式 （根据Redis官方文档关于RDB的说明）

RDB就像是给Redis的数据拍一张某一时刻的全量照片，Redis会定期将内存中所有数据的完整副本，压缩后保存到一个名为dump.rdb的二进制文件中。

如何配置RDB？ 在Redis的配置文件redis.conf中,你可以找到类似下面的配置行：

save 900 1
save 300 10
save 60 10000

这三行是RDB的核心配置,它们的意思是：

你可以根据自己对数据丢失的容忍度来调整这些参数，如果你觉得数据丢失一分钟是可以接受的，那么保留save 60 10000这一条就足够了，如果你希望更频繁地备份，可以设置更短的时间和更少的键变化数量，比如save 30 5。

RDB的优点和缺点：

优点：
1. 性能影响小：因为是通过创建子进程来生成快照，主进程可以继续处理命令,对服务性能影响相对较小。
2. 文件紧凑：RDB文件是压缩后的二进制文件，非常紧凑,适合用于灾难恢复和远程备份。
3. 恢复速度快：恢复大数据集时,比AOF方式要快得多。
缺点：
1. 可能丢失较多数据：这是最大的问题，如果配置为每5分钟保存一次，那么一旦服务器故障,最多可能会丢失最近5分钟内的数据。
2. 耗时：当数据集非常大时，生成RDB快照的过程可能会比较耗时，虽然是通过子进程操作，但在生成快照时，如果父进程有大量写操作,仍可能导致服务短暂停顿。

第二种方案：AOF（追加日志）方式 （根据Redis官方文档关于AOF的说明）

AOF方式则更像是记日记，它不会保存数据本身，而是记录下每一个会修改数据的写命令（比如SET, HSET, SADD等），这些命令会以Redis协议的格式追加到一个日志文件的末尾，当Redis重启时，会重新执行一遍AOF文件中的所有命令,从而在内存中重建整个数据集。

如何配置AOF？ 在redis.conf文件中，找到appendonly配置项，将其改为yes：

appendonly yes

你需要配置AOF日志的同步策略，这是决定数据安全性的关键，通过appendfsync选项设置：

appendfsync always
# appendfsync everysec
# appendfsync no

appendfsync always：最安全，但最慢，每个写命令都会立即同步到硬盘的AOF文件中，这意味着即使系统崩溃，也最多只丢失一个命令的数据，但这种模式会严重拖慢Redis的性能,因为硬盘写入速度远慢于内存。
appendfsync everysec：推荐配置，在安全性和性能之间取得平衡，每秒同步一次AOF文件，这意味着即使系统崩溃，也最多只丢失一秒钟的数据，这种模式性能几乎与RDB的快照模式一样好,是生产环境中最常用的配置。
appendfsync no：最不安全，但最快，由操作系统来决定何时同步到硬盘，这种模式下性能最好，但一旦系统崩溃，可能会丢失较长时间的数据（通常是30秒左右）。

AOF的优点和缺点：

优点：
1. 数据安全性高：特别是使用appendfsync always时，数据丢失风险极低，使用everysec模式也最多只丢失1秒数据。
2. 可读性强：AOF文件是纯文本格式，记录了所有操作命令,便于理解和人工处理。
缺点：
1. 文件体积大：AOF文件通常会比同数据的RDB文件大得多。
2. 恢复速度慢：恢复大数据集时，需要逐条执行命令,比RDB方式慢。
3. 性能影响：在写入负载很高的场景下,AOF可能会比RDB略慢一些。

第三种方案：混合持久化（RDB + AOF） （根据Redis官方文档关于混合持久化的说明）

这是最推荐的生产环境方案，它结合了RDB和AOF的优点，在Redis 4.0及以上版本中,你可以开启这个功能。

如何配置混合持久化？ 你需要同时开启AOF和RDB（AOF开启后，Redis重启会优先使用AOF恢复）。

appendonly yes
aof-use-rdb-preamble yes

开启后，当需要生成AOF文件时，Redis会先执行一次RDB快照，并将这个快照数据写入AOF文件的开头，在这个RDB数据块之后,继续以AOF格式追加新的写命令。

这样一来，既利用了RDB快速恢复的优点（因为重启时先加载RDB快照，数据就已经恢复了大半），又拥有了AOF记录所有操作的优点（RDB快照之后的数据变化由AOF日志保证）。

总结与建议

没有一种方案是完美的,你需要根据业务需求进行权衡：

如果你可以容忍分钟级别的数据丢失（比如用于缓存），那么只使用RDB可能就足够了,因为它简单高效。
如果你对数据安全性要求很高，希望尽可能少丢失数据，那么应该使用AOF，并将appendfsync设置为everysec,这是最普遍的配置。
如果你追求最高的数据安全性和最快的恢复速度，并且使用的是Redis 4.0以上版本，那么强烈推荐使用混合持久化（RDB+AOF）,它提供了近乎完美的平衡点。

无论选择哪种方案，定期将持久化文件（无论是.rdb还是.aof）备份到其他安全的服务器或云存储上，是实现真正“永久保存”不可或缺的最后一道防线。

Redis怎么配置才能实现数据不丢失，永久保存那些东西的方案讲解