Redis 性能管理 主从复制与哨兵模式

目录

redis性能管理

内存碎片率

如何清理内存

面试题

Redis雪崩

Redis集群大面积故障

面试:Redis的缓存击穿

Redis的缓存穿透

Redis的集群高可用方案

redis的主从复制

哨兵模式


redis性能管理

redis的数据缓存在内存当中

info memory
#在redis数据库中查看的命令,可以看到当前它使用系统内存的情况

used_memory:1800800
#表示redis数据占用的内存,单位是字节

used_memory:_rss:5783552
#表示redis向操作系统申请的内存

used_memory_peak:1800800
#redis使用内存的峰值,最高值

#运维工作日常:系统巡检,还有关键组件巡检,数据库,nginx,redis,docker,k8s

内存碎片率

used_memory:_rss  /  used_memory
#用向操作系统申请的内存除以redis数据占用的内存得出为内存碎片率
#内存的碎片率指系统已经分配给了redis,但是redis未能够有效利用的内存

工作中非常重要的指标

allocator_frag_ration:1.19
#分配器碎片的比率,redis主进程调度时产生的内存空间,比例越小越好,值越高,内存的浪费越多

allocator_rss_ration:7.15
#分配器占用的物理内存的比率,告诉你主进程调度执行时占用了多少物理内存

ass_overhead_ration:0.31
#rss是向系统申请的内存空间,redis占用物理空间额外的开销比例,比率越低越好,表示redis实际占用的物理内存和向系统申请的内存越接近,额外的开销越低,

mem_fragmentation_ratio:3.33
#内存碎片的比例,越低越好,内存的使用率越低越好

如何清理内存

自动清理

自动清理需要配置redis文件

且一定需要设置redis的最大内存阀值

vim /etc/redis/6379.conf

手动清理

客户端输入命令

redis-cli memory purge

#配置文件一定要设置阀值
Vim /etc/redis/6379.conf

activedefrag yes
#最后一行插入 ,开启自动清理,只要达到一定的阀值(需要手动配置,如下)

maxmemory 1gb
#567行 达到阀值,会自动清理碎片,需要配合开启key的回收机制

maxmemory-policy volatile-lru
#599行左右,使用redis内置的LRU算法,把已经设置了过期时间的键值对中淘汰数据,移除最近最少使用键值对(针对已经设置了过期时间的键值对)(推荐该配置)

maxmemory-policy volatile-ttl
#已经设置了过期时间的键值对,从当中挑选一个即将过期的键值对。(针对有设置生命周期的键值对)

maxmemory-policy volatile-random
#从已经设置了过期时间的键值对当中,挑选数据随机淘汰键值对(对设置了过期时间的键值对进行随机移除)

allkeys-lru
#根据LRU算法当中对所有的键值对,进行淘汰,移除最少使用的键值对,(针对所有的键值对)

allkeys-random
#对所有键值对当中任意选择数据进行淘汰

maxmemory-policy noeviction
#禁止键值对回收,不删除任何键值对,直到redis把内存塞满,写不了,报错为止.(推荐这个配置)
面试题
你在工作当中发现redis占用内存过高的效率问题,如何解决
1 日常巡检当中,对redis占用情况做监控
2 设置redis占用系统内存的阀值,避免占用系统全部内存
3 内存碎片清理,有手动清理和自动清理
4 配合合适的key回收机制

Redis雪崩

也叫缓存雪崩,大量的应用请求无法再redis缓存当中处理,请求会全部发送到后台数据库,数据库并发能力本身就很差,一旦高并发,数据库很快崩溃

Redis集群大面积故障

原因 在redis缓存中,大量数据同时过期,大量的请求无法得到处理,还有可能是redis实例宕机,或者恶意删除了键值对。
解决方案
事前 高可用架构,防止整个缓存故障,主从复制和哨兵模式,redis集群
事中

在国内用的比较多的方式

HySTRIX(基于代码机制实现),熔断机制(到达请求阀值立即断开),降级(到达阀值之后自动降低并发请求数量),限流(只允许一定数量的请求到服务器上),这几个方式来降低雪崩发生之后的损失,确保数据库存活,速度慢一点,效率低一点可以接收,但不能没有响应

事后 通过redis备份,快速缓存预热
面试:Redis的缓存击穿
1 缓存击穿主要是热点数据缓存过期,或者被删除,当多个请求并发访问热点数据,请求转发到了后台数据库,从而导致数据库的性能快速下降
2 键值对还在,但是值被替换了,原有的请求找不到之后,同样也会去请求后台数据库
经常被请求的缓存数据最好设置为永不过期

Redis的缓存穿透

缓存中没有数据,数据库也没有对应的数据,但是有用户一直发起这个没有的请求,而且请求的数据格式很大,这就是黑客在利用漏洞攻击,用来压垮应用数据库

Redis的集群高可用方案

1 持久化
2

高可用

主从复制,哨兵模式,集群

redis的主从复制

概念

它是redis实现高可用的基础,哨兵模式和集群都是在主从复制的基础之上实现高可用

主从复制实现数据的多机备份以及读写分离(主服务器负责写,从服务器只能读),缺点是故障无法自动恢复,需要人工干预,写操作的负载均衡

原理

主节点(master)从节点(slave)组成,数据复制是单向的,只能从主节点到从节点,从节点只能读

工作流程

首先slave1会向主发送一个syn command 请求建立连接,主节点收到之后不管slave是第一次连接还是从新连接,主节点都会启动一个后台进程,执行Bgsave,并且主节点会把所有修改数据的命令加载到缓存和数据文件之中,数据文件创建完毕之后由master传送给slave,slave会把这个数据文件,先保存到硬盘,再加载到内存

主从复制推荐使用AOF

Redis 性能管理 主从复制与哨兵模式_第1张图片

实验 

主机1
[root@c1 ~]# systemctl stop firewalld
[root@c1 ~]# setenforce 0
[root@c1 ~]# vim /etc/redis/6379.conf

bind 0.0.0.0
#70行,监听地址改成所有网段都可以通信

daemonize yes
#137行,打开

logfile /var/log/redis_6379.log
#172行,日志文件要打开

dir /var/lib/redis/6379
#264行,这是工作目录

appendonly yes
#AOF持久化模式打开
[root@c1 ~]# /etc/init.d/redis_6379 restart

主机2
[root@c2 ~]# systemctl stop firewalld
[root@c2 ~]# setenforce 0
[root@c2 ~]# vim /etc/redis/6379.conf

bind 0.0.0.0
#70行,所有网段都可以通信

daemonize yes
#137行,守护进程打开

dir /vr/lib/redis/6379
#264行,日志文件要打开

replicaof 192.168.233.66 6379
#在288行,开启后从节点将成为只读模式,指向主的ip,6379是主的端口号

appendonly yes
#AOF同步要打开

[root@c2 ~]# /etc/init.d/redis_6379 restart
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...

主机3
[root@c3 ~]# systemctl stop firewalld
[root@c3 ~]# setenforce 0
[root@c3 ~]# vim /etc/redis/6379.conf

bind 0.0.0.0
#70行

daemonize yes
#288行,后台同步打开

replicaof 192.168.233.66 6379
#288行,打开

appendonly yes
#700行,打开

[root@c3 ~]# /etc/init.d/redis_6379 restart
Stopping ...
Redis stopped
Starting Redis server...

#如果要确定是否配置成功可以查看一下日志
主机1
[root@c1 ~]# tail -f /var/log/redis_6379.log
4928:M 22 Nov 2023 23:14:28.212 * Synchronization with replica 192.168.233.67:6379 succeeded
4928:M 22 Nov 2023 23:18:54.708 * Synchronization with replica 192.168.233.68:6379 succeeded
#表示已经配置且同步成功

#然后直接验证主从是否可以进行复制,从是否为只读且不能写入

哨兵模式

概念 先有主从复制再有哨兵模式,在主从复制的基础之上,从而实现主节点故障的自动切换
原理 哨兵模式是一个分布式系统,用于在主从结构之间,对每台redis的服务进行监控,主节点出现故障时,从节点通过投票的方式选择一个新的master,哨兵模式也需要至少三个节点
结构

哨兵节点:监控,不存储任何数据

数据节点:主节点和从节点都是数据节点

工作流程 每个哨兵节点之间每隔一秒,会通过ping命令方式,互相监控主从之间的节点心跳线,主节点在一定时间内没有回复或者回复了错误的消息,这个时候,哨兵就会主观的认为主节点下线了,而超过半数的哨兵节点认为主节点下线,则会被认为主节点客观下线,一旦被认为客观下线,哨兵节点会通过raft算法(选举算法),每个节点共同投票选举出一个新的master,然后新的master实现主节点转移和故障恢复通知

主节点的选举过程

1.已经下线的从节点不会被选为主节点

2.选择配置文件当中,从节点优先级最高的replica-prioity 100

3.选择一个复制数据最完整的从节点

Redis 性能管理 主从复制与哨兵模式_第2张图片

 实验

主机1
[root@c1 ~]# vim /opt/redis-5.0.7/sentinel.conf

protected-mode no
#17行,取消注释,关闭保护模式

port 26379
#21行,哨兵模式的默认端口

daemonize yes
#26,指定哨兵模式是否后台运行改成也是

pidfile /var/run/redis-sentinel.pid
#31行,哨兵模式的进程文件

logfile "/var/log/sentinel.log"
#36行,指定他的日志文件的存放路径

dir "/var/lib/redis/6379"
#65行,指定它的数据库存放路径

sentinel monitor mymaster 192.168.233.66 6379 2
#84行,指定初始的主服务器,ip要指向主,6379为主的端口,2表示最少需要2台服务器认为主已经下线,才会进行主从切换,6台服务器就要3台或者4台

sentinel down-after-milliseconds mymaster 30000
#113行,判断服务器宕机的最小超时时间30000毫秒,也就是30秒内没有反应就会主观认为主服务器已下线

sentinel failover-timeout mymaster 180000
#146行,判断服务器宕机的最大超时时间180000毫秒,也就是180秒内没有反应,两台从节点就会共同投票主节点下线,进行主从切换

[root@c1 redis-5.0.7]# cd /opt/redis-5.0.7/
[root@c1 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 17695




主机2
[root@c2 redis-5.0.7]# vim /opt/redis-5.0.7/sentinel.conf

protected-mode no
#17行,取消注释保护模式关闭

daemonize yes
#26行,后台运行打开

logfile "/var/log/sentinel.log"
#36行,指定日志文件路径

dir /var/lib/redis/6379
#65行,指定数据库的工作目录

sentinel monitor mymaster 192.168.233.66 6379 2
#84行,指向原主服务器ip

#最小超时时间与最大超时时间需要打开113行最小,146行最大

[root@c2 opt]# cd /opt/redis-5.0.7/
[root@c2 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 57998




主机3
[root@c3 ~]# vim /opt/redis-5.0.7/sentinel.conf

protected-mode no
#17行,取消注释保护模式关闭

daemonize yes
#26行,后台运行打开

logfile "/var/log/sentinel.log"
#36行,指定日志文件路径

dir /var/lib/redis/6379
#65行,指定数据库的工作目录

sentinel monitor mymaster 192.168.233.66 6379 2
#84行,指向原主服务器ip

#最小超时时间与最大超时时间需要打开113行最小,146行最大

[root@c3 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 48920

主机1
[root@c1 redis-5.0.7]# redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.233.66:6379,slaves=2,sentinels=2
#表示为主服务器,ip为66,有两个从服务器,2台机器(一主两从应该是3)
[root@c1 redis-5.0.7]# tail -f /var/log/sentinel.log
#看从节点的信息,ID is cf399f2635f3f5004a61346698b524701afbbb67 id等于ip地址

#之后就可以验证主从复制与故障切换,可能会有延迟

你可能感兴趣的:(redis,数据库,缓存)