redis持久化：rdb和aof

redis持久化：rdb和aof

什么是持久化

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复数据就是直接将快照文件读取到内存中。单独创建(fork)一个子进程进行操作，将持久化的数据写到一个临时文件中，等持久化完成了，临时文件替换掉上次持久化的文件。

rdb

​ RDB即redis database，它是redis默认采用支持持久化的方式。RDB通过快照实现持久化的支持，当满足一定条件时，RDB将对内存中的所有数据生成快照，并存放到硬盘中，默认存放在当前执行redis服务的根目录的dump.rdb中。

配置rdb:

#   save ""  #不执行rdb

save 900 1   #900秒内有一个key被修改，执行rdb持久化
save 300 10
save 60 10000

rdb生成文件，默认dump.rdb，可以配置指定文件名

dbfilename dump.rdb

其他配置：

stop-writes-on-bgsave-error yes #当后台最后一次保存出错，停止redis的写操作。
rdbcompression yes  #当进行持久化时，是否对数据使用LZF算法进行压缩。
rdbchecksum yes  #在存储快照后，是否使用CRC64算法进行数据校验。
dir ./  #存储快照文件的路径，./表示当前路径，可以在进入redis服务后通过config get dir查看。

rdb优点：

• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快;

• RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

rdb缺点：

• 不能避免数据的丢失，至少五分钟保存一次，一旦宕机，至少丢失几分钟的数据
• 每次保存rdb文件时，都要创建(fork)一个子进程来进行，在数据集很庞大的时候，创建子进程很耗时，可能会造成某毫秒内服务器停止处理客户端。

aof

每一个收到的写命令(包括flushall命令)都通过write函数追加到文件appendonly.aof中。默认情况不开启aof操作

appendfsync always  #每次收到写命令就立即强制写入磁盘，性能最低，但是最能保证数据的完整性，不推荐使用
appendfsync everysec  #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
appendfsync no  #从不写入，完全依赖os，性能最好，不能保证数据的完整性

redis对aof新增了一种重写机制，当aof文件大小超过所设定的阈值时，redis会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof手动重写，

以上配置信息说明：redis会记录上一次重写时aof文件的大小，默认配置是当aof文件大小超过上次rewrite后大小的一倍且文件大于64mb时触发。如果启动redis后没有发生过重写，记录aof文件的大小就为启动时加载的aof文件大小。
重写的原理：主进程会fork出一条新的进程对文件重写，遍历新进程的内存数据，每条记录有一条set语句。实际上，重写aof文件的操作并没有读取旧的aof文件，它只针对内存中当前存在的键值重写一个新的aof文件。