Redis教程

Redis持久化梳理

本文主要是介绍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持久化梳理的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!