本文主要是介绍Redis持久化梳理,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
1.redis的持久化主要是为了恢复数据,而不是保存数据;
2.redis的持久化不能保证数据的完整性;
3.查看持久化信息的命令,默认rdb开启
127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1637570277
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:2314240
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
1.RDB
* redis database,redis默认的持久化方式,默认是开启的。
* rdb文件默认保存在 /usr/local/bin 中,文件名为:dump.rdb
* rdb是保存这一刻的数据,不关注过程;
触发快照的方式:
* 符合自定义配置的快照规则,默认的配置为:
# save "" 表示不使用rdb快照,此配置下不能使用主从结构
save 900 1 表示15分钟(900秒钟)内至少1个键被更改则进行快照。
save 300 10 表示5分钟(300秒)内至少10个键被更改则进行快照
save 60 10000 表示1分钟内至少10000个键被更改则进行快照。
* 执行save或者bgsave命令(save 在主线程中执行,会阻塞主线程,bgsave 是创建子进程写)
* 执行flushall命令
* 执行shutdown命令
* 执行主从复制操作(第一次)
RDB执行流程
1. Redis父进程首先判断:当前是否在执行save,或bgsave/bgrewriteaof(aof文件重写命令)的子
进程,如果在执行则bgsave命令直接返回。
2. 父进程执行fork(调用OS函数复制主进程)操作创建子进程,这个过程中父进程是阻塞的,Redis
不能执行来自客户端的任何命令。
3. 父进程fork后,bgsave命令返回”Background saving started”信息并不再阻塞父进程,并可以响
应其他命令。
4. 子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换。
(RDB始终完整)
5. 子进程发送信号给父进程表示完成,父进程更新统计信息。
6. 父进程fork子进程后,继续工作.
RDB文件格式(了解即可,后续用到了再详细查询)–可以用二进制查看器查看具体内容
与RDB相关的配置
stop-writes-on-bgsave-error yes
yes:当后台备份时候反生错误,前台停止写入,默认是yes
no:不管死活,就是往里写
rdbcompression yes
对于存储到磁盘中的快照,是否启动LZF压缩算法
yes,启动,默认是yes
no,不启动(不消耗cpu资源)
rdbchecksum yes
在存储快照后,是否启动CRC64算法进行数据校验,默认yes
开启后,大约增加10%左右的CPU消耗;
如果希望获得最大的性能提升,可以选择关闭;
dbfilename "dump.rdb" 快照备份文件名字
dir "/usr/local/bin" 快照备份文件保存的目录,默认为当前目录
优缺点
优点:RDB是二进制压缩文件,占用空间小,便于传输(传给slaver)
主进程fork子进程,可以最大化redis的性能,主进程不能太大,复制过程中主进程阻塞;
缺点:不能保证数据的完整性,会丢掉最后一次快照后的所有修改
2.AOF
* append only file默认不开启
* 以日志的形式记录每个操作;只记录写操作;
* 数据写成功后,才记录;
* 只许追加文件,不允许改写文件;
* redis在启动之初会读取该文件从头到尾执行一遍,这样来重新构建数据;
* AOF和RDB两种备份策略同时开启,系统优先载入AOF恢复数据,AOF比RDB数据保存的完整性更高;
开启方式
可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的。
dir ./
默认的文件名是appendonly.aof,可以通过appendfilename参数修改
appendfilename appendonly.aof
AOF原理
命令传播
Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
缓存追加
AOF 程序根据接收到的命令数据,将命令转换为网络通讯协议的格式,然后将协议内容追加
到服务器的 AOF 缓存中。
文件写入和保存
AOF 缓存中的内容被写入到 AOF 文件末尾,如果设定的 AOF 保存条件被满足的话,
fsync 函数或者 fdatasync 函数会被调用,将写入的内容真正地保存到磁盘中。
AOF 保存模式
always:每次数据变更,就会立即记录到磁盘,性能较差,但数据完整性好
everysec:默认设置,异步操作,每秒记录,如果一秒内宕机,会有数据丢失
no:不追写,操作系统控制写回,每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,
由操作系统决定何时将缓冲区内容写回磁盘
三种情况下触发save
* redis被关闭
* AOF功能被关闭
* 系统的写缓存被刷新(可能是缓存已经被写满,或者定期保存操作被执行)
这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。
AOF 重写
* fork子进程在后台进行重写;
* 为了保证主进程的写不受影响,增加了一个AOF重写缓存;写原AOF文件时,同步写缓存;
* 手工触发重写命令:BGREWRITEAOF
* 自动触发重写配置:
# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过,以 启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小,也就是文件大小小于64mb的时候,不需要进行优化
auto-aof-rewrite-min-size 64mb
3. AOF和RDB混合持久化
* 开启混合持久化参数:aof-use-rdb-preamble yes 默认就是yes
* Redis 4.0 开始支持 rdb 和 aof 的混合持久化。如果把混合持久化打开,aofrewrite 的时候就直接把 rdb 的内容写到 aof 文件开头。
* RDB的头+AOF的身体---->appendonly.aof
* 恢复的时候,先按RDB内容进行恢复,然后按照AOF内容恢复
4.AOF和RDB使用注意事项
* 默认开启RDB,如果不开启,则不能使用主从;
* 作为缓存,使用RDB,性能高,但是数据量过大时,fork子进程时间长,影响性能;
* 作为缓存,不建议只使用aof,性能差;
* 作为缓存,追求单机的极致性能,可以RDB和AOF都不开;
* 作为内存数据库,使用rdb+aof,数据不容易丢失;
* 数据还原时,如果有rdb+aof,则还原aof,因为aof相对数据要完整;
这篇关于Redis持久化梳理的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!