深入详解Redis持久化操作( 二 )


图示执行流程
RDB配置
在配置文件中修改 。
对于存储到磁盘中的快照,可以设置是否进行压缩存储 。如果是的话,redis会采用LZF算法进行压缩 。推荐开启 。
rdbcompression yes
在存储快照后,还可以让redis使用CRC64算法来进行数据校验 。推荐开启 。
rdbchecksum yes
当Redis无法写入磁盘的话,直接关掉Redis的写操作 。推荐开启 。
stop-writes-on-bgsave-error yes
rdb文件的保存路径,默认为Redis启动时命令行所在的目录下,可以修改 。
dir ./
修改生成的rdb文件名
dbfilename dump.rdb
AOF 简介
以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作 。
AOF开启
AOF默认不开启,需要修改配置文件开启,改为yes开启
appendonly no
持久化策略
可以设置配置文件中的属性:
:始终同步,每次redis的写入都会立刻记入日志,性能较差但数据完整性比较好 。
:每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失 。
no:redis不主动进行同步,把同步时机交给操作系统 。
appendfsync everysec
持久化流程
所有写命令会被追加到AOF缓冲区内,AOF缓冲区根据AOF持久化策略将操作sync同步到磁盘的AOF文件中,AOF文件大小超过重写策略或手动重写时,会对AOF文件重写,压缩AOF文件容量 。
文件损坏修复
通过/usr/local/bin/redis-check-aof 进行修复
redis-check-aof --fix .aof
文件重写压缩
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集 。可以使用命令进行重写 。
重写原理
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再替换) 。.0版本后的重写,就是把rdb 的快照,以二级制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作 。
重写流程
1.触发重写,判断是否当前有或在运行,如果有,则等待该命令结束后再继续执行 。
2.主进程fork出子进程执行重写操作,保证主进程不会阻塞 。
3.子进程遍历redis内存中数据到临时文件,客户端的写请求同时写入缓冲区和重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失 。
4.子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息 。主进程把中的数据写入到新的AOF文件,期间主进程阻塞 。
5.使用新的AOF文件覆盖旧的AOF文件,完成AOF文件重写 。
图示执行流程
AOF配置
在配置文件中修改 。
yes:客户端的写操作不写入aof文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据 。(降低数据安全性,提高性能)
no:会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞 。(数据安全,但是性能降低)
no-appendfsync-on-rewrite=no
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次重写后大小的一倍且文件大于64M时触发重写 。虽然可以节约大量磁盘空间,减少恢复时间,但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写 。