-
第十三章 【高级篇】分布式缓存Redis6.x持久化配置实战-AOF和RDB
第1集 Redis6.x持久化介绍和RDB讲解
简介: Redis6.x持久化配置介绍和RDB讲解
-
Redis持久化介绍
- Redis是一个内存数据库,如果没有配置持久化,redis重启后数据就全丢失
- 因此开启redis的持久化功能,将数据保存到磁盘上,当redis重启后,可以从磁盘中恢复数据。
-
两种持久化方式
- RDB (Redis DataBase)
- AOF (append only file)
-
RDB持久化介绍
-
在指定的时间间隔内将内存中的数据集快照写入磁盘
-
默认的文件名为dump.rdb
-
产生快照的情况
-
save
- 会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止
-
bgsave
- fork创建子进程,RDB持久化过程由子进程负责,会在后台异步进行快照操作,快照同时还可以响应客户端请求
-
自动化
- 配置文件来完成,配置触发 Redis的 RDB 持久化条件
- 比如 "save m n"。表示m秒内数据集存在n次修改时,自动触发bgsave
-
主从架构
- 从服务器同步数据的时候,会发送sync执行同步操作,master主服务器就会执行bgsave
-
-
-
优点
- RDB文件紧凑,全量备份,适合用于进行备份和灾难恢复
- 在恢复大数据集时的速度比 AOF 的恢复速度要快
- 生成的是一个紧凑压缩的二进制文件
-
缺点
- 每次快照是一次全量备份,fork子进程进行后台操作,子进程存在开销
- 在快照持久化期间修改的数据不会被保存,可能丢失数据
-
核心配置
- dir 持久化文件的路径
- dbfilename 文件名
#任何ip可以访问
bind 0.0.0.0
#守护进程
daemonize yes
#密码
requirepass 123456
#日志文件
logfile "/usr/local/redis/log/redis.log"
#持久化文件名称
dbfilename xdclass.rdb
#持久化文件存储路径
dir /usr/local/redis/data
#持久化策略, 10秒内有个1个key改动,执行快照
save 10 1
######之前配置######
#导出rdb数据库文件压缩字符串和对象,默认是yes,会浪费CPU但是节省空间
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
第2集 分布式缓存Redis6.x持久化配置RDB操作实战
简介: 分布式缓存Redis6.x持久化配置RDB操作实战
-
配置持久化
- dir 持久化文件的路径
- dbfilename 文件名
-
save
-
bgsave
-
配置文件触发
bind 0.0.0.0
daemonize yes
requirepass 123456Xdclass
logfile "/usr/local/redis/log/redis.log"
dbfilename xdclass.rdb
dir /usr/local/redis/data
#关闭rdb
#save ""
#10秒2个key变动则触发rdb
save 10 2
#100秒5个key变动则触发rdb
save 100 5
#压缩
rdbcompression yes
#检查
rdbchecksum yes
- 备注: linux内存分配策略
0 表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程
1 表示内核允许分配所有的物理内存,而不管当前的内存状态如何。
2 表示内核允许分配超过所有物理内存和交换空间总和的内存
解决方式
echo 1 > /proc/sys/vm/overcommit_memory
持久化配置
vim /etc/sysctl.conf
改为
vm.overcommit_memory=1
修改sysctl.conf后,需要执行 sysctl -p 以使生效。
第3集 Redis6.x持久化配置AOF介绍和配置实战
简介: Redis6.x持久化配置AOF介绍和配置实战
-
AOF持久化介绍
- append only file,追加文件的方式,文件容易被人读懂
- 以独立日志的方式记录每次写命令, 重启时再重新执行AOF文件中的命令达到恢复数据的目的
- 写入过程宕机,也不影响之前的数据,可以通过 redis-check-aof检查修复问题
-
配置实战
- appendonly yes,默认不开启
- AOF文件名 通过 appendfilename 配置设置,默认文件名是appendonly.aof
- 存储路径同 RDB持久化方式一致,使用dir配置
-
核心原理
- Redis每次写入命令会追加到aof_buf(缓冲区)
- AOF缓冲区根据对应的策略向硬盘做同步操作
- 高频AOF会带来影响,特别是每次刷盘
-
提供了3种同步方式,在性能和安全性方面做出平衡
-
appendfsync always
- 每次有数据修改发生时都会写入AOF文件,消耗性能多
-
appendfsync everysec
- 每秒钟同步一次,该策略为AOF的缺省策略。
-
appendfsync no
- 不主从同步,由操作系统自动调度刷磁盘,性能是最好的,但是最不安全
-
bind 0.0.0.0
daemonize yes
requirepass 123456Xdclass
logfile "/usr/local/redis/log/redis.log"
dbfilename xdclass.rdb
dir /usr/local/redis/data
#save 10 2
#save 100 5
save ""
rdbcompression yes
#对rdb数据进行校验,耗费CPU资源,默认为yes
rdbchecksum yes
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
第4集 Redis6.x持久化配置AOF重新rewrite配置实战
简介: Redis6.x持久化配置AOF重新rewrite配置实战
-
rewrite 重写介绍
- AOF文件越来越大,需要定期对AOF文件进行重写达到压缩
- 旧的AOF文件含有无效命令会被忽略,保留最新的数据命令
- 多条写命令可以合并为一个
- AOF重写降低了文件占用空间
- 更小的AOF 文件可以更快地被Redis加载
-
重写触发配置
-
手动触发
- 直接调用bgrewriteaof命令
-
自动触发
-
auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数
-
auto-aof-rewrite-min-size
- 表示运行AOF重写时文件最小体积,默认 为64MB。
-
auto-aof-rewrite-percentage
- 代表当前AOF文件空间和上一次重写后AOF文件空间(aof_base_size)的比值。
-
-
-
常用配置
# 是否开启aof
appendonly yes
# 文件名称
appendfilename "appendonly.aof"
# 同步方式
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理
# yes表示如果aof尾部文件出问题,写log记录并继续执行。no表示提示写入等待修复后写入
aof-load-truncated yes
第5集 Redis6.x持久化配置AOF+RDB的选择问题和混合模式
简介: Redis6.x持久化配置AOF和RDB的选择问题
-
Redis提供了不同的持久性选项:
- RDB持久化以指定的时间间隔执行数据集的时间点快照。
- AOF持久化记录服务器接收的每个写入操作,将在服务器启动时再次读取,重建原始数据集。使用与Redis协议本身相同的格式以仅追加方式记录命令,当文件太大时,Redis能够重写
- 补充之前的配置
auto-aof-rewrite-min-size
AOF文件最小重写大小,只有当AOF文件大小大于该值时候才可能重写,6.x默认配置64mb。
auto-aof-rewrite-percentage
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比,如100代表当前AOF文件是上次重写的两倍时候才重写。
-
RDB的优缺点
-
优点:
- RDB最大限度地提高了Redis的性能,父进程不需要参与磁盘I/O
- RDB文件紧凑,全量备份,适合用于进行备份和灾难恢复
- 在恢复大数据集时的速度比 AOF 的恢复速度要快
- 生成的是一个紧凑压缩的二进制文件
-
缺点:
- 如果您需要在Redis停止工作时(例如断电后)将数据丢失的可能性降至最低,则RDB并不好
- RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大,Fork可能会非常耗时
-
-
AOF的优缺点
-
优点:
- 数据更加安全
- 当Redis AOF文件太大时,Redis能够在后台自动重写AOF
- AOF以易于理解和解析的格式,一个接一个地包含所有操作的日志
-
缺点:
- AOF文件通常比同一数据集的等效RDB文件大
- 根据确切的fsync策略,恢复的时候AOF可能比RDB慢
-
-
在线上我们到底该怎么做?
- RDB持久化与AOF持久化一起使用
- 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据
- 集群中可以关闭AOF持久化,靠集群的备份方式保证可用性
- 自己制定策略定期检查Redis的情况,然后可以手动触发备份、重写数据;
- 采用集群和主从同步
-
Redis4.0后开始的rewrite支持混合模式
-
就是rdb和aof一起用
-
直接将rdb持久化的方式来操作将二进制内容覆盖到aof文件中,rdb是二进制,所以很小
-
有写入的话还是继续append追加到文件原始命令,等下次文件过大的时候再次rewrite
-
默认是开启状态
-
好处
- 混合持久化结合了RDB持久化 和 AOF 持久化的优点,采取了rdb的文件小易于灾难恢复
- 同时结合AOF,增量的数据以AOF方式保存了,数据更少的丢失
-
坏处
- 前部分是RDB格式,是二进制,所以阅读性较差
-
数据恢复
- 先看是否存在aof文件,若存在则先按照aof文件恢复,aof比rdb全,且aof文件也rewrite成rdb二进制格式
- 若aof不存在,则才会查找rdb是否存在
-
- 来源:https://www.cnblogs.com/Xd17324217006/p/14959912.html