redis-持久化

目录

• 1、RDB
  • 1.1 触发机制
  • 1.2 流程说明
  • 1.3 RDB优缺点
• 2、AOF
  • 2.1 开启AOF
  • 2.2 AOF流程
• 3、重启加载流程

持久化即备份，这是单机高可用的策略之一，有了备份，就能够在Redis故障经过备份进行恢复。redis持久化主要有RDB和AOF。

1. RDB

   RDB（Redis DataBase），基于策略定时将redis内存中的数据保存到硬盘。须要时能够经过这个备份文件进行恢复。

2. AOF

   AOF（Append Only File），是把每次redis执行的命令记录到日志文件中（相似于MySql的Bin log），当Redis启动时能够经过执行log中的命令来恢复数据

1、RDB

1.1 触发机制

save命令：阻塞当前redis服务器，直到RDB过程完成，服务器在阻塞期间不能处理如何客户端请求，原则上save命令已经废弃。

bgsave命令：会fork一个子进程，RDB的持久化由这个子进程来完成，阻塞只发生在fork阶段，耗时较短，子进程执行rdb期间redis服务器不会阻塞，正常处理客户端请求。

自动触发机制：在redis.conf 配置：

save m n

表明若是在m秒内存在n次的修改时，则执行bgsave命令

1.2 流程说明

1. 执行bgsave命令，redis父进程判断若是当前存在正在执行的子进程，则直接返回，好比AOF或者RDB子进程。
2. 父进程fork一个子进程，fork过程父进程是阻塞，没法响应客户端请求
3. fork结束后，bgsave返回“background saving started”信息，而且再也不阻塞父进程，父进程能够继续响应客户端请求。
4. 子进程根据父进程的内存快照建立RDB文件，完成后对原有文件进行原子替换。
5. 子进程发送信号给父进程表示RDB完成

1.3 RDB优缺点

优势

1. RDB是一个压缩的二进制文件，表明Redis在某个时间点上的数据快照，适合备份，全量复制等场景
2. Redis加载RDB恢复数据远远快于AOF

缺点

1. RDB没法作到实时持久化
2. 兼容性问题，新版本的redis可能没法兼容老版本的RDB

为了解决实时持久化问题，redis引入了AOF。

2、AOF

2.1 开启AOF

AOF默认是关闭的，经过以下命令开启：

appendonly yes

2.2 AOF流程

AOF工做基本流程：

1. 命令写入（append）：redis全部的写入命令会追加到aof_buf（缓冲区）中
2. 文件同步（sync）：AOF缓冲区根据对应的策略向硬盘作同步操做
3. 文件重写（rewrite）：随着AOF文件愈来愈大，须要按期对AOF文件进行重写，达到压缩的目的
4. 重启加载（load）：redis启动后能够加载AOF文件进行数据恢复。

命令写入

对于每一条redis写入命令，在AOF中会追加一条文本，文本格式是redis文本协议格式（RESP），直接采用协议格式，以来兼容性和可读性高，二来避免了二次处理的开销。

若是直接把命令写入硬盘会影响到redis的性能。先写入aof_buf，而后后期经过同步策略写入硬盘，避免直接的IO影响到redis的性能。

文件同步

redis提供了多种AOF缓冲区文件同步策略，同步策略分别使用了操做系统的wirte函数和fsync函数，说明以下：

write: 会触发延迟写（delayed write）操做，为了性能，linux在内核提供了页缓冲区用来提升硬盘的IO性能，write操做在写入系统缓冲区后直接返回，后期同步硬盘操做依赖于操做系统调度（好比按时，或者缓冲区慢等）。若是在同步前出现系统宕机故障，缓冲区的数据会丢失。

fsync: 强制操做系统将缓冲区的操做同步到硬盘。

由appendfsync参数控制：

可配置的值	说明
always	命令写入buf后调用系统调用fsync同步AOF文件，fsync完成后线程返回
no	命令写入buf后调用系统调用write操做，后续fsync同步操做由操做系统来完成，通常为30秒一次。
everysec	命令写入buf后调用系统调用write操做，后续fsync同步操做专门线程每一秒调用一次。

everysec是always和no的折中，是性能和安全性的这种，是redis默认的配置，也是比较推荐的配置。

文件重写

文件重写就是把Redis进程里面的最新数据转化为写命令而后同步到aof文件的过程，经过重写不但能够减少aof文件的体积，从而进一步提升aof文件在恢复过程当中的加载速度。

由如下缘由能够经过aof重写减小aof文件的体积：

1. 旧的apf包含过时的数据再也不写入aof，好比 set k1 aaa，这条命令已通过期，可是已经在aof文件中存在，经过重写这条命令将移除aof文件。
2. 旧的aof中存在无效的命令，好比set k1 111,set k1 222，aof中存在两条命令，其实第一条已经失效，经过重写，能够变成一条。
3. 多条命令命令合并。

触发机制：

1. 手动触发：执行bgrewriteaof命令

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

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

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

     只有当以上两个条件同时知足时，才会触发自动aof

aof重写流程：

1. 执行aof重写请求
2. 父进程fork一个子进程，开销等同于bgsave时候fork的过程
3. aof缓冲区写入
   1. fork结束后，主进程继续响应客户端请求，全部修改命令都会写入aof_buf，后续基于appendfsync策略写入硬盘
   2. 因为fork操做运用写时复制技术，子进程只能共享fork操做时的的内存数据。在执行bgrewrite期间，主进程依然在响应命令，redis用aof_rewrite_buf来保存这部分数据，防止在新的aof文件生成期间丢失这部分数据。
4. 写入新的AOF，子进程基于fork后的aof_buf（快照）生成新的aof文件
5. 后续操做
   1. 子进程发送信号通知父进程aof生成完成，父进程更新相关统计信息
   2. 父进程把aof_rewrite_buf的数据写入到新的aof文件
   3. 使用最新的aof文件替换老文件，完成最终的AOF重写。

3、重启加载流程

1. 优先加载AOF
2. AOF关闭时加载RDB
3. 加载成功后redis才能成功启动
4. 加载失败，则redis启动失败