【Redis基础】持久化机制

1.RDB

（1） 定义

RBD：snapshotting（快照）是默认方式，将内存中数据以快照的方式写入到二进制文件中，默认文件名为dump.rdb

（2）触发rdbSave过程的方式

• save命令：阻塞Redis服务器进程，直到RDB文件创建完毕为止。
• bgsave命令：派生出一个子进程，然后由子进程负责创建RDB文件，父进程继续处理命令请求。
• master接收到slave发来的sync命令
• 定时save(配置文件中制定）

注：

• fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）,值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

• 执行flushall命令（清空所有数据库），也会产生dump.rdb文件，但里面是空的，无意义

• 命令bgsave与bgrewriteaof不能同时执行，若bgsave正在执行，则bgrewriteaof延迟到bgsave执行完再执行。若bgrewriteaof正在执行，则服务器拒绝执行bgsave命令。

（2） 配置:

• 默认条件

  • save 900 //900秒内如果超过1个key被修改，则发起快照保存
  • save 300 10 //300秒内如果超过10个key被修改，则发起快照保存
  • save 60 10000 //60秒内如果超过10000个key被修改，则发起快照保存

• 服务器状态

  • saveparams属性：记录了保存条件的数组
  • dirty计数器：记录距离上一次save/bgsave命令之后，服务器对数据库状态修改了多少次
  • lastsave属性：是一个Unix时间戳，记录了上一次成功执行save/bgsave命令的时间。

（3）RDB文件结构

• RDB文件结构

  • REDIS长度为5个字节，程序在载入文件时，可以快速检查所载入的文件是否是RDB文件。
  • db_version长度为4个字节，一个字符串表示的整数，记录了RDB文件的版本号。
  • database包含零个或任意多个数据库，以及键值对的数据
  • EOF常量的长度为1个字节，标志着RDB文件正文内容的结束。
  • check_sum是一个8字节长的无符号整数，保存着一个校验和，由前面四部分计算得出的。

• database部分
  

  • SELECTDB常量的长度为1字节，接下来读入的将是一个数据库号码
  • db_number保存着一个数据库号码。
  • key_value_pairs 保存了数据库中的所有键值对数据，由TYPE、key、value组成

• 完整的文件结构图
  

（4）内存中数据与磁盘交互

（5）优点

• 适合大规模的数据恢复，对数据完整性和一致性要求不高

（6）缺点

• 由于快照方式是在一定间隔时间做一次的，若redis出现宕机，就会丢失最后一次快照后的所有修改。

• fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑如何停止

2.AOF

（1） 定义

AOF（appendonly file）:通过保存Redis服务器所执行的写命令来记录数据库状态。

（2）优点

redis将每一个收到的写命令都通过write函数追加到文件中，当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容

（3）缺点

• 由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上，可能会丢失部分数据修改。

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb，aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

（4） 解决方法：通过配置文件进行修改

• Appendonly yes //启用AOF持久化方式
• Appendfsync always //收到写命令就立即写入磁盘（最慢）但是保证完全的持久化
• Appendfsync everysec //每秒写入磁盘一次，在性能和持久化方面做了很好的折中（默认）

• Appendfsync no //完全依赖os,性能最好，持久化没有保证。

• 修复：如果aof文件被破坏， redis-check-aof–fix进行修复，在flushAppendOnlyFile函数中，若出现断电等情况，就将写出错的情况记录到日志里，之后会处理错误。

• 恢复：重启redis然后重新加载，如果aof和rdb两种持久化工具都开启，AOF优先。因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

（5）AOF的步骤

• 命令追加：将命令追加到AOF缓冲区
• 文件写入
• 文件同步

（6）AOF重写（bgrewriteaof）

• 出现原因
  随着服务器运行时间的流逝，AOF文件的内容会越来越多，为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写。

• AOF重写的实现原理
  fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，

• 重写触发机制
  Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发（默认）

• AOF后台重写

  • AOF重写程序放到子进程中执行，为了解决子进程下数据不一致的问题，Redis服务器设置了一个AOF重写缓冲区，在服务器创建子进程之后使用，
  • 当Redis执行完一个命令后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区，这样就可以保证现有AOF文件的处理工作照常进行，而服务器的所有写命令都会被记录到AOF重写缓冲区里。

（7）AOF图解

3.虚拟内存方式：

虚拟内存方式是Redis来进行用户空间的数据换入换出的一个策略，此种方式在实现的效果上比较差，主要问题是代码复杂，重启慢，复制慢等等，目前已经被作者放弃。

4.diskstore方式：

diskstore方式是作者放弃了虚拟内存方式后选择的一种新的实现方式，也就是传统的B-tree的方式。

本人才疏学浅，若有错，请指出，谢谢！

参考书籍：《Redis设计与实现（第二版）》—黄健宏
参考链接：
1.【Redis源码剖析】 - Redis持久化之RDB
2.《Redis源码学习札记》RDB