redis持久化机制及原理

redis持久化机制

redis提供了两种持久化机制：

• 快照（snapshot）：保存某一时刻的数据状态
• AOF（appen only file）：将写命令记录到日志文件中

快照

• 默认的持久化机制
• 保存以.rdb结尾的文件，于是也被称为RDB方式

快照生成方式

• 客户端执行BGSAVE、SAVE指令

• 服务器配置自动触发

  900 1

  300 10

  60 10000

BGSAVE

当接收到客户端的BGSAVE指令后，redis会调用fork来创建一个子进程，然后子进程负责将快照写入磁盘中，而父进程则继续处理命令请求。

fork：当一个进程创建子进程的时候，底层操作系统会创建该进程的一个副本。在类UNIX系统中，创建子进程的操作会被优化：刚开始的时候，父子进程共享同一份内存，只有在父或子进程对内存进行了写操作后，共享才会结束

SAVE

整个进程都会进行创建快照的操作，在创建快照完成之前redis处于阻塞状态

AOF

• 开启AOF持久化，修改 appendonly yes
• 修改appendfilename "appendonly.aof"指定生成文件名称

日志追加频率

always 【谨慎使用】

• 每个redis写命令都同步到硬盘。
• 如果同一时间内大量涌入写命令，会引发严重的写入放大问题（向硬盘写入大量小文件导致硬盘寿命缩减等问题）

everysec 【推荐】

• 每秒执行一次同步。最多只会丢失1秒内的数据

no 【不推荐】

• 由操作系统决定何时同步。看命，如果一次性堆积大量写操作然后同步，也会导致redis处于阻塞状态

set a 100 执行一万次，即使最终的结果只有一条，但是aof文件中却会保存所有指令。所以日久天长，aof文件可能越来越大，所以就有了AOF重写

AOF重写

• 客户端方式触发重写

  执行BGREWRITEAOF命令 不会阻塞redis服务

• 服务器配置方式自动触发

  修改redis.conf中的两个选项：

  • auto-aof-rewrite-percentage 100

  • auto-aof-rewrite-min-size 64mb

  如果这么设置，当启用了AOF持久化时，当AOF文件体积＞64MB，且上一次重写之后体积增加了100%时，就自动重写一次

  如果重写过于频繁，则可以将auto-aof-rewrite-percentage设置大一些

AOF重写原理

AOF重写，并没有读取旧有的aof文件，而是将整个内存中的数据库用命令的方式写成一个新的aof文件，用来替换就有的aof文件。

重写流程：

1、redis调用fork，产生子进程，子进程生成快照，将快照中的数据信息以写入命令的方式存入临时文件

2、父进程继续处理来自客户端的请求，并将这些请求中所有写命令存入旧aof中的同时，再存入一份到缓存中

3、子进程将快照中的内容以命令形式全部写入临时文件后，通知父进程，然后父进程将刚才缓存的新命令追加到临时文件

4、父进程将临时文件替换旧有的aof文件。后面收到的命令也开始向新的aof文件中追加