Redis持久化

有两种持久化方式：

RDB （Redis DB；默认开启；类比于 HDFS 的 fsimage）
AOF （Append Only File；类比于 HDFS 的 edits log）

1. RDB

在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。

1.1 持久化策略

自动执行：
按照配置文件中的条件满足就执行 BGSAVE
- 默认配置
  save 900 1
  save 300 10
  save 60 10000
  
  只要上面三个条件满足一个，就自动执行备份。
  创建RDB文件之后，时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的
- 持久化文件默认目录
  dir /var/lib/redis/6379

手动执行：
客户端发起 SAVE、BGSAVE 命令。

1.2 具体方式

save（阻塞）
bgsave（非阻塞）

（1）SAVE

阻塞 Redis 服务，无法响应客户端请求，创建新的 dump.rdb 替代旧文件；生产环境很少这样做，一般都是停机维护时期才考虑

image

（2）BGSAVE

非阻塞，Redis 服务正常接收处理客户端请求，Redis 会 fork()一个新的子进程来创建 RDB 文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕，父进程用新的 dump.rdb 替代旧文件。BGSAVE 是一个异步命令。

image

1.3 RDB的工作流程：

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

（2）父进程执行fork操作创建子进程（拷贝父进程所有数据的引用），fork操作过程中父进程被阻塞。

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

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

（5）子进程完成持久化操作后，通知父进程完成，父进程更新统计信息。

对于大多数操作系统来说，fork都是个重量级操作，虽然创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。子进程通过fork操作产生，占用内存大小等同于父进程，理论上需要两倍的内存来完成持久化操作。

但Linux有写时复制机制（copy-on-write），子进程拷贝父进程所有数据的引用而不是复制数据本身，如果在 bgsave 过程中客户端修改了父进程的内存，比如发生了写操作，那么父进程将开辟一个新的空间来存储修改的这个数据。

1.4 配置

[root@node01 redis]# vi /etc/redis/6379.conf 
#默认情况下 redis 不是作为守护进程运行的，设置为 yes 让它在后台运行 
daemonize yes 
#端口号 
port 6379 
#日志级别 
loglevel notice 
#日志位置 
logfile /var/log/redis_6379.log 
#一个 redis 实例最多可以包含多少个数据库 
databases 16 
# Save the DB on disk: 
save 900 1 
save 300 10 
save 60 10000 
# The filename where to dump the DB 
dbfilename dump.rdb 
# The DB will be written inside this directory, with the filename specified 
# above using the 'dbfilename' configuration directive. 
dir /var/lib/redis/6379 
#如果启动多个 redis，最好指定每个占用的内存 
# maxmemory

1.5 RDB持久化优缺点

优点：

完全备份，不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件，方便网络传输，适合灾难恢复
恢复大数据集速度较AOF快

缺点：

会丢失最近写入、修改的而未能持久化的数据
fork过程比较耗时，会造成毫秒级不能响应客户端请求

1.6 生产环境操作

由于RDB模式备份不会保留旧版本，每次都会覆盖，所以，在实际运用中需要将备份文件定时拷贝至其他目录，大致操作如下：

（1）创建一个定时任务cron job，每小时或者每天将 dump.rdb 复制到指定目录确保备份文件名称带有日期信息，便于管理和还原对应的时间点的快照版本。

（2）定时任务删除过期的备份

（3）如果有必要，跨物理主机、跨机架、异地备份

2. AOF

Append only file，采用追加的方式保存，默认文件 appendonly.aof，记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库。调整 AOF 持久化策略，可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于 RDB 损失小得多。

客户端请求写入输入

客户端再次请求修改数据

客户端继续请求写入数据

2.1 AOF 写入机制

AOF 方式不能保证绝对不丢失数据，目前常见的操作系统中，执行系统调用 write 函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行 fsync 调用和 fdatasync 调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失。

2.2 写入磁盘的策略*

appendfsync 选项： append file synchronize 这个选项的值可以是 always、everysec 或者 no 。

always： 服务器每写入一个命令，就调用一次 fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据。
everysec（默认）： 服务器每一秒重调用一次 fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据（缓冲区的量）。
no： 服务器不主动调用 fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的。

运行速度： always 的速度慢，everysec 和 no 都很快。

2.3 AOF 重写机制

AOF 文件过大
合并重复的操作，AOF 会使用尽可能少的命令来记录

AOF文件重写前后

2.3.1 AOF重写触发

一旦使用AOF，RDB持久化方式即使开启也将不采纳，恢复的时候也是使用AOF文件恢复。

手动： 客户端向服务器发送 BGREWRITEAOF 命令
自动： 配置文件中的选项，以自动执行 BGREWRITEAOF 命令
- auto-aof-rewrite-min-size ：
  触发 AOF 重写所需的最小体积（默认64MB），只要在 AOF 文件的体积大于等于 size 时，才会考虑是否需要进行 AOF 重写，这个选项用于避免对体积过小的 AOF 文件进行重写，但随着精简后文件的增长，很可能会超过64MB，此时会陷入无限精简中，所以还行配置下面的参数。
- auto-aof-rewrite-percentage ：
  指定触发重写所需的 AOF 文件体积百分比（避免重写陷入死循环），当 AOF 文件的体积大于 auto-aof-rewrite-min-size 指定的体积，并且超过上一次重写之后的 AOF 文件体积的 percent %时，就会触发 AOF 重写。（如果服务器刚刚启动不久，还没有进行过 AOF 重写，那么使用服务器启动时载入的 AOF 文件的体积来作为基准值）。将这个值设置为 0 表示关闭自动 AOF 重写。
```
  比如： 
  auto-aof-rewrite-percentage 100 
  auto-aof-rewrite-min-size 64mb 
  # 当 AOF 文件大于 64MB 时候，可以考虑重写 AOF 文件
  # 只有当 AOF 文件的增量大于起始 size 的 100%时（就是文件大小翻了一倍），启动重
  
  appendonly yes # 默认关闭，请开启
```

2.3.2 重写过程

AOF重写过程

1 执行 AOF 重写请求
2 父进程执行 fork 创建子进程，开销等同于 bgsave 过程
3.1 主进程 fork 操作完成后，继续响应其他命令。所有修改命令依然写入 AOF 缓冲区，并根据appendfsync 策略同步到磁盘，保证原有 AOF 机制正确性。
3.2 由于 fork 操作运用写时复制技术，子进程只能共享 fork 操作时的内存数据。由于父进程依然响应命令，redis 使用“ AOF 重写缓冲区”保存这部分新数据，防止新 AOF 文件生成期间丢失这部分数据。
4 子进程根据内存快照，按照命令合并规则写入到新 AOF 文件。每次批量写入硬盘数据量由 aof-rewrite-incremental-fsync 控制，默认是32MB，防止单词刷盘数据过多造成硬盘阻塞。
5.1 新 AOF 文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
5.2 父进程把 AOF 重写缓冲区数据写入到新的 AOF 文件。
5.3 使用新AOF文件替换老文件，完成AOF重写。

注：如果写入操作的时候出现故障导致命令写了“半截”，可以使用 redis-check-aof 工具修复

2.3.3 AOF 优缺点

优点
- 写入机制，默认 fysnc 每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
- 重写机制，优化 AOF 文件
- 如果误操作了（FLUSHALL 等），只要 AOF 未被重写，停止服务移除 AOF 文件尾部 FLUSHALL 命令，重启 Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
缺点
- 相同数据集，AOF 文件体积较 RDB 大了很多
- 恢复数据库速度比 RDB 慢（文本，命令重演）

Redis 持久化（RDB和AOF模式）