Redis之持久化实操(Linux版)

注：本文是基于Ubuntu 20.04.3系统上Redis v5.0.7进行讲解

1.持久化介绍

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。
防止数据的意外丢失，确保数据安全性

2.RDB相关配置

以下和save相关的是1234;
和bgsave相关的是12345;
和RDB手动启动方式相关的是12346;(虽然RDB手动启动方式是RDB，但与5无关)
和AOF相关的是2789;
和AOF手动重写相关的是2789;
和AOF手动自动重写相关的是2789 10 11;

1.dbfilename dump.rdb：
说明：设置本地数据库文件名，默认值为 dump.rdb
经验：通常设置为dump-端口号.rdb
2.dir：
说明：rdb文件的路径
经验：通常设置成存储空间较大的目录中，目录名称data
3.rdbcompression yes：
说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
4.rdbchecksum yes：
说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险
5.stop-writes-on-bgsave-error yes：
说明：后台存储过程中如果出现错误现象，是否停止保存操作
经验：通常默认为开启状
6.save second changes：
作用:满足限定时间范围内key的变化数量达到指定数量即进行持久化
参数:
second：监控时间范围
changes：监控key的变化量
7.appendonly no：
appendonly yes|no
是否开启AOF持久化功能，默认为不开启状态
8.appendfsync everysec：
appendfsync always|everysec|no
AOF写数据策略,默认everysec
9.appendfilename “appendonly.aof” ：
appendfilename filename
AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof，AOF持久化文件保存路径与RDB持久化文件一致
10.auto-aof-rewrite-percentage 100：
auto-aof-r ewrite-percentage percentage
11.auto-aof-rewrite-min-size 64mb：
auto-aof-rewrite-min-size size
指自动重写的百分比

下载redis后默认配置：

3.RDB手动启动方式-save

下载redis后默认数据目录：

把这两个都删了

进行保存，会再生成一个dump.rdb文件

save

再次进行保存，虽然是二进制文件，但隐隐约约可以发现rdb文件发生了变化

关闭服务端

再次开启服务端

客户端仍然可以查看得到刚刚我们存的键

4.RDB手动启动方式-save工作原理

命令如下，返回“save”

save

注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用(如果以下save时间太长的话，get将阻塞)

5.RDB手动启动方式-bsave工作原理

命令如下，返回“Background saving started”

bgsave

用于解决save指令的“数据量过大，单线程执行方式造成效率过低如何处理”问题；
手动启动后台保存操作，但不是立即执行；
bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作（即“RDB自动启动方式-修改配置”）都采用bgsave的方式，save命令可以放弃使用，bgsave与save用的是一个rdb文件

6.RDB手动启动方式-bgsave

紧接着save操作，发现提示“Background saving started”

查看dump.rdb,隐隐约约发现里面添加了个beijing

7.RDB自动启动方式-修改配置

与以下配置有关：
save second changes

与windos RDB操作一样

8.RDB自动启动方式-修改配置工作原理

1."自动启动方式配置"要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的：
比如不要设置成“两个key变一次就存储一次”频度过高
2."自动启动方式配置"中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系：
比如先“设置的时间短又变化的量又少，设置成1秒变化1次key”，再设置一个成“100秒变化100次key”，“100秒变化100次key”会被“1秒变化1次key”给限制住，所以说一般second小的时候changes就设置大，second大的时候changes就设置小
3."自动启动方式配置"启动后执行的是bgsave操作：
save 900 1的含义是：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave

每次的指令都会返回一个结果给redis，必须符合以下三个条件：
1.会对数据产生影响：
比如get操作接没有产生影响
2.真正产生了影响：
如果产生对数据了影响但数据值却没有产生变化，这不叫“真正产生了影响”，必须使数值发生了变化才算真正产生了影响
3.不进行数据比对：
即如果现在我们对同一个key进行了连续两次的set指令，是不会进行数据比对的，redis认为是两个key发生了变化

9.RDB三种启动方式对比

注:”RDB自动启动方式：与“bgsave”一样，在此省略

10.RDB特殊启动形式

10.1全量复制

全量复制:
在主从复制中详细讲解

10.2服务器运行过程中重启服务器

如果服务器运行过程中重启服务器的话，会进行自动启动RDB保存

debug reload

10.3服务器运行过程中关闭服务器时指定保存数据

如果服务器运行过程中重启服务器的话，会进行自动启动RDB保存
默认情况下执行shutdown命令时，自动执行bgsave(如果没有开启AOF持久化功能）

shutdown save

11.RDB优缺点

RDB优点:
1.RDB是一个紧凑压缩的二进制文件，存储效率较高
2.RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
3.RDB恢复数据的速度要比AOF快很多
4.应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点
1.RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
2.bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能,内存产生额外消耗
3.Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象
比如：2.0redis的rdb文件4.0是读不出来的，其实也有解决方案，在2.0中通过程序把数据保存到文件后，再给恢复成4.0的那种数据源格式，4.0就可以读不出来的
4.存储数据量较大，效率较低,基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
5.大数据量下的IO性能较低
6.宕机带来的数据丢失风险

12.AOF介绍

对于RDB的缺点，AOF进行改正，AOF的解决思路如下：
1.不写全数据，仅记录部分数据
2.降低区分数据是否改变的难度，改记录数据为记录操作过程
3.对所有操作均进行记录，排除丢失数据的风险

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

13.AOF写数据原理

当服务器接收到了我们执行的指令后，服务器并没有马上记录到aof文件里，而是给放到了一个临时的区域，即“AOF将要操作的写命令”所对应的一个缓冲区，到了一定阶段以后，将缓冲过去里的命令同步到aof文件里即可

14.AOF写数据三种策略(appendfsync)

1.always(每次）
每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用
2.everysec（每秒）
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高,建议使用，在系统突然宕机的情况下丢失1秒内的数据
3.no（系统控制）
由操作系统控制每次同步到AOF文件的周期，整体过程不可控

15.AOF重写前言

看以下问题，按照传统思路，AOF会将6条数据都给写入aof文件，随着命令不断写入AOF，文件会越来越大

以下是视频截屏：

16.AOF重写介绍

为了解决以上演示的那个问题，Redis引入了AOF重写机制压缩文件体积。
AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

17.AOF重写作用

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

18.AOF重写规则

1.进程内已超时的数据不再写入文件
2.忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令:
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
3.对同一数据的多条写命令合并为一条命令:
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

19.AOF手动重写方式-bgrewriteaof

bgrewriteaof

以下两个演示是视频截屏：

演示1：
多次set值

执行完bgrewriteaof输出“Background append only file rewriting started”后立马切换到“127.0.0.1：6379”，这并不代表已经重写完成了，我们只有在日志文件中才能看到是否已经重写完成

演示二：
多次lpush

20.AOF自动重写方式-修改配置

1.主要和以下配置有关:
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
2.自动重写触发比对参数（ 运行指令info
获取具体信息 ）:
aof_current_size ：指当前aof缓冲里面有了多少了，注意这并不是指存储的指令的数量！
aof_base_size：
3.自动重写触发条件:
如下图：

info

在Persistence下面：

21.AOF手动重写方式-bgrewriteaof工作原理

"AOF手动重写方式bgrewriteaof工作原理"与bgsave很类似

22.AOF重写流程

23.RDB与AOF区别

AOF优先于RDB启动

24.RDB与AOF选择问题

1.据非常敏感，建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
2.数据呈现阶段有效性，建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
3.综合比对
1）RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
2）如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
3）如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
4）灾难恢复选用RDB
5）双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量R

25.持久化应用场景

以下划红线的都不需要持久化
Tip1：只需把最后一个id+1就行了，不用持久化，临时存储就行了
Tip3：是指“缓存里面的数据是否需要持久化的意思”，由于缓存的数据是从数据库来的，所以不用持久化
Tip4：购物车是存在数据库里的
Tip5：对于抢购数据来说，速度需要非常快，所以需要持久化，而且优惠券也少
Tip6：类似于Tip7，只是临时的，需要持久化
Tip12：如果黑名单是永久存储的话，数据里存；如果黑名单是短期存储的话，redis里存；白名单基本全是数据库里存储

最后

以上就是健壮电源为你收集整理的Redis之持久化实操(Linux版)Redis之持久化实操(Linux版)的全部内容，希望文章能够帮你解决Redis之持久化实操(Linux版)Redis之持久化实操(Linux版)所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。