Redis 高可用之持久化

news/2024/10/31 7:32:43/

 1.Redis 高可用的相关知识
1.1 什么是高可用
在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务(99.9%、99.99%、99.999%等等)。

但是在Redis语境中,高可用的含义似乎要宽泛一些,除了保证提供正常服务( 如主从分离、快速容灾技术),还需要考虑数据容量的扩展、数据安全不会丢失等。

1.2 Redis的高可用技术
在Redis中,实现高可用的技术主要包括持久化、主从复制、哨兵和cluster集群,下面分别说明它们的作用,以及解决了什么样的问题。

持久化: 持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘,保证数据不会因进程退出而丢失。

主从复制: 主从复制是高可用Redis的基础,哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份(和同步),以及对于读操作的负载均衡和简单的故障恢复。

缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。
哨兵: 在主从复制的基础上,哨兵实现了自动化的故障恢复。(主挂了,找一个从成为新的主,哨兵节点进行监控)

缺陷:写操作无法负载均衡;存储能力受到单机的限制。
Cluster集群: 通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。(6台起步,成双成对,3主3从)

1.3  持久化的功能
持久化的功能: Redis是内存数据库,数据都是存储在内存中,为了避免服务器断电等原因导致Redis进程异常退出后数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置。

灾难备份:一般做异地备份,发生灾难后切换节点。

1.4 redis持久化的方式
RDB持久化:原理是将Reids在内存中的数据库记录定时保存到磁盘上。(定时对内存中的数据生成快照,以文件形式保存在硬盘中)
AOF持久化(append only file):原理是将Reids 的操作日志以追加的方式写入文件,类似于MySQL的binlog。(类似于Mysql的二进制日志)(以追加的方式将写和删的操作命令记录到AOF文件中)
由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持 久化仍然有其用武之地。(RDB体积小,恢复速度更快。对性能影响较小。)

2.RDB持久化 
RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化),用二进制压缩存储,保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。 

2.1 RDB持久化的触发方式 
(1)手动触发 
save命令和bgsave命令都可以生成RDB文件。

save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求。
而bgsave命令会创建一个子进程,由子进程来负责创建RDB文件,父进程(即Redis主进程)则继续处理请求。
bgsave命令执行过程中,只有fork子进程时会阻塞服务器,而对于save命令,整个过程都会阻塞服务器,因此save已基本被废弃,线上环境要杜绝save的使用。
(2)自动触发
在自动触发RDB持久化时,Redis 也会选择bgsave而不是save来进行持久化。

自动触发最常见的情况是在配置文件中通过 save m n 指定当m秒内发生n次变化时,会触发bgsave。

vim /etc/redis/6379.conf      #编辑配置文件
 ​
 ----219行--以下三个save条件满足任意一一个时,都会引起bgsave的调用
 save 900 1      #当时间到900秒时,如果redis数据发生了至少1次变化,则执行bgsave
 save 300 10     #当时间到300秒时,如果redis数据发生了至少10次变化,则执行bgsave
 save 60 10000   #当时间到60秒时,如果redis数据发生了至少10000次变化, 则执行bgsave
 ​
 ----242行--是否开启RDB文件压缩
 rdbcompression yes
 ​
 ----254行--指定RDB文件名
 dbfilename dump.rdb
 ​
 ----264行--指定RDB文件和AOF文件所在目录
 dir /var/lib/redis/6379  
 

(3)其他自动触发机制
除了savemn以外,还有一些其他情况会触发bgsave:

在主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点。
执行shutdown命令时,自动执行rdb持久化。
2.2 bgsave执行流程
(1)Redis父进程首先判断:当前是否在执行save,或 bgsave/ bgrewriteaof 的子进程,如果在执行则bgsave命令直接返回。

bgsave/bgrewriteaof 的子进程不能同时执行,主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题。
(2)父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,Redis不能执行来自客户端的任何命令。

(3)父进程fork后,bgsave 命令返回"Background saving started" 信息并不再阻塞父进程,并可以响应其他命令。

(4)子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换。(原子替换:文件整体替换,要么都发生,要么都不发生)

(5)子进程发送信号给父进程表示完成,父进程更新统计信息。

2.3 启动时加载
RDB文件的载入工作是在服务器启动时自动执行的,并没有专门的命令。但是由于AOF的优先级更高,因此当AOF开启时,Redis会优先载入AOF文件来恢复数据;只有当AOF关闭时,才会在Redis服务器启动时检测RDB文件,并自动载入。 服务器载入RDB文件期间处于阻塞状态,直到载入完成为止。
Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。
 3. AOF持久化
RDB持久化是将进程数据写入文件,而AOF持久化,则是将Redis执行的每次写、删除命令记录到单独的日志文件中,查询操作不会记录。
当Redis重启时再次执行AOF文件中的命令来恢复数据。(重放命令进行恢复)
与RDB相比,AOF的实时性更好,因此已成为主流的持久化方案。


3.1 AOF的开启配置
Redis服务器默认开启RDB,关闭AOF的, 要开启AOF,需要在/etc/redis/6379.conf配置文件中配置。

vim /etc/redis/6379.conf
 ----700行---修改,开启AOF
 appendonly yes
 ----704行---指定AOF文件名称
 appendfilename "appendonly.aof"
 ----796行---是否忽略最后一条可能存在问题的指令
 aof-load-truncated yes   
 #Redis恢复时,发现AOF文件的末尾被截断了,会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时,可能发生redis机器运行崩溃,AOF文件的末尾被截断了,这种情况下,yes会继续执行并恢复尽量多的数据,而no会直接恢复失败报错退出。
 ​
 ​
 /etc/init.d/redis_6379 restart    #重启redis
 ls /var/lib/redis/6379/      #查看是否生成了aof文件
3.2 执行流程 
由于需要记录Redis的每条写命令,因此AOF不需要触发,下面介绍AOF的执行流程。

AOF的执行流程包括:

命令追加(append) :将Redis的写 命令追加到缓冲区aof_ buf;
文件写入(write)和文件同步(sync) :根据不同的同步策略将aof_buf中的内容同步到硬盘;
文件重写(rewrite) :定期重写AOF文件,达到压缩的目的。(将过期数据、无效命令、多条命令,进行压缩或删除)
(1)命令追加 
 Redis先将写命令追加到缓冲区,而不是直接写入文件,主要是为了避免每次有写命令都直接写入硬盘,导致硬盘IO成为Redis负载的瓶颈。
命令追加的格式是Redis命令请求的协议格式,它是一种纯文本格式,具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。
在AOF文件中,除了用于指定数据库的select命令(如select 0为选中0号数据库)是由Redis添加的, 其他都是客户端发送来的写命令。
(2) 文件写入(write)和文件同步(sync)
Redis提供了多种AOF缓存区的同步文件策略,策略涉及到操作系统的write函数和fsync函数,说明如下:

为了提高文件写入效率,在现代操作系统中,当用户调用write函数将数据写入文件时,操作系统通常会将数据暂存到一个内存缓冲区里,当缓冲区被填满或超过了指定时限后,才真正将缓冲区的数据写入到硬盘里。
这样的操作虽然提高了效率,但也带来了安全问题:如果计算机停机,内存缓冲区中的数据会丢失。因此系统同时提供了fsync、fdatasync等同步函数,可以强制操作系统立刻将缓冲区中的数据写入到硬盘里,从而确保数据的安全性。
AOF缓存区的同步文件策略存在三种同步方式,它们分别是:

appendfsync always:命令写入aof_buf后立即调用系统fsync操作同步到AOF文件。安全性高,性能低。
appendfsync no:当缓冲区被填满或超过了指定时限后(默认30秒),才将缓冲区的数据写入到硬盘里。性能高,但安全性低。
appendfsync everysec:每秒同步一次,是性能和数据安全性的平衡,因此是Redis的默认配置。


http://www.ppmy.cn/news/83054.html

相关文章

使用GPT-4.0编写量化交易策略:方法、案例与参数优化

量化策略开发,高质量社群,交易思路分享等相关内容 『正文』 ˇ 随着人工智能的发展,GPT-4.0已经成为量化交易策略编写的强大工具。在这篇文章中,我们将探讨如何使用GPT-4.0编写量化交易策略,并提供一个实际的案例。我…

JetsonNano学习(七)Nginx 搭建 HLS 直播服务器

文章目录 一、使用 Nginx-rtmp-module 编译 Nginx下载 Nginx-rtmp-module安装 Nginx 依赖下载 Nginx编译 Nginx 二、Nginx 配置文件三、启动 Nginx 服务方式一安装nginx初始化脚本、获取nginx初始化脚本 方式二直接调用 四、使用 RTMP 将视频推送到 Nginx安装FFmpeg捕获网络摄像…

【算法】手摇算法反转部分字符串

文章目录 什么是手摇算法? 什么是手摇算法? 有一个场景,就是反转字符串中的字符。这个很简单,我们可以很快的写出如下代码: /*** 反转倒置* 在由char[]转为Sting注意不要使用toSting方法*/public static void revers…

《Kali渗透基础》02. 基本工具

kali渗透 1:基本工具1.1:NetCat1.1.1:命令参数1.1.2:示例 1.2:NCat1.2.1:命令参数1.2.2:示例 1.3:WireShark1.4:TCPdump1.4.1:命令参数1.4.2:示例…

路由器端口映射-原理+图解

文章目录 1. 前言2. 内部服务器3. 内网IP3.1 含义3.2 查询内网IP方法3.3 直观法判断内网IP 4. 内部端口5. 外部端口6. 远程桌面连接7. 端口映射原理图8. 欢迎纠正~ 1. 前言 端口映射就是可将N台主机的内网IP地址映射成一个公网IP地址,从而让外网可以访问到局域网内…

纽约时报对全球HR选出他们最想招聘的毕业生所来自的前150所大学

美国《纽约时报》对全球2500个HR部门和2000位企业的CEO发出了问卷,排名选出他们最想招聘的毕业生所来自的大学 1哈佛大学。 美国 2耶鲁大学。 美国 3 剑桥大学 英国 4 牛津大学 英国 5 斯坦福大学。 美国 6 马萨诸塞州理工学院 美国 7 哥伦比亚大学。 美国 8 普林斯…

智能文档处理黑科技,拥抱更高效的数字世界

目录 0 写在前面1 为何要关注智慧文档?2 图像弯曲矫正3 手写板反光擦除4 版面元素检测5 文档篡改检测总结 0 写在前面 近期,中国图象图形学学会文档图像分析与识别专业委员会与上海合合信息科技有限公司联合打造了《文档图像智能分析与处理》高峰论坛。…

VTKmimics Calculate Parts

前言:本博文主要研究mimics中Calculate Parts所采用的方法以及VTK中三维重建的方法,希望对各位小伙伴有所帮助,谢谢! mimics-Calculate parts - Interpolation Gray Interpolation 灰度值插值是一种真正的3D插值,它考…