redis的高可用

2023-12-18 06:02:31

redis的高可用:

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

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

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

持久化:持久化是最简单的高可用方法,主要作用是数据备份,也就是把redis缓存在内存中的数据保存到本地的硬盘中。(冷备份)

redis持久化的两种方式:

  1. RDB持久化:redis在内存中的数据定时保存到磁盘。(自动执行,手动执行)
  2. AOF持久化:redis的操作日志,以追加的方式写入一个AOF的文件,类似于mysql的binlog

rdb的持久化:指在指定的时间间隔内,将内存中当前进程中的数据生成快照保存到硬盘(快照持久化),用二进制压缩存储。

保存的文件名的后缀名.rdb。redis启动时,可以直接读取快照条件,实现数据恢复

rdb的触发机制:

手动机制:save bgsave都可以生成RDB文件

save创建RDB文件时,整个redis进程都会被阻塞,期间redis将无法进行读写操作,直到RDB文件创建完成为止。(生产中禁止使用save创建RDB文件)

手动触发机制:

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

BGSAVE工作流程:主进程会通过fork机制创建一个子进程,子进程的创建过程中,主进程会阻塞,子进程创建完毕,主进程解除阻塞。子进程来创建RDB文件。创建完成之后,通知主进程更新通知信息。

自动触发机制:

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持久化:

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

AOF的实时性更好,也是主流的持久化方案。

开启AOF,默认是关闭需要打开

vim /etc/redis/6379.conf
?
700行
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的重写功能:

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

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

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

AOF同步文件策略的三种方式:

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

重写的触发条件是什么?

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查看文件恢复
实验已经完成!

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.多条命令合并成一个。

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

RDB和AOF之间的优缺点:

RDB的优点:文件体积小,网络传输速度很快,适合全量复制。恢复速度也比AOF要快

??????缺点:做不到实时的持久化,数据如此重要,不能够容忍丢失的。另外RDB需要满足特定的格式,兼容性很差。老版本的RDB不支持新版本(redis的版本一定要一致)5.0.7

AOF的优点:秒级持久化。兼容性好。文本格式保存的是命令(实时持久化)

??????缺点:文件大,恢复速度慢。AOF持久化需要频繁的向磁盘写数据,磁盘的I/O压力

也很大。对redis主进程的性能也会有一定的影响。

总结:

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

rdb:save线上禁用,bgsave

AOF:实时持久化 写入的操作的命令,除了查set del会记录,get select不计入。实时记录,恢复方式类似于MYSQL的bin-log

重写:推荐但是不必须的。重写也是主进程创建一个子进程,在过程中产生的数据以及同步策略都是写入到AOF文件当中。

文章来源:https://blog.csdn.net/DDYYmmm/article/details/135048820
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。