Redis 持久化
2026-01-29 13:52:16 0 举报
AI智能生成
Redis持久化是其关键特性之一,它允许将内存中的数据集以不同形式保存到磁盘,确保数据的持久性。支持的主要持久化选项有RDB(Redis Database)和AOF(Append Only File)两种模式。 RDB模式通过创建数据集的时间点快照来保存数据,是一种高效的数据恢复方式。当满足特定条件时(如时间周期或数据变化数量),Redis会自动触发快照保存。RDB适合大规模数据恢复,因为它可以最大化性能和最小化CPU和内存使用。 AOF模式则提供了另一种容错保障,通过记录服务器接收的每一个写操作来记录数据变化,当Redis重启时,可以重放这些命令来恢复数据。AOF文件因为是逐条记录,所以更加详细且易于恢复,但相较RDB有更高的内存和磁盘写入开销。 Redis 4.0及以上版本中,还可以结合RDB和AOF两种方式,通过混合持久化来平衡性能和数据安全。该特性允许AOF在重写时,一部分是RDB格式的数据和一部分是AOF格式的数据,从而加快重启时的恢复速度,同时减少数据丢失风险。 为了进一步降低数据丢失的风险,Redis支持自动故障转移和主从复制,确保在一个节点失败时,数据可以在其他节点迅速恢复,从而提供了一种高可用性的解决方案。总之,Redis的持久化策略提供了灵活的选择,既可以优化性能,也能确保数据的持久性和一致性。
作者其他创作
大纲/内容
RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程
手动触发
1、sava命令:阻塞当前Redis服务器,直到 RDB 过程完成为止,对于内容比较大的实例会造成长时间的阻塞,线上环境不建议使用
2、bgsave命令:Redis进 程执行 fork 操作创建子进程,RDB 持久化过程由子进程负责,完成后自动结束,阻塞只发生在 fork 阶段,一般时间很短
自动触发
1、在 redis.conf 中配置 save m n,表示m秒内数据集存在n次修改时,自动触发bgsave
2、如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点
3、执行debug reload命令重新加载Redis时,也会自动触发 bgsave操作
4、默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave
bgsave运作流程
1、执行bgsave命令,Redis父进程判断当前是否存在正在执行的子进程,如RDB/AOF子进程,如果存在bgsave命令则直接返回
2、父进程执行fork操作创建子进程,fork操作过程中父进程阻塞
3、父进程fork完成后,bgsave命令返回Background savingstarted信息,并不再阻塞父进程,可以继续响应其他命令
4、子进程创建RDB文件,根据父进程内存生成临时快照文件,完成后对原文件进行原子替换
5、子进程发送信号给父进程表示完成,父进程更新统计信息
写时复制
Redis在对内存数据做RDB快照时,并不会暂停写操作(读操作不会造成数据的不一致)
Redis使用了操作系统的多进程写时复制技术(Copy On Write,COW)来实现RDB快照持久化
优点
1、RDB文件采用二进制格式数据 + 数据压缩的方式写磁盘,代表Redis在某个时间点上的数据快照。非常适用于备份、全量复制等场景。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程机器或者文件系统中(hdfs),用于灾难恢复
2、Redis加载RDB恢复数据远远快于AOF的方式
缺点
1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高
2、RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版本RDB格式的问题
3、通过bgsave调用fork函数创建子进程,属于重量级操作,频繁执行成本高
AOF
AOF的工作流程
1、命令写入(append):所有的写入命令会追加到aof_buf缓冲区中
2、文件同步(sync):AOF缓冲区根据对应的策略向硬盘做同步操作
3、文件重写(rewrite):随着AOF文件越来越大,需要定时对AOF文件进行重写,达到压缩的目的
4、重新加载(load):当Redis服务重启时,可以加载AOF文件进行数据恢复
AOF为什么直接采用文本格式协议?
1、文本协议具有很好的兼容性
2、开启AOF后,所有写命令都包含追加操作,直接采用文本格式,避免了二次处理的开销
3、文本协议具有可读性,方便直接修改了处理
文件同步策
1、always
2、everysec
3、no
重写机制
AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程
重写后的AOF文件变小原因:
1、进程内已经超时的数据不再写入文件
2、旧的AOF文件含有无效命令等。重写使用进程内数据直接生成,这样的新的AOF文件只保留最终数据的写入命令
3、多条写命令合一合并为一条,为了防止单条命令过大造成客户端缓冲区溢出,对于list、set、zset、hash等类型的操作,以64个元素为界拆分为多条
问题定位与优化
收藏
收藏
0 条评论
下一页