Redis缓存持久化

Redis的持久化包括RDB和AOF两种方式。RDB通过快照保存数据,bgsave命令非阻塞地创建子进程执行,文件小适合备份,但不实时。AOF记录每次写命令,支持always、everysec和no三种同步策略,可避免文件过大,通过重写压缩文件体积。AOF重写根据设置的触发条件自动或手动执行,确保数据安全。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

缓存持久化

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘,

命令为

  • save 阻塞执行,已废弃
  • bgsave 创建子进程执行

bgsave执行结果

33375:M 24 Sep 16:39:02.580 * Background saving started by pid 34280
34280:C 24 Sep 16:39:02.592 * DB saved on disk
34280:C 24 Sep 16:39:02.593 * RDB: 6 MB of memory used by copy-on-write
33375:M 24 Sep 16:39:02.599 * Background saving terminated with success

save执行结果

33375:M 24 Sep 16:39:02.599 * Background saving terminated with success
33375:M 24 Sep 16:41:27.320 * DB saved on disk

触发机制:

  • 手动触发
  • 自动触发
    • 1) 使用save相关配置, 如“save m n”。 表示m秒内数据集存在n次修改时, 自动触发bgsave。
    • 2) 如果从节点执行全量复制操作, 主节点自动执行bgsave生成RDB文件并发送给从节点。
    • 3) 执行debug reload命令重新加载Redis时, 也会自动触发save操作。
    • 4) 默认情况下执行shutdown命令时, 如果没有开启AOF持久化功能则自动执行bgsave。

bgsave运行流程

文件压缩

Redis默认采用LZF算法对生成的RDB文件做压缩处理, 压缩后的文件远远小于内存大小, 默认开启, 可以通过参数config setrdbcompression{yes|no}动态修改。虽然压缩RDB会消耗CPU, 但可大幅降低文件的体积, 方便保存到硬盘或通过网络发送给从节点, 因此线上建议开启。

RDB优缺点:

优点缺点
文件小,适于全量备份,便于传输和恢复
Redis加载恢复速度快
bgsave创建子进程操作较重,不能实时/秒级持久化,频繁执行成本过高
RDB二进制文件新老版本可能会不兼容

AOF

记录每次写命令到AOF文件中,恢复时重新执行AOF文件中的命令

策略说明
always命令写入aof_buf后调用fsync操作同步到AOF文件,每次写入都会执行,不建议
everysec命令写入aof_buf后调用系统write操作,write完成后线程返回,fsync同步文件操作由专门线程每秒调用一次。是默认的也是建议的同步策略,兼顾性能和数据安全。理论上宕机只丢1秒数据。
no命令写入aof_buf后调用write操作,由操作系统负责控制写入AOF,同步周期最长30秒,性能会提升,但安全无法保证。

系统调用write和fsync说明:

  • write操作会触发延迟写(delayed write) 机制。 Linux在内核提供页缓冲区用来提高硬盘IO性能。 write操作在写入系统缓冲区后直接返回。 同步硬盘操作依赖于系统调度机制, 例如: 缓冲区页空间写满或达到特定时间周期。 同步文件之前, 如果此时系统故障宕机, 缓冲区内数据将丢失。

  • fsync针对单个文件操作(比如AOF文件) , 做强制硬盘同步, fsync将阻塞直到写入硬盘完成后返回, 保证了数据持久化。

重写机制

为避免AOF文件越写越大,Redis引入AOF重写机制压缩文件体积。 AOF文件重写是把Redis进程内的数据转
化为写命令同步到新AOF文件的过程。

文件变小原理:

  1. 进程内超时数据不再写入文件
  2. 删除无效命令如:del等,只使用进程内数据直接生成,保留最终写入命令
  3. 集合多次操作命令合并,以64个元素为界拆分为多条

触发:

  • 手动: 调用bgrewriteaof命令。
  • 自动:根据参数确定自动触发时机。
    • auto-aof-rewrite-min-size: AOF重写最小体积
    • ·auto-aof-rewrite-percentage: 代表当前AOF文件空间( aof_current_size) 和上一次重写后AOF文件空间( aof_base_size) 的比
      值。

自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&( aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage
其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

127.0.0.1:6380> info Persistence
# Persistence
loading:0
rdb_changes_since_last_save:2
rdb_bgsave_in_progress:0
rdb_last_save_time:1632476935
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:199
aof_base_size:199
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0

aof重写流程

持久化文件加载流程

Redis单线程架构导致无法充分利用CPU多核特性, 通常的做法是在一台机器上部署多个Redis实例。 当多个实例开启AOF重写后, 彼此之间会产生对CPU和IO的竞争。 如果同一时刻运行多个子进程, 对当前系统影响将非常明显, 因此单机下部署多实例时需要采用一种措施, 把子进程工作进行隔离。通过info Persistence命令可以获取监控子进程运行状况的度量指标。基于以下这些指标,可以通过外部程序轮询控制AOF重写操作的串行执行。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值