当前位置： 首页 > news >正文

redis的高可用

news 来源：原创 2024/5/20 10:41:23

在集群当中有一个非常重要的指标，提供正常服务的时间的百分比(365天)99.9%

redis的高可用含义更加宽泛，正常服务是指标之一、数据容量的扩展、数据的安全性。

在redis当中实现高可用技术：持久化、主从复制、哨兵模式、cluster集群

持久化是什么？

持久化是最简单的高可用方法，主要作用是数据实现备份，也就是把redis缓存在内存中的数据保存到硬盘中。(是典型的冷备份方式)

redis持久化的两种方式

1、 RDB持久化：redis在内存中的数据定时保存到磁盘。（自动执行，手动也可以）

2、 AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于MySQL的binlog

RDB持久化

RDB持久化：在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），二进制压缩存储。保存的文件名后缀是.rdb。redis启动可以直接读取快照文件实现数据恢复。

RDB的触发机制

手动机制：save bgsave都可以生产RDB文件

save创建RDB文件时，整个redis进程会被阻塞，期间redis将无法进行读写操作，直到RDB文件创建完成。

save缓存流程图：

cd /var/lib/redis/6379
#rdb文件保存位置
cp dump.rdb
#备份文件
进入redis后save保存
关闭redis服务后
进行冷备份
删除原来的dump.rdb
再备份回来即可

生产中不能使用save会导致进程阻塞

bgsave主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程会解除阻塞。由子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息。

bgsave缓存流程图：

 自动触发机制：

vim /etc/redis/6379.conf
219行
save 900 1
#900秒  当时间到900秒时，redis的数据至少发生了一次变化，就执行BGSAVE
save 300 10
#300秒  当时间到300秒时，redis的数据至少发生了10次变化，就执行BGSAVE
save 60 10000
#60秒  当时间到60秒时，redis的数据至少发生了10000次变化，就执行BGSAVE一般来说生产中配置sava
sava 120 1000 bgsave
如果数据量比较大时间可以适当放短一点
sava 60 10000 bgsava
数据变动越多，执行的时间要越短，数据如果变动不大时间间隔要长一点242行
rebcompression yes
#开启rdb文件的压缩功能，在高并发场景建议关闭。264行
dir /var/lib/redis/6379
#配置文件目录

除了配置文件中的save m n 之外

主从复制，从节点执行全量复制操作，主节点会执行bgsave，把rbd文件传送给从节点。

关闭主进程，shoutdown之后，会自动执行rdb的持久化。

如果启动时加载发现rdb文件被损坏，日志中会打印错误，redis会拒绝启动。

redis-check-rdb：修复RDB的持久化文件

AOF持久化

AOF持久化是将redis的每一次读、写、删除命令记录到一个单独的.aof结尾的文件。AOF不会记录查询操作，查询操作由主进程记录。当redis重启时，再次执行AOF文件中的命令来恢复数据。

AOF的是实现更好也是主流的持久化方案

AOF持久化是需要手动打开的

vim /etc/redis/6379.conf700行
appendonly yes
#开启AOF持久化的功能704行
appendfilename "appendonly.aof"
#AOF持久化文件，名称可以自定义，文件后缀不能修改aof-load-truncated yes
#用于判断AOF文件，如果被截断时的行为
#截断：写入过程中出现异常，导致文件未能完全写入
#yes：发现被截断，redis会在启动时尽可能恢复文件中的数据。redis会继续运行
#no：发现AOF文件被截断，redis将拒绝启动如果对数据的完整性高，建议使用no
如果追求数据服务器的可用性，可以使用yes
可用性在并发场景上很重要，推荐使用yes

AOF如何实现备份恢复

vim /etc/redis/6379.conf
cd /var/lib/redis/6379
#检查文件是否生成实现数据恢复
进入redis
set test1 1
set test2 2
set test3 3
vim /var/lib/redis/6379/appendonly.aof
#配置文件会记录所有redis的操作
flushall
/etc/init.d/redis_6379 stop
#停止redis服务
vim /var/lib/redis/6379/appendonly.aof
#根据为位置点删除flushall这个操作
/etc/init.d/redis_6379 restart
#重启服务
进入redis查看文件恢复
实验已经完成！

RDB是redis的默认持久化文件，但是如果开启了AOF持久化，那么redis会以AOF持久化文件作为最高优先级

AOF的重写功能

1、 随着时间增长AOF文件中的数据也会不断怎加。AOF的文件也会越来越大，过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长。

文件重写是指定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写的命令，同步到新的AOF文件中(不会额外生成一个新的文件，只是在原有内容中进行压缩)，不会对原有的文件进行任何读、写的操作。

文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写，并不影响redis启动时读取数据。在实际中，会关闭自动的文件重写。通过定时任务来完成。

AOF同步文件的策略

有三种方式

vim /etc/redis/6379.conf729行
appendfsync always
#写入过程中立刻调用redis系统的fsync。写入到AOF文件。如果每次写入都执行同步，硬盘的性能有瓶颈，硬盘的寿命也会大大降低。appendfsync everysec
#也是命令写入，调用write操作。write操作结束后，线程会返回，fsync同步文件操作由专门的线程，每秒同步一次。属于折中策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置appendfsync no
#写入操作调用系统的write操作，但是不做同步，不对AOF文件进行同步。操作系统来同步。同步周期是30秒。文件同步的时间不可控，缓冲区会推积大量数据，数据的安全也无法保证。
AOF重写的触发条件

1、 手动触发

客户端命令行可以直接执行手动触发的命令
redis-cli bgrewriteaof
#手动执行AOF重写的命令执行完成后可以看日志文件查看
tail -f进入redis创建几个键值对
flushall
#清空所有服务
/etc/init.d/redis_6379 stop
#停止redis服务
vim /var/lib/redis/6379/appendonly.aof
#根据为位置点删除flushall这个操作
/etc/init.d/redis_6379 restart
#重启服务
进入redis查看文件恢复
实验已经完成！

AOF重写数据流程图：

2、 自动触发

vim /etc/redis/6379.conf​
771行
auto-aof-rewrite-percentage 100
#文件的大小超过基准的百分比。默认值就是100。文件的大小超过2倍时，会执行bgrewriteaof。
如果设置为0就是禁用自动触发。auto-aof-rewrite-min-size 64mb
#文件大于基准值，才会进行重写。这个是AOF文件执行重写的最小值，避免开始启动redis后，文件太小，然后频繁的进行重写。​
必须要有auto-aof-rewrite-min-size 64mb。
否则会频繁重写。如果配置定时任务需要先注释掉auto-aof-rewrite-percentage 100否则会自动生效。

AOF重写为什么可以压缩文件？

1、 在重写的过程中，如果有过期的数据不会写入文件

2、 重写的过程中无效的命令不再写入文件，数据被重复设置，例如：set test=1 set test=2。删除的数据也不会写入，例如：set test 1 del test

3、 多条命令合并成一个。例如：sadd test1 v1 sadd test1 v2 sadd test1 v3 合并为 sadd test1 v1 v2 v3

重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了。(重写不是必须的)

RDB和AOF之间的优缺点

RDB的优点：文件体积小，如果需要备份网络传输速度很快，适合全量复制。恢复速度也比AOF要快。

RDB的缺点：做不到实时持久化。数据如此重要，不能够容忍丢失的。

RDB需要满足特定的格式，兼容性很差。比如老版本的RDB不支持新版本。

生产中部署redis一定要保证版本一致，生产中一般5.0.7版本

5.0.7版本是目前最稳定的版本

所以AOF成为了主流

AOF的优点：秒级持久化策略。兼容性好。文本格式保存的命令

AOF的缺点：文件大，恢复速度慢。AOF持久化需要频繁的向磁盘写入数据，磁盘的IO压力很大。对redis主进程的性能也会有一定的影响。

总结

redis的持久化也算是高可用的一种，通过备份文件来恢复数据。是冷备份的方式

持久化的两种方式：rdb aof

rbd：save会阻塞主进程，必须等待rbd文件生成后才能恢复。所以线上禁用save。

bgsave不会阻塞主进程，会生成一个子进程

AOF是一种实时持久化，是主流。写入的操作命令，除了查 set del会记录 get select不计入。实时记录。恢复方式类似于MySQL的bin-log

AOF重写机制：推荐但是不是必须的。重写也是主进程，创建一个子进程，由子进程创建.aof文件。如果有新的同步操作会写入aof文件，不是创建新的aof文件而是压缩aof文件后写入。

拓展题

1、 bgsave持久化缓存方式：

bgsave主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程会解除阻塞。由子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息。

2、 AOF持久化

AOF持久化是将redis的每一次读、写、删除命令记录到一个单独的.aof结尾的文件。AOF不会记录查询操作，查询操作由主进程记录。当redis重启时，再次执行AOF文件中的命令来恢复数据。

AOF的是实现更好也是主流的持久化方案

AOF持久化是需要手动打开的

vim /etc/redis/6379.conf700行
appendonly yes
#开启AOF持久化的功能704行
appendfilename "appendonly.aof"
#AOF持久化文件，名称可以自定义，文件后缀不能修改aof-load-truncated yes
#用于判断AOF文件，如果被截断时的行为
#截断：写入过程中出现异常，导致文件未能完全写入
#yes：发现被截断，redis会在启动时尽可能恢复文件中的数据。redis会继续运行
#no：发现AOF文件被截断，redis将拒绝启动如果对数据的完整性高，建议使用no
如果追求数据服务器的可用性，可以使用yes
可用性在并发场景上很重要，推荐使用yes

RDB是redis的默认持久化文件，但是如果开启了AOF持久化，那么redis会以AOF持久化文件作为最高优先级

3、 AOF的重写功能

随着时间增长AOF文件中的数据也会不断怎加。AOF的文件也会越来越大，过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长。

文件重写是指定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写的命令，同步到新的AOF文件中(不会额外生成一个新的文件，只是在原有内容中进行压缩)，不会对原有的文件进行任何读、写的操作。

文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写，并不影响redis启动时读取数据。在实际中，会关闭自动的文件重写。通过定时任务来完成。

4、 如果出现了截断的情况下你是如何操作的？

aof-load-truncated yes
#用于判断AOF文件，如果被截断时的行为
#截断：写入过程中出现异常，导致文件未能完全写入
#yes：发现被截断，redis会在启动时尽可能恢复文件中的数据。redis会继续运行
#no：发现AOF文件被截断，redis将拒绝启动如果对数据的完整性高，建议使用no
如果追求数据服务器的可用性，可以使用yes
可用性在并发场景上很重要，推荐使用yes

5、 重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也怎加了。但是重写不是必须的，无非是速度快慢的问题

相关文章：

  • 浅谈电力设备智能无线温度检测系统
  • 中职网安-Linux操作系统渗透测-Server2130（环境加qq）
  • 计网（复习自用）
  • 【教学类-06-09】20231125 （55格版）X-Y之间“加法减法+-题” （以10-20之间为例）（加法的正序+逆序，减法的正序，题目多）
  • Oracle SQL 注入上的 Django GIS 函数和聚合漏洞 （CVE-2020-9402）
  • 【深度学习】学习率及多种选择策略
  • facebook如何群发小组贴
  • php站点伪静态配置（Apache+Linux）
  • expect脚本在自动化部署中的具体应用案例
  • 数据结构与算法（三）贪心算法（Java）
  • 激活函数与其导数：神经网络中的关键元素
  • 三菱PLC编码器转速测量功能块(梯形图和ST代码)
  • 网络安全深入学习第九课——本机信息收集
  • Mysql（基本介绍+下载安装+服务器+基本使用+建库建表+navicat/mybitas工具+外键及实例）
  • 【JavaEE初阶】线程安全问题及解决方法
  • IE9 : DOM Exception: INVALID_CHARACTER_ERR (5)
  • JS中 map, filter, some, every, forEach, for in, for of 用法总结
  • 【108天】Java——《Head First Java》笔记（第1-4章）
  • 【腾讯Bugly干货分享】从0到1打造直播 App
  • JAVA并发编程--1.基础概念
  • java架构面试锦集：开源框架+并发+数据结构+大企必备面试题
  • MYSQL 的 IF 函数
  • zookeeper系列（七）实战分布式命名服务
  • 对象引论
  • 函数式编程与面向对象编程[4]:Scala的类型关联Type Alias
  • 机器学习学习笔记一
  • 记一次用 NodeJs 实现模拟登录的思路
  • 前端临床手札——文件上传
  • 如何编写一个可升级的智能合约
  • 如何设计一个比特币钱包服务
  • 微信小程序上拉加载：onReachBottom详解+设置触发距离
  • 问:在指定的JSON数据中（最外层是数组）根据指定条件拿到匹配到的结果
  • 学习使用ExpressJS 4.0中的新Router
  • 7行Python代码的人脸识别
  • Linux权限管理(week1_day5)--技术流ken
  • ​2020 年大前端技术趋势解读
  • ​io --- 处理流的核心工具​
  • (13)[Xamarin.Android] 不同分辨率下的图片使用概论
  • （二）PySpark3：SparkSQL编程
  • （附源码）springboot掌上博客系统 毕业设计063131
  • （附源码）springboot猪场管理系统 毕业设计 160901
  • (六)库存超卖案例实战——使用mysql分布式锁解决“超卖”问题
  • （一）VirtualBox安装增强功能
  • （一）使用IDEA创建Maven项目和Maven使用入门（配图详解）
  • (原创)攻击方式学习之(4) - 拒绝服务(DOS/DDOS/DRDOS)
  • (原創) 人會胖會瘦，都是自我要求的結果 (日記)
  • （转）http协议
  • .NET Entity FrameWork 总结 ，在项目中用处个人感觉不大。适合初级用用，不涉及到与数据库通信。
  • .net MySql
  • .NET 程序如何获取图片的宽高（框架自带多种方法的不同性能）
  • .NET/C# 推荐一个我设计的缓存类型（适合缓存反射等耗性能的操作，附用法）
  • .net6 webapi log4net完整配置使用流程
  • .NET6使用MiniExcel根据数据源横向导出头部标题及数据
  • .Net的C#语言取月份数值对应的MonthName值
  • .NET建议使用的大小写命名原则