redis学习笔记之持久化篇

最新推荐文章于 2024-07-14 16:40:10 发布

循环ing

最新推荐文章于 2024-07-14 16:40:10 发布

阅读量277

点赞数

分类专栏： redis 文章标签： redis 缓存

本文链接：https://blog.csdn.net/linbiaorui/article/details/79822299

版权

redis 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

1.RDB：将当前进程数据生成快照保存到硬盘的过程

A.触发RDB的2种方式：

a.手动触发：

save命令：阻塞当前redis服务器,直到RDB过程完成为止,不建议线上使用

bgsave命令：redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,阻塞只发生在fork阶段

b.自动触发：

使用save相关配置(redis.conf文件),如save m n,则再m秒内数据集存在n次修改时,自动触发bgsave

若从节点执行全量复制,主节点自动执行bgsave生成RDB文件并发送给从节点

执行debug reload命令重新加载redis时,也会自动触发save操作

默认情况下执行shutdown命令时,若没开启AOF持久化功能则自动执行bgsave

B.RDB运行流程,如图：

可通过以下命令查看RDB相关信息：

info stats命令的latest_fork_usec选项可查看最近一个fork操作耗时,单位微妙

lastsave命令可以获取最后一次生成RDB的时间,对应info统计的rdb_last_save_time选项

info persistence下的rdb_*相关选项

C.RDB文件的处理：

a.保存：RDB文件保存在dir配置指定的目录下,文件名通过dbfilename配置指定,可通过config set dir{newDir}或config set dbfilename{newFileName}动态指定,下次运行时RDB文件会保存到新的目录(磁盘满时动态保存,切换目录后bgsave)

b.压缩：redis默认对生成的RDB文件进行压缩,默认开启,可用config set rdbcompression{yes|no}动态修改(建议开启)

c.校验：若redis加载损坏的RDB文件时拒绝启动,可用redis-check-dump工具检测

D.RDB的优缺点：

优点：紧凑压缩,节省空间,适合用于备份、全量复制等场景,redis加载RDB恢复数据远远快于AOF的方式

缺点：无法实时持久化/秒级持久化,有些老版本redis服务无法兼容新版RDB格式

2.AOF：以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令以达到恢复数据的目的

A.AOF的配置(redis.conf文件)：

开启AOF配置：appendonly yes,默认不开启

配置AOF文件名称：appendfilename,默认为appendonly.aof 保存路径与RDB一致,通过dir配置

B.AOF的大体工作流程：

a.所有的写命令会追加到aof_buf(缓冲区) 中

b.AOF缓冲区根据对应的策略向硬盘做同步操作

c.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的

d.当Redis服务器重启时,可以加载AOF文件进行数据恢复

C.详细版的AOF工作流程：

a.命令写入：写入的内容采用文本协议格式,兼容性与可读性(不做介绍)

b.文件同步3种策略：由appendfsync控制

可配置值	说明	建议
always	命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成后线程返回	每次都同步aof文件,低效,不建议用
everysec	命令写入aof_buf后调用系统write操作，write完成后线程返回，fsync同步文件操作由专门线程每秒调用一次	提升性能但数据安全无法保证,依赖系统调度,不建议用
no	命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30s	默认配置,理论上发生意外只丢失1s的数据

wirte操作：会触发延迟写机制,写入系统缓冲区后直接返回,同步硬盘操作依赖于系统调度机制,若在同步文件之前发生故障,缓冲区数据将丢失

fsync操作：会针对单个文件操作,做强制硬盘同步,fsync将阻塞直到写入硬盘完成后返回,保证了数据的持久化write操作：会触发延迟写机制，写入系统缓冲区后直接返回，同步硬盘操作依赖于系统调度机制，若在同步文件之前发生故障，缓冲区数据将丢失

c.重写机制：用于解决不断写入造成aof文件越来越大的问题,将redis进程内数据转化为写命令同步到新AOF文件的过程，主要以剔除无效命令、命令合并、超时数据不写入的方式来缩小AOF文件

触发重写机制的2种方式：

手动触发：直接调用bgrewriteaof命令

自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机(auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积,默认64M,auto-aof-rewrite-percentage代表当前AOF文件空间与上一次重写后AOF文件空间的比值)

自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&(aof_current_size - aof_base_size)/aof_base_size>=auto-aof-rewritepercentage

其中, aof_current_size与aof_base_size可从info persistence的统计信息中查看

d.aof重写机制：