Redis持久化原理

本文介绍redis数据备份与恢复

Redis持久化原理

redis持久化分为两种 RDB,AOF，默认持久化为RDB。在官方推荐使用中推荐两种都使用，

Redis–RDB持久化介绍

信息介绍
	Redis持久化默认为RDB(Redis DataBase)
	RDB是将数据写入一个临时文件，持久化结束后用这个临时文件替换上次持久化的文件，达到数据恢复
	优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
	缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
配置（在redis.conf中进行查看）
	设置持久化文件名称
	，dbfilename dump.rdb(filename)
	设置持久化文件路径
	dir ./(文件路径)	
	设置同步时间段(或者关系)
	save 900 1	--	15分钟之内至少有一个key进行修改进行快照
	save 300 10 --	5分钟之内至少有10个key进行修改进行快照
持久化过程
	1，当同步条件满足时，Reids用fork函数复制一份当前进程的副本.
	2，父进程继续处理客户端传来的命令，而子进程开始将内存的中数据写入磁盘中的临时文件。
	3，当子进程写入所有数据后用临时文件替换旧的RDB文件
	注：
		手动快照：
			redis -h 127.0.0.1 -p port save | bgsave
			save	--	占用主进程更新会阻塞其他请求
			bgsave	--	使用fork函数复制进行子进程快照操作
注：
	1，使用fork函数进行子进程快照时，复制的子进程与主进程占用资源一致内存()，如果资源不满足会启用虚拟内存，性能非常差。
	2，RDB也可以进行压缩(默认开启)，配置项rdbcomproession  来进行控制
		压缩
			advantage(优点)：减少内存存储空间。
			shortcoming(缺点)：消耗CPU资源。
		不压缩
			advantage：不消耗CPU资源。
			shortcoming：占用存储空间多

Redis–AOF持久化介绍

信息介绍
	AOF持久化默认是禁用的，需要手动配置
	AOF持久化是将执行过的指令记录下来，数据恢复时按照从前到后的顺序进行执行来实现数据恢复
	advantage(优点)：更高的保持的数据完整性，当日志有问题时可用redis-check-aof  来进行修复
		修复日志命令：redis-check-aof --fix ./appendonly.aof
	shortcoming(缺点)：AOF文件比RDB文件大，且恢复速度慢。


配置（在redis.conf中进行查看）
	AOF配置开关
		appendonly no --> yes	
	设置AOF日志文件
		appendfilename "filename.aof"		
	同步方式配置
		一旦输入命令，立即同步到磁盘，保证了完全的持久化，但是速度慢，不推荐  
			appendfsync always
		每秒进行同步
			appendfsync everysec
		不自动同步(服务器资源有空闲的时候更新)，性能最好，持久化没有保障
			appendfsync on
	文件重写：
		造成原因：随着客户端命令的增多，AOF日志文件也逐步增大，所以会进行rewrite
		retrite 相关配置
			当前AOF文件超过上次重写文件的百分之几进行重写，如果没有启动过则以启动时的文件大小为准
				auto-aof-rewrite-percentage 100
			允许重写的文件最小
				auto-aof-rewrite-min-size 64mb
持久化过程
	将快照内容以命令的形式追加到AOF文件中，所有随着追加AOF文件会越来越大，如果想修改可以修改文件内容（信息未同步之前可修改）

总结

持久化过程中 同时有appendonly.aof 和dump.rab 优先使用appendonly.aof,rdb的数据不会恢复内存中

文档转载

Redis持久化介绍
Redis–RDB持久化
Redis–AOF持久化