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

实验 

主机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.选择一个复制数据最完整的从节点

 实验

主机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地址

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