redis持久化

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。理解掌握持久化机制对于Redis运维非常重要

持久化之RDB

是什么

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

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

• rdb 保存的是dump.rdb文件
• 相关配置在配置文件的位置 - 在redis.conf搜寻### SNAPSHOTTING ###

1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进 程，如RDB/AOF子进程，如果存在bgsave命令直接返回。

2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通 过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒

3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。

4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后 对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间，对应info统计的rdb_last_save_time选项。

5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence下的rdb_*相关选项。

RDB文件的处理

保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配 置指定。可以通过执行config set dir{newDir}和config set dbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。

如何触发RDB快照

• 配置文件中默认的快照配置dbfilename dump.rdb，dump.rdb则是生成的快照名，启动redis服务时会根据配置文件中定义的快照名找寻快照文件，从而恢复数据
• 命令save或者是bgsave
  • SAVE：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
  • BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
• 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

自动触发RDB的持久化

1）在redis.conf配置文件快照模块中，有save m n。表示m秒内数据集存在n次修改 时，自动触发bgsave。

2）执行debug reload命令重新加载Redis时，也会自动触发save操作。

3）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。

bgsave是主流的触发RDB持久化方式

如何通过快照文件恢复数据

• 将备份文件 (dump.rdb) 移动到 redis 安装目录重新启动服务即可
• CONFIG GET dir获取目录

RDB优缺点

RDB的优点：

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据 快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
• Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点：

• RDB方式数据没办法做到实时持久化（秒级持久化）。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
• RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。
• 在一定间隔时间做一次备份，所以如果redis意外挂掉，就会丢失最后一次快照后的所有修改

针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

小节

• RDB是一个非常紧凑的文件。
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一一些。
  数据丢失风险大。
• RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候fork的过程是非常耗时的吗，可能会导致Redis在一些毫秒级不能回应客户端请求。

持久化之AOF

是什么

AOF（append only file）持久化：以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。目前已经是Redis持久化的主流方式。

配置

位置：在redis.conf文件中的APPEND ONLY MODE模块

• 启动：appendonly yes，默认不开启
• AOF文件名：通过appendfilename配置设置，默认文件名是appendonly.aof
• 保存路径同：RDB持久化方式一致，通过dir配置指定，获取配置路径命令：config get dir
• 备份被写坏的AOF文件，运行redis-check-aof aof文件
• 持久化配置appendfsync ：
  • always ：每次有数据修改发生时都会写入AOF文件，性能差。
  • everysec： 每秒钟同步一次，该策略为AOF的缺省策略。
  • no： 从不同步。高效但是数据不会被持久化。

AOF的工作流程

AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）

1）所有的写入命令会追加到aof_buf（缓冲区）中。

2）AOF缓冲区根据对应的策略向硬盘做同步操作。

AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如 果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负 载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

重写后的AOF文件为什么可以变小？有如下原因：

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

4) AOF重写过程可以手动触发和自动触发

• 手动触发：直接调用bgrewriteaof命令。

• 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

  • auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。

  • auto-aof-rewrite-percentage：代表当前AOF文件空间 (aof_current_size)和上一次重写后AOF文件空间（aof_base_size）的比值。

流程说明：

1）AOF持久化开启且存在AOF文件时，优先加载AOF文件

2）AOF关闭或者AOF文件不存在时，加载RDB文件

3）加载AOF/RDB文件成功后，Redis启动成功。

4）AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

参考文档

redis持久化

原文：https://www.cnblogs.com/silloutte/p/14628686.html