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

Redis持久化怎么弄才靠谱，设置那些坑和技巧你知道吗

革姣丽
问答
2026-01-16 17:19:42
3

关于Redis持久化怎么弄才靠谱，核心就是理解它的两种主要方式：RDB和AOF，然后根据你的业务场景进行选择和搭配，别想着用一个万能配置解决所有问题,那是不现实的。

两种持久化方式： snapshot（RDB）和 log（AOF）

你可以把Redis想象成一个在内存里工作的数据库，内存速度快，但一断电数据就没了，持久化就是把内存里的数据想办法存到硬盘上,防止数据丢失。

RDB（快照方式）
- 是什么：就像给数据库拍一张全景照片，在某个时间点，把内存里所有数据完整地保存到一个压缩过的二进制文件中（默认叫 dump.rdb）。
- 怎么触发：可以手动触发（执行 SAVE 或 BGSAVE 命令），但通常是自动触发，自动触发的规则在配置文件里设置，
  - save 900 1：在900秒（15分钟）内，如果至少有1个key发生变化,就拍快照。
  - save 300 10：在300秒（5分钟）内，如果至少有10个key发生变化,就拍快照。
  - save 60 10000：在60秒内，如果至少有10000个key发生变化,就拍快照。
- 优点：
  - 文件小：因为是压缩的二进制文件，文件体积小，适合做灾难备份,方便传输到别的地方。
  - 恢复快：恢复大数据集时速度比AOF快很多,因为直接读入内存就行。
- 缺点（最大的坑）：
  - 会丢数据：这是最要命的一点，如果设置成每5分钟拍一次快照，那么一旦服务器宕机，最多会丢失最近5分钟的数据，对数据可靠性要求高的业务,这是无法接受的。
AOF（日志方式）
- 是什么：不像RDB拍照片，AOF是写日记，它会把每一个会修改数据的写命令（比如SET, LPUSH等）都记录到一个日志文件里（默认是 appendonly.aof），当Redis重启时，会重新执行一遍这个日志文件里的所有命令,从而恢复数据。
- 怎么工作：AOF日志会越来越大，所以需要“瘦身”，Redis提供了AOF重写机制（BGREWRITEAOF），会创建一个新的AOF文件,这个文件包含恢复当前数据集所需的最少命令序列。
- 同步策略（关键设置，直接影响性能和可靠性）：
  - appendfsync always：每写一个命令，就同步一次磁盘。最安全，基本不会丢数据（除非磁盘坏了），但速度最慢，严重影响性能,一般不建议用。
  - appendfsync everysec：每秒同步一次。折中方案，就算宕机，最多丢1秒钟的数据，这是默认也是生产环境最常用的配置。
  - appendfsync no：由操作系统决定何时同步。性能最好,但丢数据的风险最大。
- 优点：
  - 数据安全度高：用everysec策略，最多丢1秒数据,比RDB通常要安全。
- 缺点：
  - 文件大：AOF文件通常比RDB文件大得多。
  - 恢复慢：数据量大的时候,重新执行所有命令恢复数据会比较慢。

靠谱的设置方案和技巧

了解了优缺点，我们就可以来组合了，没有最好的,只有最适合的。

高可靠性，允许分钟级数据丢失 如果你的数据比较重要，但可以容忍几分钟的数据丢失（比如用户缓存、排行榜等），可以只使用RDB。
- 技巧：把RDB的快照频率设置得合理一些。save 300 10 和 save 60 10000 组合，既要避免频繁写盘影响性能,又要避免间隔太长丢太多数据。
- 坑：务必确保硬盘空间充足，快照文件写入失败会影响持久化,把RDB文件自动备份到别的机器或云存储上。
高可靠性，要求数据丢失最少 这是生产环境最常用、最推荐的方案：同时开启RDB和AOF。
- 怎么弄：在配置文件里同时启用两者（appendonly yes 并配置好RDB的save规则）。
- 好处：
  1. 兼得两者优点：AOF保证数据不会大量丢失（用everysec策略）,持久性更好。
  2. RDB做后备：AOF文件可能出问题（比如在重写时断电），这时候可以用RDB文件来快速恢复,而且RDB文件更适合做冷备。
  3. 重启恢复时，Redis会优先使用AOF文件来恢复数据,因为AOF通常数据更完整。
- 技巧：
  - 监控AOF文件大小，设置合理的自动重写条件（auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size）,防止文件无限膨胀。
  - 定期手动执行BGREWRITEAOF重写AOF文件也是个好习惯。
纯缓存，数据可丢弃 如果你的Redis只用作缓存，数据丢了也没关系，可以从数据库重新加载，那么可以关闭持久化。
- 怎么弄：配置文件中注释掉所有save规则，或者写成 save ""，并设置 appendonly no。
- 好处：获得最佳性能。

必须知道的坑和技巧

别在主库上做持久化！ 这是血泪教训，无论是RDB的BGSAVE还是AOF重写，都是重量级操作，会fork子进程，消耗大量CPU和内存（尤其是内存，fork瞬间如果内存很大，可能导致系统内存不足，触发OOM Killer把Redis进程杀掉）。一定要配置从库（slave），在从库上做持久化。
监控磁盘空间！ 持久化就是写磁盘，如果磁盘满了，Redis会卡死，持久化失败，甚至可能直接关闭AOF功能导致数据丢失,务必设置监控告警。
备份！备份！备份！ 光有持久化不够，万一服务器硬盘整个坏了呢？一定要有定期备份策略，把RDB或AOF文件拷贝到异地机房或云存储上，可以写个脚本，定时SCP或者用rsync同步。
测试恢复流程！ 定期演练一下用你的备份文件恢复Redis实例，千万别等到真出事了,才发现备份文件是坏的或者恢复流程走不通。
关于SAVE和BGSAVE：SAVE是同步命令，会阻塞所有客户端请求，生产环境绝对不能用，做快照一定要用BGSAVE（后台执行）。