Redis学习之一文弄懂Redis持久化机制: RDB 及 AOF

1.什么是持久化

持久化就是将有用的数据以某种技术保存起来，将来可以再次取出来应用，数据库技术，将内存数据一文件的形式保存在永久介质中(磁盘等)都是持久化的例子。

2.为什么Redis要做持久化

redis的数据都是存放到内存中的，如果服务器突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis在内存中的数据不会丢失，这种机制就叫Redis持久化机制。

3.Redis持久化机制

3.1 RDB

1. 概念

(Redis DataBase) RDB 其实就是把数据以快照的形式保存在磁盘上，可以理解成把当前时刻的数据拍成一张照片保存下来；
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为 dump.rdb。

2. 配置

#   禁用快照(系统某个状态下的各种数据记录在一个文件里)
#   save ""

save 900 1    # 在900秒(15分钟)内，如果至少有1个key发生变化，则内存快照，即持久化
save 300 10    # 在300秒(5分钟)内，如果至少有10个key发生变化，则内存快照，即持久化
save 60 10000    # 在60秒(1分钟)内，如果至少有10000个key发生变化，则内存快照，即持久化

# 若bgsave快照出现问题则停止写入
stop-writes-on-bgsave-error yes

# 对于存储到磁盘中的快照，是否进行LZF压缩存储，若不想消耗CPU进行压缩处理可关闭
rdbcompression yes

# 5.0之后，一个CRC64的校验就被放在了文件末尾，当存储或者加载rbd文件的时候会有一个10%左右的性 
# 能下降，为了达到性能的最大化，你可以关掉这个配置项
rdbchecksum yes

# 通过RDB方式生成快照文件名
dbfilename dump.rdb

3. RDB持久化触发机制

3.1. save

该命令会阻塞当前Redis服务器，执行 save 命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

3.2. bgsave

fork: 用于创建一个子进程，不是子线程。fork() 出来的进程共享其父类的内存数据。仅仅是共享 fork() 出子进程的那一刻的内存数据，后期主进程修改数据对子进程不可见，同理，子进程修改的数据对主进程也不可见。

执行该命令时，Redis进程判断是否存在子进程，若没有则执行 fork 操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。Redis会在后台异步进行快照操作，同时还可以响应客户端请求。阻塞只发生在 fork 阶段，时间很短。基本上Redis内部所有的RDB操作都是采用 bgsave 命令。

3.3. 自动触发

自动触发是由我们的配置文件来完成的。在redis.conf配置文件中：

save 900 1    #在900秒(15分钟)内，如果至少有1个key发生变化，则内存快照，即触发bgsave进行持久化
save 300 10    #在300秒(5分钟)内，如果至少有10个key发生变化，则内存快照，即触发bgsave进行持久化
save 60 10000    #在60秒(1分钟)内，如果至少有10000个key发生变化，则内存快照，即触发bgsave进行持久化

若不想进行持久化注释即可

3.4. save 与 bgsave 比较

	save	bgsave
IO	同步	异步
阻塞	是	是（只在fork时阻塞）
优点	不消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	消耗额外内存执行fork操作创建子进程

3.2 AOF

1. 概念

（Append On File) Redis会将每一个收到的写命令都通过write函数追加到文件中，类似于日志操作。

2. 配置

# 是否开启AOF持久化机制
appendonly no
 
# 指定AOF持久化生成的文件名
appendfilename "appendonly.aof"
 
# appendfsync always    # 这种模式下每次write后都会调用fsync    
appendfsync everysec    # 每秒调用一次fsync
# appendfsync no    # write后不会有fsync调用，由操作系统自动调度刷磁盘，性能是最好的
 
# 若设置为yes相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这
# 样并不会造成阻塞(因为没有竞争磁盘)，但是如果这个时候redis挂掉，就会丢失数据
# 若设置为yes相当于将appendfsync设置为yes，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
no-appendfsync-on-rewrite no
 
# aof文件增长比例，指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后， 
# 重新将整个内存写到aof文件当中，以反映最新的状态(相当于bgsave)。这样就避免了，aof文件过大而
# 实际内存数据小的问题(频繁修改数据问题)
auto-aof-rewrite-percentage 100
 
# aof文件重写最小的文件大小，即最开始aof文件必须要达到这个文件时才触发，后面的每次重写就不会根
# 据这个变量了(根据上一次重写完成之后的大小).此变量仅初始化启动redis有效.如果是redis恢复时，
# 则lastSize等于初始aof文件大小
auto-aof-rewrite-min-size 64mb

# 指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写
# 错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败
aof-load-truncated yes

# 是否开启RDB和AOF的混合持久化
aof-use-rdb-preamble yes

3. AOF文件重写

AOF的持久化方式使持久化文件会变的越来越大。为了压缩生成的AOF文件，Redis提供了bgrewriteaof命令，将内存中的数据以命令的方式保存到临时文件中，同时fork出一条子进程来将AOF文件重写。

4. AOF持久化触发机制

appendfsync always    # 这种模式下每次write后都会调用fsync    
appendfsync everysec    # 每秒调用一次fsync
appendfsync no    # write后不会有fsync调用，由操作系统自动调度刷磁盘，性能是最好的

	always	everysec	no
优点	不丢失数据	每秒一次fsync调用	性能好
缺点	IO开销较大	丢一秒数据	不可控

3.3 RDB与AOF优缺点及比较

	RDB	AOF
优点	1.RDB文件紧凑，全量备份，非常适合用于进行备份及灾难恢复；2.异步生成RDB文件，主进程不需要进行任何磁盘IO操作；3.RDB 恢复大数据集时的速度比 AOF 的恢复速度快。	1.AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。2.AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不易破损。3.AOF文件即使过大，因为存在重写操作，不会影响客户端的读写。4.AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
缺点	RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。	1.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。2.AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。3.以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。