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