2022/08/20、21、22 day07/08/09：redis的持久化

目录

1. 持久化简介
2. RDB
3. AOF
4. RDB与AOF区别
5. 持久化应用场景

持久化简介

意外的断电

• 遇到软件崩溃
• 意外断电

会出现（防止我们丢东西的情况）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8ke8g7Zo-1661244512723)(en-resource://database/5159:1)]

自动备份，自动恢复
其实就是把内存中的文件与硬盘中的文件做一个关联。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xzMTKWn8-1661244512724)(en-resource://database/5161:1)]

redis也有这样的操作：因为redis丢东西会很麻烦。

什么是持久化
利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

为什么要进行持久化
防止数据的意外丢失，确保数据安全性

持久化过程保存什么
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TPQ5elB1-1661244512725)(en-resource://database/5165:1)]

Redis中两种方式都在用。

第一种方式：数据当前的形式全部保存起来，出问题后直接使用其恢复：数据（快照）

• 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据（数据长什么样）

第二种方式：保存数据操作的过程：过程（日志）

• 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。

RDB 快照

save

RDB启动方式

谁，什么时间，干什么事情

命令执行

• 谁：redis操作者（用户）
• 什么时间：即时（随时进行）
• 干什么事情：保存数据

RDB启动方式–save指令

• 命令：save
• 作用：手动执行一次保存操作

看redis空间中是否有数据
keys *

每保存（save）一次，会在设定好的目录下data，生产一个.rdb文件（但是我的没有，不知道为什么）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gw2IlUIH-1661244512725)(en-resource://database/5167:1)]

RDB启动方式–save指令相关配置

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S0HReCH1-1661244512725)(en-resource://database/5169:1)]

在conf目录下修改配置
vim redis-6379.conf
查看进程
ps -ef | grep redis-
结束进程
kill -s 9 1109
开启进行进程(修改配置文件后，需要重启进程）
redis-server conf/redis-6379.conf

如何恢复数据

退出客户端

杀死进程
kill -s 9 4155

重启进程
redis-server conf/redis-6379.conf

查看进程
ps -ef | grep redis-

杀死进程后重启进程，连接客户端发现上次创建的数据会还存在(在redis启动时，数据就已经加载进来了）
keys *

bgsave

RDB启动方式–save指令工作原理

redis是单线程的，多个指令save（有时太长）指令会阻塞服务器，线上环境不建议使用。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rjxbfxyk-1661244512726)(en-resource://database/5171:1)]
第二种RDB的工作方式，能够较好的解决这个问题

【提问】数据量过大，单线程执行方式造成效率过低如何处理？
使用【后台执行】

• 谁：redis操作者（用户）发起指令；redis服务器控制指令执行
• 什么时间：即时（发起）；合理的时间（执行，后台自己）
• 干什么事情：保存数据

【bgsave指令】

• 命令：bgsave
• 作用：手动启动后台保存操作，但不是立即执行的

【bgsave指令工作原理】
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zSMxknnR-1661244512726)(en-resource://database/5175:1)]
save是马上执行，在任务执行序列中；bgsave利用函数创建的子进程执行，是后台执行【save命令可以放弃使用，bgsave是针对save阻塞问题的优化】

RDB启动方式–bgsave指令相关配置

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0bAIjc05-1661244512727)(en-resource://database/5177:1)]

存储的时候出错时，是否停止，默认是开启的。

优化2–自动执行

【提问】反复执行保存命令，忘记了怎么办？不知道数据产生了多少变化，如何保存？

第三种执行：自动执行

• 谁：redis服务器发起指令（基于条件）
• 什么时间：满足条件，就开干（只有key发生变化才行，后台用的是bgsave）
• 干什么事情：保存数据

【save配置】

• 牌配置：sava second changes
• 作用：满足限定时间范围内key的变化数量达到指定数量，即进行持久化
• 参数
  • second：监控时间范围
  • changes：监控key的变化量
• 位置：在conf文件中进行配置
• 范例
  • save 900 1
  • save 300 10
  • save 60 11000

修改配置
cd conf/

save配置原理
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2hyoAVIV-1661244512727)(en-resource://database/5179:1)]

RDB三种启动方式对比

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eAIeoCQ4-1661244512727)(en-resource://database/5181:1)]

rdb特殊启动形式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QcNC44vw-1661244512727)(en-resource://database/5183:1)]

RDB的优缺点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BBIln0gs-1661244512728)(en-resource://database/5185:1)]

AOF

AOF的概念

RDB存储的弊端

• 存储数据量较大，效率较低
  • 基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低。
• 大数据量下的IO性能较低
• 基于fork常见子进程，内存产生额外消耗
• 宕(dang)机带来的数据丢失风险（不是时时刻刻都在快照）

基于以上问题：那么问题是否可以解决呢？

解决思路：

1. 上面存的是全数据，那么不存全数据，仅仅记录部分数据
2. 我们不记录数据，改记录数据为记录操作过程
3. 对所有操作均进行记录，排除丢失数据的风险
4. 【这些思想就是AOF的思想】

AOF概念

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比，可以简单描述为改记录数据为记录数据产生的过程
• 在下一次重启或数据恢复的时候，我把你写的指令再执行一次就行了。
• AOF的主要朱勇是解决了数据持久化的实时性，目前已经是Redis持久化的【主流方式】，也就是两者优先使用AOF

AOF写数据过程

AOF写数据过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RqlU8KQL-1661244512728)(en-resource://database/5187:1)]

AOF写数据三种策略(appendfsync)

• always（每次）【不建议使用，除非你对指令准确度特别高】
  • 你这边只要来一个命令，我就把它放在AOF文件中。
  • 每次写入操作均同步到AOF文件中，数据零误差，性能较低
• everysec（每秒）【建议使用，同时也是默认配置(不写配置时)】
  • 以上，别那么频繁。每一秒存储一次。
  • 每秒将存储区中的指令同步到AOF文件中，数据准确性较高，性能较高
  • 在系统突然宕机的情况下丢失1秒内的数据
• no（系统控制）
  • 由系统控制多长时间同步到AOF文件中。
  • 由操作系统控制每次同步到AOF文件的周期，整体过程就不归我们管了。

AOF功能开启
进入conf文件去修改配置文件XXX.conf

• 配置：appendonly yes|no
• 作用
  • 是否开启AOF持久化功能，默认不开启状态
• 配置：appendfsync always|eversec|no
• 作用
  • AOF写数据策略

演示：

• vim redis-6379.conf

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u8Go3zcw-1661244512728)(en-resource://database/5189:1)]

• 启动redis：redis-server redis-6379.conf 【root下】

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pEI9v6v0-1661244512729)(en-resource://database/5191:1)]

• 到客户端连接一下：redis-cli

• always是每次执行改变的命令，就会在AOF文件中同步一下。

• 改一下配置文件：appendfsync everysec 每秒一次，太快了，几乎看不出always的区别

• 进程重启一下

• ps -ef | grep redis-

• kill -s 9 3776

• 再次启动redis：redis-server redis-6379.conf

还有一个配置：文件名的自定义

• 配置：appendfilename filename

• 作用：

  • AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

• 配置：dir

• 作用：

  • AOF持久化文件保存路径，与RDB持久化文件保持一致即可

AOF写数据遇到的问题

【如果连续执行如图指令该如何处理】
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ir9lfIuy-1661244512729)(en-resource://database/5193:1)]

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将同一个数据的若干条命令执行结果转换成最终结果数据对应的指令进行记录。这个重新整理的过程就是AOF重写。

AOF重写作用

1. 降低磁盘占用量，提高磁盘利用率
2. 提高持久化效率，降低持久化写时间，提高IO性能
3. 降低数据恢复复用时，提高数据恢复效率

AOF重写规则

• 进程内已超时的数据不再写入文件

• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据写入命令。

  • 如del key1 、hdel key2、srem key3、set key4 111、set key4 222等

• 对同一数据的多条写命令合并为一条命令

  • 如Ipush list1 a，Ipush list1 b，Ipush list1 c 可以转化为Ipush list1 a b c.
  • 为防止数据量过大造成客户端缓冲区溢出，对list\set\hash\zset等类型，每条指令最多写入64个元素。

AOF重写方式

• 手动重写（执行一条指令就重写了）：bgrewriteaof
  • bg：后台 re：重 write：写 aof：AOF文件
• 自动重写：
  • auto-aof-rewrite-min-size size
  • auto-aof-rewrite-percentage percent

演示：

1. 手动重写演示
   1. 修改配置文件：
      1. 每次保存
      2. 修改AOF文件名
      3. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wS9IUDoH-1661244512729)(en-resource://database/5195:1)]
   2. 查看进程：ps -ef | grep redis-
   3. 杀死进程：kill -s 9
   4. 重启进程：redis-server redis-6379.conf
   5. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W2ofCGR1-1661244512730)(en-resource://database/5197:1)]
   6. 添加数据
      1. set name 123
      2. set name 234
      3. set name 345
      4. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dNaTUVLQ-1661244512730)(en-resource://database/5201:1)]
   7. 重写：bgrewriteaof
      1. 变小了
      2. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yT8dCY2v-1661244512730)(en-resource://database/5199:1)]
      3. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SyGJpVBS-1661244512730)(en-resource://database/5205:1)]
      4. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0T0HeUpC-1661244512731)(en-resource://database/5203:1)]

工作原理

AOF手动重写工作原理–bgrewriteaof指令
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Jp0rAwtm-1661244512731)(en-resource://database/5207:1)]

AOF自动重写方式

• 自动重写触发条件设置：
  • auto-aof-rewrite-min-size size 达到这个大小就重写
  • auto-aof-rewrite-percentage percent 增量的配置，自动重写的百分比
• 自动重写触发比对参数（运行指令info Persistence获取具体信息）
  • aof_curnt_size
  • aof_base_size 基础尺寸
• 自动重写触发条件
• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-px1k3oSj-1661244512731)(en-resource://database/5209:1)]
• 这个实验并没有做。

AOF工作流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ia3hJdig-1661244512732)(en-resource://database/5211:1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-goFAKhBh-1661244512732)(en-resource://database/5213:1)]

RDB与AOF区别

RDB VS AOF

RDB与AOF的选择之惑

                                                                                 ——此文档为学习笔记！