一、redis的性能管理
1、内存指标info memory
内存指标(重要) |
|
注:单位:字节 |
系统巡检:硬件巡检、数据库、中间件(nginx、redis)、docker、k8s
2、内存碎片率
(1)定义:系统已分配给redis,但reids未能有效利用的内存
(2)计算格式:内存碎片率=used_memory_rss/used_memory
(3)监控指标redis–cli info memory|grep ratio(生产环境常用)
监控指标 |
||
分配器碎片的比例 (越小越好,值越高,内存浪费越多) |
||
分配器占用物理内存的比例 |
||
redis占用物理空间额外的开销比例(比例越低越好,redis实际占用的物理内存和向系统申请的内存越接近,额外的开销越低) |
RSS是redis向系统申请的内存空间 |
|
mem_fragmentation_ratio:15.59 |
内存碎片率 (越低越好,内存使用率越高) |
|
3、清理内存的两种方式
(1)自动清理碎片vim /etc/redis/6379.conf
(2)手动清理碎片redis–cli memory purge
4、设置redis的最大内存阀值
(在工作中一定要设置redis的占用内存阈值。若不设置阈值,会塞满内存,直到炸)
(1)先设置最大内存阀值vim /etc/redis/6379.conf
添加maxmemory 1gb
(2)再开启key的回收机制
key的回收机制 |
|
(常用) |
|
maxmemory-policy volatile-ttl (常用) |
使用redis内置的ttl算法,在已设置过期时间的键值对中挑选一个即将过期的键值对 |
maxmemory-policy volatile-random (少用) |
在已设置过期时间的键值对中,挑选数据,随机淘汰键值对 |
allkeys-lru |
使用redis内置的lru算法,对所有的键值对进行淘汰,移除最少使用的键值对 |
allkeys-random (更少用) |
在所有键值对中任意选择数据进行淘汰 |
注:以上算法针对所有的键值对,无论是否设置过期时间 |
|
maxmemory-policy noeviction (最常用) |
【面试题】redis占用内存的效率问题如何解决?(经验)
①日常巡检中,监控redis的占用情况
②设置redis占用系统内存的阀值,避免占用系统全部内存
③手动/自动清理内存碎片
④配置合适的key回收机制
5、redis雪崩(缓存雪崩)(少见)
(1)定义
大量的应用请求无法在redis缓存中处理,请求会全部发送到后台数据库,数据库并发能力本身就差,一旦高并发,数据库很快会崩溃
(2)产生雪崩的原因
①redis集群大面积故障
②在redis缓存中,大量数据同时过期,大量的请求无法得到处理
③redis实例宕机
(3)解决雪崩的方式
①事前预防:采用高可用架构(主从复制、哨兵模式、redis集群),防止整个缓存故障
②事中处理(开发):在国内通用方式——HySTRIX(熔断、降级、限流),降低雪崩发生后的损失,确保数据库不死,可以慢,但不能没有响应
③事后解决:以redis备份的方式恢复数据(运维)或快速缓存预热(开发)
6、redis的缓存击穿(重点)
(1)产生原因
①热点数据缓存过期或被删除,当多个请求并发访问热点数据时,请求转发到数据库,导致数据库性能快速下降。经常被请求的缓存数据最好设置为永不过期
②键值对还在,但值被替换,原有的请求找不到之后,同样会请求后台数据库,导致数据库性能快速下降
(2)解决方式
①热点数据设置成永不过期
②恢复原有的值
7、redis的缓存穿透(恶意攻击)(很少见)
(1)定义
缓存中没有数据,数据库也没有相应的数据,但有用户一直在发起这个都没有的请求,而且请求的数据格式很大。这种情况一般是黑客利用漏洞攻击,压垮应用数据库
(2)解决方式:专门的安全人员处理
二、redis的集群架构
1、高可用方案
(1)主从复制
(2)哨兵模式
(3)redis集群
2、主从复制
(1)主从复制是redis实现高可用的基础,哨兵模式和集群都是在主从复制的基础上实现高可用
(2)主从复制实现数据的多机备份和读写分离(主服务器——写,从服务器——读)
缺点:故障无法自动恢复,需人工干预,无法实现写操作的负载均衡
3、主从复制的工作原理
由主节点master和从节点slave组成,数据复制是单向的,只能从主节点到从节点
4、哨兵模式
(1)哨兵模式定义
哨兵是一个分布式系统,用于在主从结构之间,对每台redis服务进行监控。主节点出现故障时,从节点通过投票的方式选择一个新的master
(2)哨兵模式的结构
①哨兵节点:监控主、从节点,不存储数据
②数据节点:主节点和从节点,都是数据节点
(哨兵1监控从1,从2节点;哨兵2监控主节点,从2 节点;哨兵3监控主节点,从1节点)
(2)哨兵模式工作原理
每个哨兵节点每隔一秒,通过ping命令方式,检测主、从之间的心跳线,主节点在一定时间内没有回复或回复了错误消息,这个时候哨兵会主观认为主节点下线了;超过半数的哨兵节点认为主节点下线了,这个时候才会认为主节点是客观下线
故障恢复可能会有延迟,因为有一个选举过程
(4)如何选举新的主节点
哨兵节点通过raft算法(选举算法),每个节点共同投票选举出一个新的master,然后新的master实现主节点的转移和故障恢复通知
(5)主节点的选举过程
①已下线的从节点不会被选为主节点
②选择配置文件中从节点优先级最高的replica-priority 100
③自动选择一个复制数据最完整的从节点
三、主从复制+哨兵模式实验
基于主从复制做哨兵模式实验
实验目的:解决redis单节点故障问题
实验条件:
IP地址 |
作用 |
|
20.0.0.14 |
主服务器 |
redis服务 |
20.0.0.24 |
从服务器1 |
redis服务 |
20.0.0.34 |
从服务器2 |
redis服务 |
实验步骤:
1、主从复制实验
从1
从2
replicaof 20.0.0.14 6379表示只读(20.0.0.14是主服务器的IP地址)
主从复制完成
(3)测试
2、哨兵模式实验
这个2:一般设置成集群的一半
最小切换时间30秒
最大切换时间180秒
(2)配置从服务器
从1
从2(与从1同样的配置)
redis-sentinel sentinel.conf &
监控哨兵集群的信息redis-cli -p 26379 info Sentinel
哨兵模式搭建完毕
查看从节点信息tail -f /var/log/sentinel.log
(4)故障切换
模拟故障
看日志是否主从切换,有延迟
目前,新主的IP地址是20.0.0.34
(5)测试
①测试新主能不能写
能
恢复原主
②测试原主能否继续写
不能
原因:配置文件/etc/redis/6379.conf发生变化
原主(现从2)
从1
原从2(新主)
原文地址:https://blog.csdn.net/2303_79207100/article/details/134553259
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_1569.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!