redis的持久化

redis的持久化：

	概念：将内存中的数据保存到磁盘，在机器宕机或重启时可以保证数据不丢失。
	
	说明：建议RDB和AOF同时开启，若二者同时开启，则redis在启动时优先使用aof文件来恢复数据，若读取aof文件失败，则读取rdb文件来恢复数据。

	RDB(Redis DataBase)
		概念：
			将内存中的数据进行快照并且存储到磁盘上，即在指定目录下生成一个dump.rdb文件。RDB是redis默认的持久化方式。
			redis启动后可用通过读取rdb文件，将数据再次载入到内存中，一般情况下1G的rdb文件载入到内存的时间大概为20~30秒。
			
		过程：把所有的数据都写到一个临时文件中，然后用这个临时文件替换掉之前的rdb文件。
		
		触发机制：
			手动触发：
				save命令：阻塞Redis当前的进程，直到RDB过程完成为止。若实例占用的内存比较大，则会造成redis服务长时间的不可用。(不建议使用)
				bgsave命令：redis当前进程执行fork操作创建子进程，RDB持久化过程由子进程负责，父进程继续接收并处理客户端发出的请求。阻塞只发生在fork阶段，一般时间很短。
					注意：fork一个进程时，子进程占用的内存空间与父进程相同。
			自动触发：
				达到配置的条件时，自动触发bgsave命令。
				在执行shutdown命令后会自动触发bgsave命令。
		
			配置文件redis.conf：

				# 设置触发快照的条件(Will save the DB if both the given number of seconds and the given number of write operations against the DB occurred.)
				# 格式：save <seconds> <changes>
				save 900 1 		# 900秒内，如果有1个以上(包括1个)的key被修改了，则触发快照。
				save 300 10		# 300秒内，如果有10个以上(包括10个)的key被修改了，则触发快照。
				save 60 10000	# 60秒内，如果有10000个以上(包括10000个)的key被修改了，则触发快照。
				
				# RDB默认会开启，关闭RDB方式的持久化
				save ""
				
				# 设置rdb文件的名称
				dbfilename dump.rdb

				# 设置redis的工作目录，即rdb文件、aof文件所在的目录
				# The working directory.
				# The DB will be written inside this directory, with the filename specified above using the 'dbfilename' configuration directive.
				# The Append Only File will also be created inside this directory.
				dir ./
				
				# 设置rdb文件是否进行压缩，默认为yes。注：压缩rdb文件可以减少磁盘空间的占用，但是需要消耗额外的cpu。
				rdbcompression yes
	
		优点：适合大规模的数据恢复，且数据加载的速度比较快。
		缺点：无法做到数据实时的(秒级)持久化。故数据备份的完整性不高。

	AOF(Append Only File)
		概念：
			将发送到redis服务端的每一条写操作都存储到磁盘上，即在指定目录下生成一个appendonly.aof文件，并且将每次的写操作追加到aof文件的末尾。
			redis启动后通过读取aof文件，将aof文件中的写操作依次再执行一遍，以此来达到数据恢复的效果。
		
		过程：命令写入(append)到缓存区、将缓存区的数据同步到aof文件中(sync)、重新aof文件(rewrite)
			重写aof文件：
				目的：去除数据的中间执行过程，保留最终数据的命令，可大大减小aof文件的大小，从而可以加快数据恢复的速度。
				过程：redis当前进程执行fork操作创建子进程(开销等同于bgsave过程)，子进程根据命令合并规则将内存中的数据写入到新的AOF文件中，最后用新的aof文件替换掉现有的aof文件。
		
		触发机制：
			手动触发：
				BGREWRITEAOF
				若aof文件格式异常，则需要修复aof文件：redis-check-aof --fix appendonly.aof
			自动触发：
				达到配置的条件时，自动触发更新aof文件 或 重新aof文件 的操作。
		
		3)配置文件redis.conf：

			# AOF和RDB可以同时存在，AOF方式的持久化拥有更好的数据完整性和一致性。
			# AOF and RDB persistence can be enabled at the same time without problems. 
			# If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.
	
			# 开启AOF (AOF默认是关闭的appendonly no)
			appendonly yes
			
			# 设置触发更新aof文件的条件
			# appendfsync always	# 同步持久化，即每次执行写操作后都会去更新aof文件。数据完整性好，但是性能较差。
			appendfsync everysec	# 每秒同步一次，是AOP默认触发更新日志的条件。
			# appendfsync no		# 不主动同步，由操作系统来决定什么时候同步(一般为30s)，性能最好但是持久化得不到保障，故不推荐使用该配置。
			
			# 设置触发重写aof文件的条件，多个条件是"与"的关系。
			# redis在重写aof文件后会将aof文件的大小记录下来(若没有重写过aof文件，则这个大小默认是redis启动时aof文件的大小)
			auto-aof-rewrite-percentage 100		# 当前aof文件的大小 超过 上一次重写后记录的大小 的 100%。
			auto-aof-rewrite-min-size 64mb		# 当前aof文件大于等于64mb。注一般不会设置的这么小，看情况设为ngb比较合理。
			
			# 设置aof文件的名称
			# appendfilename appendonly.aof

			# 设置redis的工作目录，即rdb文件、aof文件所在的目录
			dir ./
			
		优点：可以做到数据实时的(秒级)持久化，故数据备份的完整性很高。
		缺点：AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢，故redis在AOF中引入了重写aof文件的机制。

	持久化给redis带来的开销：
		概念：子进程在重写RDB文件和重写AOF文件时会消耗cpu、内存、硬盘等资源。
		
			cpu：子进程负责把进程内的数据分批写入文件，这个过程属于CPU密集操作，通常子进程对单核CPU利用率接近90%。
			
			内存：父进程fork子进程时，子进程默认占用的内存同父进程一样。我们可以修改Linux内存分配的配置，避免物理内存不足导致fork进程失败。
			
			硬盘：往rdb文件或aof文件中写数据的过程中，磁盘io的压力比较大。
				说明：开启AOF的Redis在高流量写入时，如果使用普通机械磁盘，写入吞吐一般在100MB/s左右，这时Redis实例的瓶颈主要在AOF同步硬盘上。

		注意：redis实例不应该和其它对cpu、内存、硬盘敏感的服务混部。