Redis持久化-RDB与AOF

简介

Redis是一种内存数据库，也就是说，在进程期间，所有对数据库的读写操作都是基于内存来进行的。这样的机制在把Redis当作缓存的场景来说是没啥问题。但是更多的情况是，希望Redis中的数据能够持久化，也就是说下次重启时也可以访问到上次留下来的数据，于是Redis持久化就应运而生了，主要的持久化有两种：RDB和AOF…

RDB

RDB是一种全量持久的快照保存，它的内容就是：在某一个特定的时间点上，将Redis数据库中所有的内容生成数据快照，写到dump.rbd二进制文件中，然后保存到存储设备中

触发时机

触发RDB的时机主要有分为手动触发和被动触发：

手动触发

save

save命令可以直接触发Redis进行RDB持久化。但是这是一个阻塞式操作，也就是说Redis服务器必须停止处理请求，等到持久化完毕后，再开始接受请求。如果是数据量比较庞大的话容易造成长时间阻塞，线上环境建议不要使用

bgsave

Redis进程执行fork操作创建子进程，由子进程执行持久化，而父进程可以继续处理请求。但是也会有内存问题。因为要确保数据正确性，所以子进程实际上是通过Copy-On-Write来进行持久化的，也就是说在进行持久化的时候，内存占用会变为原来的两倍大。

被动触发

redis.conf

redis.conf文件下就设置了Redis被动执行RDB的条件：

save 900 1                    # 900秒内如果超过1次key被修改，则发起快照保存

save 300 10                  # 300秒内超过10次key被修改，则发起快照保存

save 60   10000            # 60s内发生10000次可以值修改，则发起快照

参数

• rdbcompression yes 是否开启压缩功能。因为压缩操作需要额外的开销，所以这个操作实际上属于“时间换空间”。而在系统中一般来说CPU资源是要比磁盘资源更宝贵的。但是还是要取决于具体情况
• dbfilename dump.rdb # 数据集文件名

优缺点

优点：

• .rdb文件小，方便备份，并且进行恢复的时候速度很快，因为只需要把数据快照加载进内存中就可以了，适合作冷备
• RDB模式下，服务端的每次写都是写Redis内存，只有在满足一定条件的时候，才会执行一次磁盘IO，所以性能很好

缺点：

• 无法保障数据的准确性。因为RDB并不是实时备份，所以从上一次备份到现在的这部分数据改动是无法还原的。
• 如果数据量很大，而且写操作很频繁时，必然会引起大量的磁盘IO，对性能可能会有严重的影响。

AOF

AOF是Append-Only-File的简称，是一种增量持久化的机制。也就是说：Redis的每一个写操作都会以命令的形式追加到文件末尾，它能保证数据持久化的实时性和准确性。

触发时机

AOF无法手动触发，触发时机可以通过参数设置

参数

• appendonly yes # 启用aof持久化方式。想要启用就要设为yes
• appendfsync always # 每次收到写命令就立即强制写入磁盘，这样可以保证数据的完全正确性，但会严重影响性能
• appendfsync everysec # 每秒钟强制写入磁盘一次，在性能和数据正确性上做了一个折中，是不错的方案

重写机制

随着命令不断写入aof文件中，文件会越来越大，所以AOF也有重写机制来压缩文件的体积。

当达到触发条件时，Redis会fork一个子进程，由子进程建立一个临时文件，然后使用和RDB类似的快照方式，将此时间点上Redis数据库中所有的数据以命令的方式写入临时文件中（以命令的方式就是说，只关心数据的最终结果，不关心数据变化的过程），然后用临时文件替换到原来的aof文件，这就完成了一次重写。

触发时机：

• 手动：直接调用bgrewriteaof命令
• 自动：由auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机：auto-aof-rewrite-min-size表示触发重写时文件的最小内存，默认为64m auto-aof-rewrite-percentage：一个百分值，表示当前aof文件空间和上一次重写完后aof空间比值。默认为100，就是大一倍的时候触发

优缺点：

优点：

• 能更好地保证数据的正确性，因为AOF的持久化基本上是实时更新，所以在数据正确性和实时性上比RDB更加优秀
• AOF文件以append-only的模式写入，没有任何磁盘寻址的开销，所以写入性能非常高
• 适用于灾难性误删除的恢复。比如说不小心执行了flushall命令。此时只要后台的重写还没发生，就可以直接去aof文件中把flushall命令给删除，然后重启，就可以恢复了

缺点：

• aof文件比较庞大，且恢复速度比较慢。因为AOF恢复的原理就是将文件中的命令逐个执行，可能会是一个很慢的操作
• 因为aof进行磁盘IO的频率非常高，尽管它效率高，但是也会对性能有影响

现在基本都是采用RDB+AOF混合持久化的方式了，因为两者可以相辅相成嘛~在恢复数据的时候，先按照RDB进行恢复，保证速度，然后在RDB基础上再按AOF逐条恢复，可以保证数据实时性和正确性。两全其美。

主从服务器恢复时的不同策略

在进行恢复的时候，难免会遇到那些已经过期的键，那服务器是怎么处理这些过期键的呢？其实在主从服务器上实现有所不同：
在主服务器上，恢复的时候遇到了过期键，会将该键忽略，也就是说，主服务器不会加载已经过期的键(当然，这个判断也是需要额外开销的)
在从服务器上，恢复的时候遇到了过期键，不会忽略该键，也就是说，从服务器会把已经过期的键加载进来。为什么可以这样做呢？因为在建立主从关系后，主服务器可以通知从服务器删除过期键，而不需要自己主动删除。这样可以免去判断是否过期这一流程，加快恢复速度