Redis 持久化配置
前言
Redis为持久化提供了两种方式:
RDB
:在指定的时间间隔能对你的数据进行快照存储。AOF
:记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
性能 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
轻重 | 重 | 轻 |
一、RDB的持久化
在Redis中RDB持久化的触发分为两种:自己手动触发与Redis定时触发
手动触发
- save:会阻塞当前Redis服务器,直到持久化完成,线上应该禁止使用。
- bgsave:该触发方式会fork一个子进程,由子进程负责持久化过程,因此阻塞只会发生在fork子进程的时候。
自动触发
- 根据我们的 save m n 配置规则自动触发;
- 从节点全量复制时,主节点发送rdb文件给从节点完成复制操作,主节点会触发 bgsave;
- 执行 debug reload 时;
- 执行 shutdown (退出)时,如果没有开启aof,也会触发。
1、RDB策略配置文件
# 时间策略
save 900 1
save 300 10
save 60 10000
# 文件名称
dbfilename dump.rdb
# 文件保存路径
dir /home/work/app/redis/data/
# 如果持久化出错,主进程是否停止写入
stop-writes-on-bgsave-error yes
# 是否压缩
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
时间策略
- save 900 1 表示900s内如果有1条是写入命令,就触发产生一次快照,可以理解为就进行一次备份
- save 300 10 表示300s内有10条写入,就产生快照
- save 60 10000 表示60秒内有10000条写入,就产生快照
stop-writes-on-bgsave-error yes
这个配置也是非常重要的一项配置,这是当备份进程出错时,主进程就停止接受新的写入操作,是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统,可以禁止此项配置, 否则请开启。
关于压缩的配置 rdbcompression yes
,建议没有必要开启,毕竟Redis本身就属于CPU密集型服务器,再开启压缩会带来更多的CPU消耗,相比硬盘成本,CPU更值钱。
RDM持久策略关闭方法:
方法1:redis命令窗口里输入命令 config set save ""
即可
方法2:修改配置文件,注释掉三个save
,并打开save ""
的注释,使得 save ""
生效,即可关闭rdb;
save ""
#save 900 1
#save 300 10
#save 60 10000
2、RDM持久化测试
- 在 redis-cli 端创建 key 键值
127.0.0.1:6379> set RDB:test1 mykey1
OK
127.0.0.1:6379> set RDB:test2 mykey2
OK
127.0.0.1:6379> set RDB:test3 mykey3
OK
127.0.0.1:6379> set RDB:test4 mykey4
127.0.0.1:6379> keys *
1) "RDB:test4"
2) "RDB:test3"
3) "RDB:test2"
4) "RDB:test1"
- 退出redis-cli端,查看dump.rdm文件(查看dump.rdm文件需要安装
redis-rdb-tools
工具)
- 重启redis服务,查看数据是否持久化
127.0.0.1:6379> keys *
1) "RDB:test4"
2) "RDB:test3"
3) "RDB:test2"
4) "RDB:test1"
PS:若将dump.rdm
文件删除,则数据丢失;
二、AOF的持久化
AOF的整个流程大体来看可以分为两步
- 第一步是命令的实时写入(如果是 appendfsync everysec 配置,会有1s损耗);
- 第二步是对aof文件的重写;
对于增量追加到文件这一步主要的流程是:命令写入 =》 追加到aof_buf =》同步到aof磁盘
那么这里为什么要先写入buf 再同步到磁盘呢?如果实时写入磁盘会带来非常高的磁盘IO,影响整体性能。
aof重写是为了减少aof文件的大小,可以手动或者自动触发,关于自动触发的规则请看上面配置部分。fork的操作也是发生在重写这一步,也是这里会对主进程产生阻塞。
手动触发: bgrewriteaof
,自动触发 就是根据配置规则来触发
,当然自动触发的整体时间还跟Redis的定时任务频率有关系。
对于上图有四个关键点补充一下:
- 在重写期间,由于主进程依然在响应命令,为了保证最终备份的完整性,它依然会写入到旧的AOF file中,如果重写失败,能够保证数据不丢失。
- 为了把重写期间响应的写入信息也写入到新的文件中,因此也会为子进程保留一个buf,防止新写的file丢失数据。
- 重写是直接把当前内存的数据生成对应命令,并不需要读取老的AOF文件进行分析、命令合并。
- AOF文件直接采用的文本协议,主要是兼容性好、追加方便、可读性高可随时可修改修复。
1、AOF策略配置文件
# 是否开启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时如果有错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes
appendfsync everysec
它其实有三种模式:
- always:把每个写命令都立即同步到aof,很慢,但是很安全
- everysec:每秒同步一次,是折中方案
- no:redis不处理交给OS来处理,非常快,但是也最不安全
一般情况下都采用 everysec
配置,这样可以兼顾速度与安全,最多损失1s的数据。
aof-load-truncated yes
- 如果该配置启用,在加载时发现aof尾部不正确时,会向客户端写入一个log,但是会继续执行
- 如果设置为 no ,发现错误就会停止,必须修复后才能重新加载
2、AOF持久化测试
PS:在测试之前,为数据准确性,需要关闭RDB持久化策略
- 启动redis进程,并进入redis
[root@localhost bin]# redis-server redis.conf
[root@localhost bin]# redis-cli
- 创建测试key键值,并将所有 key 键值清除(为下面恢复数据做准备)
127.0.0.1:6379> set name villian ///创建3个测试键值
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> set home shenzhen
OK
127.0.0.1:6379> flushdb ///清空库中的键值,为下面做测试准备
127.0.0.1:6379> shutdown ///退出redis
- 退出后,在启动目录下自动生成 appendonly.aof 文件
[root@localhost bin]# ls
appendonly.aof
- 进入到该文件查看数据,并删除
flushdb
命令,测试恢复数据
[root@localhost bin]# vim appendonly.aof
*3
$3
set
$4
name
$3
zwl
*3
$3
set
$3
age
$2
20
*3
$3
set
$4
home
$8
shenzhen
*1
$7
flushdb ///此命令为上述清空命令,将此命令删除,并保存退出
- 数据恢复(将上面最后一个
flushdb
命令删除,再重新启动redis-server
服务即可)
127.0.0.1:6379> keys *
1) "home"
2) "name"
3) "age"
AOF持久策略关闭方法:
方法1:redis命令窗口里输入命令 config set appendfsync no
即可
方法2:修改配置文件,将appendonly设置为no,默认是 appendonly no
,即可关闭aof;
三、从持久化中恢复数据
恢复数据,只需要重新启动Redis(命令:redis-server redis.conf
)即可。
启动时会先检查AOF文件是否存在,如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢?因为AOF保存的数据更完整,通过上面的分析我们知道AOF基本上最多损失1s的数据。
四、性能与实践分析
通过上面的分析,我们都知道RDB的快照、AOF的重写都需要fork,这是一个重量级操作,会对Redis造成阻塞。因此为了不影响Redis主进程响应,我们需要尽可能降低阻塞。
降低fork的频率
,比如可以手动来触发RDB生成快照、与AOF重写;控制Redis最大使用内存
,防止fork耗时过长;使用更牛逼的硬件
;合理配置Linux的内存分配策略
,避免因为物理内存不足导致fork失败。
策略:
- 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据,可以关闭持久化,如果丢失数据可以通过其它途径补回;
- 自己制定策略定期检查Redis的情况,然后可以手动触发备份、重写数据;
- 单机如果部署多个实例,要防止多个机器同时运行持久化、重写操作,防止出现内存、CPU、IO资源竞争,让持久化变为串行;
- 可以加入主从机器,利用一台从机器进行备份处理,其它机器正常响应客户端的命令;
- RDB持久化与AOF持久化可以同时存在,配合使用;