Redis持久化机制

第一种是 RDB 快照，第二种是 AOF 日志。

RDB 快照是某一个时间节点的一次全量备份，二进制文件；AOF 日志是追加式的增量备份，内存数据修改的指令记录；

RDB 触发机制：

RDB 持久化触发机制 ：手动触发和自动触发

执行 save 命令：阻塞当前服务器进程，直到 RDB 过程完成，一旦数据量过大可能会造成长时间的进程阻塞，线上环境一般禁止；

使用 bigsave（background save） 命令 ：执行 bgsave 命令时 Redis 主进程会 fork 一个子进程来完成 RDB 持久化过程，完成后自动结束（操作系统的多进程 Copy On Write 机制）。

所以 Redis 主进程阻塞时间只有 fork 这一阶段，相对于 save 阻塞时间很短。

自动触发 ：

场景一：配置 redis.conf 触发规则：

当在规定的时间内，Redis 发生了写操作的个数满足条件，自动触发发生 BGSAVE 命令（当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作）

save 900 1 #900秒之内至少一次写操作
save 300 10 #300秒之内至少发生10次写操作
save 60 10000 #60秒之内发生至少10000次写操作

场景二：执行 shutdown 命令关闭服务器时，如果没有开启 AOF 持久化功能，那么会自动执行一次 bgsave

场景三：主从同步（slave和master建立同步机制）

如何关闭RDB快照持久化方式：

注掉 save 配置；

RDB 的执行流程：

Redis 使用操作系统的多进程 Copy On Write 机制来实现 RDB 快照持久化

1）执行 bgsave 命令，Redis 主进程会检查是否有子进程在执行 RDB/AOF 持久化任务，如果有，直接返回，主线程继续接收 redis 命令并执行；
2）如果没有，Redis 主进程会 fork 一个子进程执行执行 RDB 操作，fork 操作这一过程不会对主进程造成阻塞（Redis 主进程正常接收命令）；
3）RDB 子进程会根据 Redis 主进程的内存生成临时的快照文件，持久化完成后会使用临时快照文件替换掉原来的RDB文件；
（子线程与主线程共享内存，RDB 操作过程中，主线程修改一块数据，该过程中主进程的读写不受影响，子线程与主线程共享内存，Redis 的写操作不会同步到主进程的主内存，而是会写到一个临时的内存区域作为一个副本）
4）子进程完成 RDB 持久化后会发消息给主进程，通知 主进程RDB 持久化完成（将上阶段内存副本中的增量写数据同步到主内存）

优点：

文件小，定时备份

redis加载RDB文件的速度比AOF（RDB文件直接存储内存数据，AOF文件中存储的是一条条命令，需要回放命令）

缺点：

RDB 无法做到实时持久化，若在两次 bgsave 间宕机，则会丢失一部分（分钟级）的增量数据，不适用于实时性要求较高的场景

RDB 的 Copy On Write 机制中，fork子进程属于重量级操作，并且会阻塞 redis 主进程

注*** 存在老版本的 Redis 不兼容新版本 RDB 格式文件的问题

--- 删除 rdb 文件/usr/local/redis/data/6379/dump.rdb

---重启 redis

AOF 日志：

Redis 收到的每一条写入命令，并以文本形式保存；

属于持续增量的备份，是基于写命令存储的可读的文本文件；

目前 AOF 是 Redis 持久化的主流方式；

AOF 触发机制 ：手动触发、自动触发

手动触发：调用 bgrewriteaof 命令

redis-cli -h ip地址 -p 端口号 bgrewriteaof

自动触发：

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

auto-aof-rewrite-min-size : 表示运行 AOF 重写时文件最小体积，默认 64MB（建议 512MB）。

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

自动触发时机 ：(aof_current_size > auto-aof-rewrite-min-size ) && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

AOF日志会在持续运行中持续增大，由于 Redis 重启过程需要优先加载AOF日志进行指令重放以恢复数据，恢复特别耗时，所以需要定期进行AOF重写，对AOF日志进行瘦身。

开启方式：

AOF 默认是关闭的，通过 redis.conf 配置文件进行开启：

## 此选项是 aof 功能的开关，默认 no，配置 yes 开启 aof 功能 ，此时 aof 重写、文件同步等特性才会生效  
appendonly yes
 
## 指定 aof 文件名称  
appendfilename appendonly.aof  

## 指定 aof 操作中文件同步策略，可选参数 ：always everysec no, 默认 everysec
## always：每执行一条写命令，都会触发AOF 持久化机制（每次写入，都会调用fsync函数，缓存数据同步到磁盘文件）
## everysec：每秒调用一次fsync函数，将缓存数据写入AOF文件（一旦遇到物理服务器故障，可能导致最多1秒的 AOF 记录丢失）
## no ：操作系统决定何时同步到磁盘文件（写操作不会调用fsync函数，是由操作系统自动调度将内存数据刷新到磁盘文件）
appendfsync everysec
 
## 在 aof-rewrite 期间，appendfsync 是否暂缓文件同步，no - 不暂缓，yes - 暂缓，默认 no
no-appendfsync-on-rewrite no

## aof 文件 rewrite 触发的最小文件大小(mb,gb),只有大于此 aof 文件，才会触发 rewrite，默认 64mb，建议 512mb  
auto-aof-rewrite-min-size 64mb  

## 相对于上一次 rewrite，本次 rewrite 触发时 aof 文件应该增长的百分比（每一次 rewrite 之后，redis 都会记录下此时“新 aof ”文件的大小）
## aof 文件增长到A*(1 + p)之后，触发下一次 rewrite，每一次 aof 记录的添加，都会检测当前aof文件的尺寸。  
auto-aof-rewrite-percentage 100

注***：

AOF 是文件操作命令文本，对于变更操作比较密集的 server ，将造成磁盘 IO 负荷加重。

linux 对文件操作采取“延迟写入”，并非每次 write 操作都会触发实际磁盘操作，而是先写入buffer（缓存），一旦 buffer 数据达到阀值时，触发实际写入(也有其他时机)

--- linux 对文件系统的一种优化手段。Linux 的 glibc 提供了fsync(int fd)函数可以将指定文件的内容强制从内存刷入到磁盘。

---

fsync 是AOF 文件的一个刷盘命令，将缓存数据写入 appendonly.aof 文件，只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。

但是 作为一个磁盘 IO 操作，慢！如果 Redis 执行一条指令就要 fsync 一次，Redis 性能就无法保证了！！！

AOF 重写机制：

AOF 日志运行中持续增大，需要定期进行 AOF 重写，对日志进行瘦身。

AOF Rewrite 是“压缩”AOF文件的过程，但并非采用“基于原AOF文件”重写或压缩，而是采取了类似 RDB 快照的方式：

基于 Copy On Write 全量遍历内存中数据，然后逐个追加写入 AOF 文件。

AOF 重写（bgrewriteaof）和 RDB 快照写入（bgsave）过程类似，消耗磁盘 IO 。

Redis采取了“schedule”策略：无论是“人工干预”还是“系统触发”，快照和重写需要逐个被执行。

重写过程，Redis 对于新的变更操作命令仍然写入到原AOF文件，同时将这些新的变更操作收集起来。内存中的数据被全部写入到新的AOF文件之后，收集的新的变更操作也将被一并追加到新的AOF文件。然后将新AOF文件重命名为appendonly.aof，使用新AOF文件替换老文件，此后所有的操作都将被写入新的AOF文件。

AOF 优点：

追加写日志文件，对服务器性能影响较小，速度比 RDB 快，消耗的内存较少

一般AOF日志保存的数据比RDB文件一致性更高

AOF 缺点：

AOF 生成的日志文件过大，需要不断重写 AOF文件，进行文件瘦身

数据重构、数据恢复，AOF 重放恢复数据的速度，比 RDB 慢

混合持久化：

rdb 文件的内容和增量的 AOF 日志文件一起保存，AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间数据修改的增量 AOF 日志

---不仅仅将内存数据转换数据修改命令写入 AOF 文件，而是将重写这一刻之前的内存数据以RDB快照处理，并将RDB快照与增量的AOF修改命令保存在一起写入新的临时文件，从写完成之后，命名为 appendonly.aof,替代原来旧的AOF文件，redis 重启时，先加载RDB快照，再重放增量的AOF日志，完成数据恢复

Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志，替代 AOF 全量文件重放，大幅度提高重启效率
---数据量大情况下，粗粒度（时间上）的rdb快照方式，性能高，恢复速度快
---增量数据，细粒度（时间上）的 AOF 日志方式，尽量保证数据的不丢失

开启混合持久化（必须先开启AOF）配置： 

# aof‐use‐rdb‐preamble yes

混合持久化 --- 本质上还是AOF持久化方式，唯一区别只是在AOF文件重写的时候，将内存中之前保存的数据以快照的形式写入到AOF文件中保存

另外：

Master 采用 AOF 日志，Slave 采用 RDB 快照；

master 需要首先确保数据完整性，它作为数据备份的第一选择；

slave 提供只读服务或仅作为备机，它的主要目的就是快速响应客户端 read 请求或容灾切换