持久化

是什么

相对于内存而言，内存的数据，不是持久数据，关机之后，数据就没了；

存在磁盘中的数据，是持久数据，关机重启之后，还可以恢复。

这是 Redis 区别于 Memcache的特征之一

image.png

两种方式

RDB（Redis DataBase）

是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

如何备份

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件（全量保存）。 整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感(因为最后一次持久化后的数据可能丢失)，那RDB方式要比AOF方式更加的高效(因为不需要生成数据，只需要读取就行)。

备份流程

image.png

触发备份的策略

save 和 bgsave

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

bgsave(background save)：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

可以通过lastsave 命令获取最后一次成功执行快照的时间

命令格式：save 秒钟 写操作次数

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次，则会触发

image.png

备份压缩

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

image.png

备份文件完整性检查

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，

但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

推荐yes.

image.png

如何恢复

Redis启动后，会从配置文件中，查找rdb文件的路径，再读取其中数据到内存中。

AOF（Append Only File）

是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

备份流程

• 客户端的请求写命令会被append追加到AOF缓冲区内
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
• AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
• Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

image.png

触发备份的策略

• append fsync always

    始终同步，**每次`Redis`的写入都会立刻记入日志**；性能较差但数据完整性比较好
  

• append fsync everysec

    每秒同步，每秒记入日志一次，**如果宕机，本秒的数据可能丢失**。
  

• append fsync no

    `redis`不主动进行同步，把同步时机交给操作系统
  

备份压缩 -- rewrite 重写

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集，可以使用后台压缩命令bgrewriteaof

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)

• 重写流程
  • bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
  • 主进程fork出子进程执行重写操作，保证主进程不会阻塞
  • 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区，保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
  • 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。主进程把aof_rewrite_buf中的数据（重写过程中，新的写请求）写入到新的AOF文件
  • 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写
  • image.png

AOF文件修复

如果AOF文件损坏(记录了不规范的操作)，可以用命令修复：

/usr/local/bin/redis-check-aof--fix appendonly.aof

两种方式的比较

RDB

优势

• 恢复速度快，适合大规模的数据恢复（不需要重新构建数据）
• 占用空间少（RDB 只要存键值对，AOF还要存关键字get，set等）
• 对数据完整性和一致性要求不高更适合使用

劣势

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改
• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能（fork的子进程消耗过大，也会影响到主进程）

AOF

优势

• 备份机制更稳健，丢失数据概率更低
• 读的日志文本，通过操作AOF稳健，可以处理误操作

劣势

• 恢复备份速度要慢
• 比起RDB占用更多的磁盘空间（RDB 只要存键值对，AOF还要存关键字get，set等）
• 存在bug，可能造成不能恢复

两种方式的选择

• AOF默认关闭
• 两者都启用的情况下，系统默认取AOF的数据（AOF存的数据更完整，丢失概率更低）

官方建议

• 如果只是做纯内存缓存(不需要持久化)，可以都不用。

• 如果对数据不敏感，可以选单独用RDB，不建议单独用 AOF，因为可能会出现Bug。

  • 即推荐RDB必选，AOF可选

• 推荐两个都启用，RDB作为备用

  • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

参考：

尚硅谷视频