查看内存使用指标
- 查看内存使用指标
- info memory
-
- used_memory:1800800 redis中主句占用的内存
- used_memory_rss:5783552 redis向操作系统申请的内存
- used_memory_peak:1800800使用内存的峰值
系统巡检:硬件巡检,数据库,nginx redis docker k8s
- used_memory_rss/used_memory
-
- 系统已经分配给了redis,但是redis未能够有效利用的内存
-
-
- 查看内存碎片率
-
- redis-cli info memory | grep ratio
-
- allocator_frag_ratio:1.19
- 分配器碎片的比例,redis住金层调度时产生的内存,比例越小越好,值越高,内存的浪费越多
-
- allocator_rss_ratio:7.15
- 分配器占用物理内存的比例,告诉你主进程调度执行时占用了多少物理内存
-
- rss_overhead_ratio:0.31
- rss是向系统申请的内存空间,redis占用物理空间额外的开销比例,比例越低越好,redis实际占用物理内存和向系统申请的内存越接近,额外的开销越低
-
- mem_fragmentation_ratio:3.33
- 内存碎片的比例,越低越好,内存的使用率越高
- 自动清理内存碎片
- vim /etc/redis/6379.conf
- 最后一行添加
- activedefrag yes
- 重启服务
-
- 手动清理内存碎片
- redis-cli memory purge
- 设置redis的最大内存阀值
- vim /etc/redis/6379.conf
- 567行
- maxmemory lgb
一旦到达阀值,自动清理碎片,开启key的回收机制(回收键值对)
- vim /etc/redis/6379.conf
- 598行
- maxmemory-policy volatile-lru
- 使用redis内置的LRU算法,把已经设置了过期时间的键值对中淘汰数据,移除最近最少使用键值对(针对已经设置了过期时间的键值对)
-
- maxmemory-policy volatile-ttl
- 已经设置了过期时间的键值对,从当中挑选一个即将过期的键值对(针对有设置过期时间的键值对)
-
- maxmemory-policy volatile-random
- 从已经设置了过期时间的键值对当中,挑选数据随机淘汰键值对(对设置了过期时间的键值对进行随机移除)
-
- allkeys-lru
- LRU算法当中,对所有的键值对进行淘汰,移除最少使用的键值对(针对所有的键值对)
-
- allkeys-random
- 从所有键值对当中任意选择数据进行淘汰
-
- maxmemory-policy noeviction
- 禁止键值对回收(不删除任何键值对,直到redis把内存塞满,写不了,报错)
在工作中,一定要给redis占用内存设置阀值
缓存雪崩:大量的应用请求无法在redis缓存当中处理,请求会全部发送到后台数据库,数据库并发能力就很差,一旦高并发,数据库很快崩溃
1、redis集群大面积故障
2、redis缓存中,大量数据同时过期,大量的请求无法得到处理
3、redis实例宕机
事前:高可用架构,防止整个缓存故障,主从复制和哨兵模式 redis集群
事中:在国内用的比较多的方式:HySTRIX,熔断,降级,限流 ,用这个三个手段来降低雪崩发生之后的损失(数据库不死即可,慢可以,但是不能没有响应)
事后:redis备份,快速缓存预热
缓存击穿主要是热点数据缓存过期,或者被删除,多个请求并发热点数据,请求也是转发到数据库了,导致数据库的性能快速下降
经常被请求的缓存数据,最好设置为永不过期
键值对还在,但是值被替换了,原有的请求找不到之后,同样也回去请求后台数据库,也是击穿的一种
缓存中没有数据,数据库也没有对应数据,但是有用户一直发起这个都没有的请求,而且请求的数据格式很大,黑客在利用漏洞攻击,压垮应用数据库