深入理解Redis系列之持久化

redis持久化配置

redis.conf

// RDB配置

save 900 1

save 300 10

save 60 10000

// AOF配置

appendonly yes

//AOF三种同步方式

# appendfsync always

appendfsync everysec

# appendfsync no

RDB配置对应saveparams参数：

dirty：距离上一次成功执行SAVE或BGSAVE命令之后，服务器对数据库状态进行了多少次修改

RDB和AOF对比

因为AOF更新频率通常比RDB文件高，所以：

如果服务器开启了AOF，那么服务器优先使用AOF文件来还原数据库状态
只有在AOF关闭状态，服务器才使用RDB文件还原数据库状态

RDB

RDB手动触发和自动触发

手动触发分别对应save和bgsave命令

SAVE：阻塞redis进程，直到RDB文件创建完毕为止
BGSAVE：不阻塞，派生出一个子进程，然后由子进程负责创建RDB文件

BGSAVE命令执行时，客户端发送SAVE或BGSAVE命令会被拒绝，避免父进程和子进程同时执行两个rdbSave调用，防止产生竞争条件

BGSAVE命令执行时，客户端发送BGSAVE命令会被拒绝，避免两个父进程同时执行两个rdbSave调用，防止产生竞争条件

BGSAVE命令执行时，客户端发送BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行；若是BGREWRITEAOF命令正在执行，客户端发送BGSAVE命令会被拒绝

bgsave执行流程(注意第二步，fork操作创建子进程时，父进程会阻塞)

redis内部自动触发

使用save相关配置，如save m n，表示m秒内存在n次修改，自动触发bgsave
如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
执行debug reload命令重新加载redis时，也会触发save操作
默认情况下执行shutdown命令时，如果没有开启AOF持久化功能，则自动执行bgsave

RDB文件载入：在服务器启动时，检测到RDB文件存在，自动载入

RDB文件结构

RDB结构：

REDIS： 5字节，保存"REDIS"5个字符
db_version：4字节，记录RDB文件的版本号

database部分：

database 0 代表0数据库所有键值对数据；database 3 代表3数据库所有键值对数据；

SELECTDB：1字节，代表接下来要读一个数据库分区号

AOF

AOF主要作用：解决数据持久化的实时性

AOF工作流程

所有写入命令会追加到aof_buf（缓冲区）中
AOF缓冲区根据对应的同步策略向硬盘做同步操作
随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
当Redis服务器重启时，可以加载AOF文件进行数据恢复

AOF一些问题

AOF为何直接采用文本协议？

文本协议具有很好的兼容性
开启AOF后，所有写入命令都包含追加操作，直接采用文本协议格式，避免二次处理开销
文本协议具有可读性，方便直接修改和处理

AOF为何把命令追加到aof_buf中？

Redis使用单线程响应命令，如果每次写AOF命令都直接写入磁盘，那么性能完全取决当前硬盘负载。另写入缓冲区，可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

文件同步

重写机制

AOF重写作用：

降低文件占用空间
更小的AOF文件可以更快的被redis加载

重写机制命令或配置：

手动触发：bgrewriteaof命令
自动触发配置：

auto-aof-rewrite-min-size：AOF重写时，文件最小体积，默认64MB
auto-aof-rewrite-percentage：当前AOF空间(aof_current_size)与上一次重写后AOF文件空间(aof_base_size)的比值
自动触发时机：aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

重写流程：

1. 执行AOF重写请求
1. 父进程执行fork创建子进程
1. 1）父进程fork操作完成后，继续响应其他命令；所有修改命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制正确 2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用AOF重写缓冲区保存这部分数据，防止AOF文件生成期间丢失这部分数据
子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认32MB，防止单次刷盘过多造成硬盘阻塞
新的AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下aof_*相关统计
父进程把AOF重写缓冲区的数据写入新的AOF文件
使用新的AOF文件替换老文件，完成AOF重写

重写AOF文件为什么可以变小：

进程内已经超时的数据不再写入文件
旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等；重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据写入命令
多条写命令可以合并为一个；为防止单条命令过大，造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF追加阻塞

流程：

主线程负责写入AOF缓冲区
AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间
主线程负责对比上次AOF同步时间：

如果距离上次同步时间小于2s，直接返回
如果距离上次同步时间大于2s，主线程将会阻塞，直到同步操作完成

可以发现两个问题：

everysec配置最多丢失2s数据，不是1s
如果系统fsync缓慢，将会导致redis主线程阻塞，影响效率

每当AOF追加阻塞事件发生时，在info persistence统计中，aof_delayed_fsync指标会累加

一些命令

save //等待RDB文件创建完毕

bgsave //fork生成子进程

config set dir {newDir} //RDB文件保存在dir目录下

config set dbfilename {newFileName} //RDB文件名

config set rdbcompression {yew|no}//默认采用LZF算法进行压缩，默认开启，此命令动态进行修改是否进行压缩

bgrewriteaof //aof文件重写

redis-cli config set appendonly yes //开启aof

redis-cli config set save “” //关闭rdb

info stats

redis-check-aof –fix

参考：

《Redis开发与运维》

《Redis设计与实现》

http://www.redis.cn/documentation.html

https://mp.weixin.qq.com/s/GwjQalQ9ZkBbTBtEKpbkMw

http://www.redis.cn/topics/persistence.html