Redis持久化

一、持久化

持久化，顾名思义就是将数据持久保存。因为Redis数据都保存在内存中，对数据的更新将异步地保存到磁盘上。

主流数据库的持久化方式：

• 快照：记录某一时刻数据的状态 （Redis RDB、MySQL Dump）
• 写日志：记录对数据库的修改（Redis AOF、MySQL Binlog、Hbase HLog）

二、RDB：保存某个时间点的全量数据快照

1.什么是RDB

Redis将快照保存在RDB文件，RDB文件是保存在磁盘中的。当Redis想要恢复数据时，将磁盘中的RDB文件恢复到Redis中。

新的RDB文件会覆盖旧的

2.触发机制

（1）手动创建

RDB文件可以通过两个命令来创建：

• SAVE：阻塞Redis服务器进程，直到RDB文件被创建完毕（少被使用）
• BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程。

（2）自动创建

除手动方式，RDB也会自动触发：

1. 根据redis.conf配置里的SAVE m n定时触发（用的是BGSAVE），即如果在m秒中改变了n条数据，就触发bgsave。
2. 主从复制时，主节点自动触发
3. 执行Debug Reload
4. 执行Shutdown且没有开启AOF持久化

3.最佳配置

Redis配置文件中对于RDB的相对最佳配置如下：

1. 不使用自动SAVE，因为这样会导致不确定性；
2. dbfilename 按照端口号取名字
3. dir 选择一个比较大的硬盘路径
4. stop-writes-on-bgsave-error bgsave出问题就停止写入
5. rdbcompression 采用压缩格式
6. rdbchecksum 采用校验和方式

dbfilename dump-${port}.rdb
dir /bigdiskpath
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

4.实验

执行save的时间是很长的，而且在此期间，执行其他命令都会被阻塞。

而bgsave就不会阻塞，且会创建一个子进程：

三、AOF

RDB进行全量快照，具有耗时、耗性能的缺点，同时也不可控，容易丢失数据。

1.什么是AOF

记录下除了查询以外的所有变更数据库状态的指令，并以append的形式追加保存到AOF文件中（增量）。

2.三种策略

在做AOF持久化时，并不是直接写入磁盘，而是先写入缓冲区。

1. always 即缓冲区中每一条命令都fsync到磁盘。
2. everysec 每秒将缓冲区fsync到硬盘。（IO开销较小）（默认策略）
3. no 操作系统决定fsync的时机。

3.日志重写

问题：随着进程运行，AOF文件大小不断增大。
使用日志重写解决，原理如下：

1. 调用fork()，创建一个子进程；
2. 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件；
3. 主进程持续将新的变动同时写到内存和原来的AOF文件中；
4. 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动；
5. 使用新的AOF文件替换掉旧的AOF文件。

这样就可以替换掉一些已经失效的指令，从而减少对硬盘的占用量，以及加快恢复速度。
加粗样式

4.日志重写策略

（1）bgrewriteaof

客户端向服务端发送bgrewriteaof命令，Redis会启动一个子进程进行日志重写。

（2）AOF重写配置

配置名	含义
auto-aof-rewrite-min-size	AOF文件重写需要的尺寸
auto-aof-rewrite-percentage	AOF文件增长率

统计名	含义
aof_current_size	AOF当前尺寸（字节）
aof_base_size	AOF上次启动和重写的尺寸（字节）

只有尺寸大于auto-aof-rewrite-min-size且增长率大于auto-aof-re才会write-percentage自动触发日志重写。

5.AOF重写流程

6.配置

appendonly yes
appendfilename "appendonly-${port}.aof"
appendfsync everysec
dir /bigdiskpath
no-appendfsync-on-rewrite yes （在重写时是否要做append操作）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

四、Redis持久化的取舍与选择

1.RDB对比AOF

当既开启AOF又开启RDB时，在Redis突然关闭时会优先使用AOF。