redis-持久化(1)

目录

  • 一、RDB

    • 1.1 触发机制

    • 1.2 流程说明

    • 1.3 RDB优缺点

  • 二、AOF

    • 2.1 开启AOF

    • 2.2 AOF流程

  • 三、重启加载流程

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

  1. RDB

    RDB(Redis DataBase),基于策略定时将redis内存中的数据保存到硬盘。需要时可以通过这个备份文件进行恢复。

  2. AOF

    AOF(Append Only File),是把每次redis执行的命令记录到日志文件中(类似于MySql的Bin log),当Redis启动时可以通过执行log中的命令来恢复数据

一、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。

二、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重写。

三、重启加载流程

  1. 优先加载AOF

  2. AOF关闭时加载RDB

  3. 加载成功后redis才能成功启动

  4. 加载失败,则redis启动失败

来源:https://www.icode9.com/content-2-788501.html

(0)

相关推荐