Redis持久化

最新推荐文章于 2024-04-10 14:00:56 发布

liujie379908

最新推荐文章于 2024-04-10 14:00:56 发布

阅读量1.2k

点赞数 14

分类专栏： Redis 文章标签： Redis持久化

本文链接：https://blog.csdn.net/liujie379908/article/details/102413423

版权

Redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Redis持久化

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时，利用之前持久化的文件即可实现数据恢复。

1 RDB

RDB持久化是把当前进程数据生成快照保存在磁盘的过程，触发RDB持久化的过程分为手动触发和自动触发

1.1 RDB触发机制

手动触发分别对应save和bgsave命令
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对内存大的实例会造成长时间阻塞，线上环境不建议使用
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短，因此现在Redis内部所有涉及到RDB的操作都采用bgsave方式，而save已被废弃
自动触发
1.使用save相关配置，如：“save m n”,表示m秒内数据集存在n茨修改时，自动触发bgsave
2.如果节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
3.执行debug reload命令重新加载Redis时，也会自动触发save操作
4.默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave

1.2 流程说明

bgsave是主流的触发RDB持久化方式，下面是其运作流程

在这里插入图片描述
1：执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在直接退出
2：父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞
3：父进程fork完成后，不再阻塞父进程，可以继续响应其他命令
4：子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换
5：进程发送信号给父进程表示完成，父进程更新统计信息

1.3 RDB文件的处理

保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置
指定。可以通过执行conf set dir{newDir}和config set dbfilename {newFileName}运行期动态执行，下次运行时RDB文件会保存在新目录
压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression {yes|no}动态修改
校验：如果Redis加载损坏的RDB文件时拒绝启动

1.3 RDB优缺点

优点
1.RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点的数据快照，适合用于备份和全量复制
2.RDB加载RDB恢复数据远远快于AOF的方式

缺点
1：RDB方式数据没办法做到实时持久化，因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本较高
2：RDB文件使用特定二进制格式保存，存在老版本Redis服务无法兼容新版本RDB格式的问题

2 AOF

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的主要作用是解决了数据持久化的实时性。
目前Redis持久化最主流的方式是AOF

2.1 使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。
保存的路径同RDB持久化方式一致，通过dir配置指定。
AOF的工作流程：
命令写入(append)
文件同步(sync)
文件重写(rewrite)
重启加载(load)
具体流程如下：
1.所有的写入命令追加到aof_buf(缓存区)中
2.AOF缓存区根据对应的策略向磁盘做同步操作
3.随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
4.当Redis服务器重启时，可以加载AOF文件进行数据恢复
## 在这里插入图片描述

2.2 命令写入

AOF命令写入的内容直接是文本协议格式

AOF为什么直接采用文本协议格式？

文本协议格式具有很好的兼容性
开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销
文本协议具有可读性，方便直接修改和处理

AOF为什么把命令追加到aof_buf中

Redis是单线程响应命令，如果每次写AOF文件命令都直接追加到磁盘，那么性能完全取决于当前硬盘负载。
先写入缓冲区aof_buf中，还有一个好处，Redis可以提供多种缓冲区同步硬盘策略，在性能和安全性上做出平衡

2.3 文件同步

AOF缓冲区同步文件策略

可配置值	说明
always	命令写入aof_buf后调用系统fsync操作听同步到AOF文件，fsync完成后退出线程
everysec	命令写入aof_buf后调用系统write操作，write完成后退出线程返回。fsync同步文件由专门线程每秒调用一次
no	命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步磁盘操作由操作系统负责，通常同步周期最长为30s

系统调用write和fsync说明：

write操作会触发延迟写机制。Linux在内核提供缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步磁盘操作依赖于系统调度机制。例如：缓冲区页空间满或者达到特定时间周期。同步文件之前如果系统故障宕机，缓冲区内的数据将会丢失。
fsync针对单个文件操作，做强制硬盘操作，fsync将阻塞直到写入磁盘完成后返回，保证了数据持久化

配置为always时，每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议使用
配置为no，由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步磁盘的数据量，虽然提高性能，但是数据安全性无法保证
配置everysec，是建议的策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失一秒数据

2.4 重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制来压缩文件体积。
AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件的过程
重写后AOF文件为什么会变小？

进程内已经超时的数据不再写入文件
旧的AOF文件含有无效命令，重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
多条写命令可以合并为一个。为了防止单条命令过大造成客户端缓冲区溢出，对于list，set，hash，zset等类型操作，以64个元素为界拆分为多条

重写好处

降低了文件占用空间
更小AOF可以更快地被Redis加载

AOF重写过程可以手动触发和自动触发
手动触发：直接调用bgrewriteaof命令
自动触发：自动触发时机=aof_current_size>auto-aof-rewrite-min-size && (aof_current_size - aof_base_size)/aof_base_size >= auto-aof-rewrite-percentage
其中，auto-aof-rewrite-min-size：表示运行AOF重写文件最小体积，默认是64MB,auto-aof-rewrite-percentage:代表当前AOF文件空间和上次重写后AOF文件空间的比值
AOF重写流程

执行AOF重写请求
如果当前进程正在执行AOF重写，请求不执行
如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成后再执行
父进程执行fork创建子进程，开销等同于bgsave过程
3.1父进程fork操作完成后，继续响应其他命令。所有修改命令依然写到AOF缓冲区并根据appendfsync策略同步到磁盘上，保证原有AOF机制正确性
3.2 由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用"AOF重写缓冲区"保存这部分新数据，防止新AOF文件生成期间丢失这部分数据
子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
5.1 新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息
5.2父进程把AOF重写缓冲区中的数据写入到新的AOF文件
5.3使用新的AOF文件替换老的AOF文件，完成AOF重写