当前位置:网站首页>[Study Notes] Persistence of Redis
[Study Notes] Persistence of Redis
2022-08-10 13:21:00 【Tiejia Xiaobao classmate】
【学习笔记】Redis的持久化
前言
持久化简介
持久化(Persistence):即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘).
在Redis
中有RBD
和AOF
两种持久化方式,But generally defaultRDB
.
RDB
默认中Redis
The first is to save the in-memory database snapshot under the namedump.rdb
的二进制文件中.
save
我们能通过save
to configure the persistence strategy.
save N M #让redis在“N秒内至少有M个改动”才会触发一次rdb持久化操作.
#例如:
save 100 60 #表示在100秒内有60个改动
当执行save
命令时,Redis
同步做快照操作,在快照执行过程中会阻塞所有来自客户端的请求.当redis
内存中的数据较多时,通过该命令将导致Redis
较长时间的不响应.所以不建议在生产环境上使用这个命令,而是推荐使用bgsave
命令.
bgsave
Redis
借助了linux
系统的写时复制(Copy-On-Write)
技术,在生成快照的同时,仍然可以接收命令处理数据.简单来说,bgsave
线程是由主线程fork
生成的子线程,可以共享主线程所有的内存数据.bgsave
线程运行后,开始读取主线程的内存数据,也就是redis
的内存数据,将内存数据写入到dump.rdb
文件中.此时,如果主线程处理的命令都是读操作,则bgsave
线程不受影响.如果主线程处理了写操作,则会对该命令操作的数据复制一份,生成副本,bgsave
线程会把这个副本写入到dump.rdb
文件中,而在这个过程中,主线程仍可执行命令.
和save的对比:
save | bgsave | |
---|---|---|
IO类型 | 同步 | 异步 |
是否阻塞其他命令 | 是 | 否 |
复杂度 | O(n) | O(n) |
优点 | Does not consume additional memory | 不阻塞操作 |
缺点 | 阻塞操作 | consumes additional memory |
RDB的优点:
- 因为
dump.rdb
是二进制文件,When disaster-level data loss occurs,Using binary files can be easily restored. - 生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作.
- RDB 在恢复大数据集时的速度比AOF的恢复速度要快.
RDB的缺点:
- RDB方式数据没办法做到实时持久化/秒级持久化.因为bgsave每次运行都要执行fork操作创建子进程,频繁执行成本过高.
- 在一定间隔时间做一次备份,所以如果redis意外down掉的话,Modified data after the last snapshot will be lost(数据有丢失).
AOF(Append-Only File)
Redis
默认不开启.AOF
采用日志
的形式来记录每个写操作,并追加到文件中.开启后,执行更改Redis
数据的命令时,就会把命令写入到AOF
文件中.
Redis
重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作.
手动配置:
# appendonly yes
AOF可以配置三种刷盘策略:
appendfsync always:每次执行写命令都会刷盘,非常慢,也非常安全.
appendfsync everysec:每秒刷盘一次,兼顾性能和安全.
appendfsync no:将刷盘操作交给系统,很快,不安全.
AOF重写
随着时间的推移,AOF
The backup file will get bigger and bigger!This not only results in taking up a lot of disk space,will also make some移动复制
,加载分析
Seems very time consuming!
To reduce file growth,可以采用 压缩 way to reduce the memory of a file.
如下两个配置可以控制aop文件重写的频率:
# auto‐aof‐rewrite‐min‐size 64mb: -- aof文件至少达到了64m才会触发重写
# auto‐aof‐rewrite‐percentage 100: -- 距离上次重写增长了100%才会再次触发重写
AOF也可以手动触发重写:bgrewriteof
注意,AOF重写redis会fork出一个子进程去做(与bgsave命令类似),不会对redis正常命令处理有太多影响
重写的流程:
- 主进程会
fork
一个子进程出来进行AOF
重写,It is not a rearrangement of the original file,而是直接读取redis
Existing key-value pairs in service memory,Then replace each key-value pair with a single command,写入到新的AOF
文件中 - 在
fork
子进程这个过程中,服务端仍然可以对外提供服务,In this period of time when the child process is rewritten,,主进程的数据更新操作,会缓存到aof_rewrite_buf
中,也就是单独开辟一块缓存来存储重写期间收到的命令,当子进程重写完以后再把缓存中的数据追加到新的aof
文件. - 当所有的数据全部追加到新的
aof
文件中后,会把旧的aof
文件替换成新的aof
文件,此后所有的操作都会被写入新的aof
文件. - 如果在
rewrite
过程中出现故障,不会影响原来aof
文件的正常工作,只有当rewrite
完成后才会切换文件.因此这个rewrite
过程是比较可靠的.
在aof_bufcache to oldaofThere is actually a child process in the middle of the file,将aof_bufThe data in the cache is synchronized toaof文件中取.
AOF相关问题
问题1:数据都是实时持久化到磁盘吗?
虽然每次执行更改Redis数据库内容的操作时,AOF都会将命令记录在AOF文件中,但是事实上,由于操作系统的缓存机制,数据并没有真正地写入硬盘,而是进入了aof_buf缓存中.在默认情况下系统每30秒会执行一次同步操作.以便将aof_bufThe contents of the cache are actually written to disk.
在这30If the system exits abnormally in the process of seconds, it will be causedaof_bufData in cache is lost.这个时候就需要Redis在写入AOFAfter the file is actively requested the system willaof_bufCache contents are synced to disk.在redis.conf中通过如下配置来设置同步机制.
fork()出一个子进程,Via subprocess willaof_bufThe data in the cache is synchronized to disk:
问题2:为什么要AOF重写?
比如我有业务很简单,就来回delete set同一个key.就这个业务运行了10年,那么aof文件将记录无数个delete k1, set k1.其实都是重复的,但是我aof每次都追加,文件变成了1T大小.这时候Redis宕机了,要恢复,你想想1TB大小的aof文件去恢复,累死了.最主要的是1TB大小只记录了两个命令,所以压缩其实就是来处理这件事的.
RDB于AOF对比
命令 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 容易丢失数据 | 根据策略决定 |
混合持久化
如果我们采用 RDB
持久化会丢失一段时间数据.如果我们采用 AOF
持久化,AOF
日志较大,重放比较慢.
Redis 4.0 为了解决这个问题,支持混合持久化.将 RDB
文件的内容和增量的 AOF
日志文件存在一起.
混合持久化同样也是通过 bgrewriteaof
完成的,不同的是当开启混合持久化时,fork
出的子进程先将共享的内存副本全量的以 RDB
方式写入 AOF
文件,然后在将重写缓冲区的增量命令以 AOF
方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB
格式和 AOF
格式的 AOF
文件替换旧的的 AOF
文件.简单的说:新的AOF
文件前半段是RDB
格式的全量数据后半段是AOF
格式的增量数据.
于是在 Redis
重启的时候,可以先加载 rdb
的内容,然后再重放增量 AOF
日志就可以完全替代之前的 AOF
全量文件重放,重启效率因此大幅得到提升.
参考文章链接:
文章1 |
---|
文章2 |
文章3 |
边栏推荐
- LeetCode·297.二叉树的序列化与反序列化·DFS·BFS
- 生成树协议STP(Spanning Tree Protocol)
- CodeForces-834C
- Real-time data warehouse practice of Baidu user product flow and batch integration
- Code Casual Recording Notes_Dynamic Programming_70 Climbing Stairs
- Polygon zkEVM工具——PIL和CIRCOM
- Educational Codeforces Round 41 (Rated for Div. 2) E. Tufurama
- C#中导入其它自定义的命名空间
- 山水的高度
- Pod生命周期
猜你喜欢
2022 Recruitment Notice for Academician Zhao Guoping Group of Shenzhen Institute of Advanced Technology, Chinese Academy of Sciences
R语言实战应用案例:论文篇(一)-特殊柱形图绘制
海外邮件发送指南(二)
LeetCode中等题之比较版本号
Interface Automation Testing Basics
【目标检测】小脚本:提取训练集图片与标签并更新索引
kubernetes介绍
Solution for "Certificate not valid for requested usage" after Digicert EV certificate signing
LeetCode简单题之合并相似的物品
想通这点,治好 AI 打工人的精神内耗
随机推荐
Overview of Loudi Petrochemical Experiment Design and Construction Planning
机器学习实战(2)——端到端的机器学习项目
[Advanced Digital IC Verification] Difference and focus analysis between SoC system verification and IP module verification
Keithley DMM7510 accurate measurement of ultra-low power consumption equipment all kinds of operation mode power consumption
协程与任务
3DS MAX 批量导出文件脚本 MAXScript 带界面
ABAP file operations involved in the Chinese character set of problems and solutions for trying to read
Detailed explanation of es6-promise object
代码随想录笔记_动态规划_70爬楼梯
phpstrom 快速注释:
Pod生命周期
I would like to ask the big guys, how to solve this error when cdc oracle initializes a 3 million table task running
2022-08-09:以下go语言代码输出什么?A:否,会 panic;B:是,能正确运行;C:不清楚,看投票结果。 package main import ( “fmt“ “syn
Alibaba Cloud Jia Zhaohui: Cloud XR platform supports Bizhen Technology to present a virtual concert of national style sci-fi
LeetCode中等题之比较版本号
数字藏品,“赌”字当头
Fragment的show和hide
CodeForces - 834C
YTU 2295: KMP pattern match one (string)
Nanodlp v2.2/v3.0光固化电路板,机械开关/光电开关/接近开关的接法和系统状态电平设置