Redis持久化机制

Redis之所以能够高速读写操作是因为数据存储在了内存中，但这有一个弊端，就是服务器宕机或断电的情况加，内存中的数据就会丢失

为了解决这个问题，Redis提供了持久化机制来确保数据的持久和可靠

Redis持久化机制

  • RBD（Redis Data Base）：内存快照
  • AOF（Append Only File）：增量日志
  • 混合持久化：RDB + AOF

RDB持久化

在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份

流程

image-20250408101932548.png

image-20250408101932548.png

RDB持久化方案进行备份时，Redis会单独fork一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的RDB文件

在整个持久化过程中，主进程（为客户端提供服务的进程）不参与IO操作，这样能确保Redis服务的高性能，RDB持久化机制适合对数据完整性要求不高，但追求高恢复的使用场景

触发规则

手动触发

  • save：阻塞当前Redis进程，直到RDB持久化过程完成，如果内存实例比较大会造成长时间阻塞，尽量不要使用这种方式
  • bgsave：Redis主进程fork创建子进程，由子进程完成持久化，阻塞时间很短（微秒级）

自动触发

  • 配置触发

优点

  • 高性能：RDB持久化是通过生成一个快照文件来保存数据，因此在恢复数据时速度非常快
  • 文件紧凑：RDB文件是二进制格式的数据库文件，相对于AOF文件来说，文件体积较小

缺点

  • 可能丢失数据：由于RDB是定期生成的快照文件，如果Redis意外宕机，最近一次的修改可能会丢失
Redis默认开启RDB持久化

AOF持久化

AOF持久化需要手动修改conf配置文件开启

流程

image-20250408103750751.png

image-20250408103750751.png

AOF持久化方案进行备份时，客户端所有请求的写命令都会被追加到AOF缓冲区中，缓冲区中的数据会根据Redis配置文件中的同步策略来同步到磁盘上的AOF文件中，同时当AOF的文件达到重写策略配置时，Reids会对AOF日志文件进行重写，给AOF日志文件瘦身

Reids服务重启的时候，通过加载AOF日志文件来恢复数据

配置

AOP默认不开启，开启需要修改appendonly yes
image-20250408104122725.png

image-20250408104122725.png

AOF + RDB缓和模式设置为 no
image-20250408104416990.png

image-20250408104416990.png

AOP同步策略
image-20250408104505517.png

image-20250408104505517.png

  • appendfsync always：每次Redis写操作，都写入AOF日志，非常消耗性能
  • appendfsync everysec：每秒刷新一次缓冲区中的数据到AOF文件，这个是Redis配置文件中默认的策略，兼容了性能和数据完整性的这种方案
  • appendfsycn no：Redis进程不会主动的去刷新缓冲区的数据到AOF文件，而是直接交给操作系统去判断，不推荐这种，丢失数据的可能性非常大

优点

  • 数据更加可靠：AOF持久化记录了写命令的操作，因此在出现故障时，可以通过重写执行AOF文件来保证数据完整性
  • 可以保留写命令历史：AOF文件是一个追加日志文件，可以用于回放过去的写操作

缺点

  • 文件较大：由于记录了每个写命令，AOF文件体积通常比RDB文件要大
  • 恢复速度较慢：当AOF文件较大时，Redis重启需要重写执行整个AOF文件，恢复速度相对较慢

混合持久化

因为RDB虽然加载快，但是存在数据丢失

AOF数据安全但是加载慢

持久化策略通过aof-use-rdb-preamble yes开启
image-20250408105421164.png

image-20250408105421164.png

推荐两个都开启

最后修改：2025 年 04 月 08 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏