Redis的数据缓存在内存当中
INFO memory
used_memory:853808
Redis中数据占用的内存
used_memory_rss:3715072
Redis向操作系统申请的内容
used_memory_peak:853808
Redis使用的内存的峰值
系统巡检:硬件巡检,数据库,Nginx,Redis,docker,k8s
内存碎片率:used_memory_rss/used_memory
系统已经分配给了Redis,但是Redis未能够有效利用的内存
allocator_frag_ratio:1.26
分配碎片的比例,Redis主进程调度时产生的内存,比例越小越好,值越高,内存的浪费越多
allocator_rss_ratio:6.02
分配占用物理内存的比例,告诉你主进程调度执行时占用了多少物理内存
rss_overhead_ratio:0.43
Rss是向系统申请的内存空间,Redis占用物理空间额外的开销比例,比例越低越好,Redis实际占用的内存和向系统申请的内存越接近,额外的开销越低
mem_fragmentation_ratio:4.69
内存碎片的比例,越低越好,内存的使用率越高
vim /etc/redis/6379.conf
最后一行添加
activedefrag yes
手动碎片清理:
redis-cli memory purge
设置Redis的最大内存阀值:
vim /etc/redis/6379.conf
一旦达到设置的阀值,自动清理碎片,开启key的回收机制
Key回收的策略:
vim /etc/redis/6379.conf
599行添加:
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缓存当中处理,请求全部发送到后台数据库,数据库的并发能力本身就很差,一旦高并发,数据库就会很快崩溃
雪崩出现的原因:
Redis集群大面积故障
Redis缓存中,大量的数据同时过期,大量的请求无法得到处理
Redis实例宕机
事前:高可用架构,防止整个缓存故障,主从复制和哨兵模式,Redis集群
事中:在国内用的比较多的方式:HySTRIX,熔断,降级,限流用这三个手段来降低雪崩发生之后的损失,数据库不急即可,但是很慢,不能没有反应,类似于春运期间的12306
事后:Redis备份,快速缓存预热
缓存击穿主要是热点数据缓存过期,或者被删除,多个请求并发访问热点数据,请求也是转发到数据库了,导致数据库的性能下降,经常被请求的缓存数据,最好设置为永不过期
键值对还在,但是值被替换了,原有的请求找不到之后,同时也会请求后台数据库,也是击穿类型的一种
缓存当中没有数据,数据库当中也没有对应数据,但是有用户一直发起这个都没有的请求,而且请求的数据格式很大,黑客在利用漏洞在攻击,压垮应用数据库
主从复制是Redis实现高可用的基础,哨兵模式和集群都是在主从复制的基础上实现高可用,主从复制实现数据的多机备份,以及读写分离(主服务器负责写,从服务器只能读)
缺陷:主从复制故障之后无法自动恢复,需要人工干预,写操作的负载均衡
1.主节点(MAster)从节点(slave)组成,数据复制是单向的,只能从主节点到从节点
核心图:
20.0.0.51主
20.0.0.52 从1
20.0.0.53 从2
主:
vim /etc/redis/6379.conf
监听地址噶为0.0.0.0
然后
重启服务
从1
打开AOF
指向主:
从节点直接自动变成只读模式
然后
/etc/init.d/redis_6379 restart
从2
/etc/init.d/redis_6379 restart
验证效果,看日志
tail -f /var/log/redis_6379.log
主从复制搭建完成
三台Redis登录Redis验证效果
验证主从复制,
验证只读模式
Set失败,只有主节点可以写,从节点写失败
查看主从策略
redis-cli info replication
从策略查看
redis-cli info replication
当从1或从2停机一台服务,不影响主从复制功能,而且服务打开后,照样同步
先有主从,再有哨兵
在主从复制的基础上,实现主节点故障的自动切换
哨兵:是一个分布式系统,用于分布式系统,用于在主从结构之间,对每台Redis的服务器进行监控,主节点出现故障时,从节点通过投票的方式选择一个新的master
哨兵模式需要事少三个节点服务器
哨兵节点:监控(监控的是Redis节点,不是监控哨兵),不存储数据
数据节点:主节点和从节点都是数据节点
核心图:
取消注释,取消保护模式
哨兵模式端口
哨兵模式后台运行
日志文件运行打开
指定工作目录
指定初识的主服务器
2表示至少需要两台服务器认为主已经下线,才会进行主从切换
最小时间限制,30秒后就认为已挂,主官认为已挂
最大时间限制
先启主节点,再起从节点,先器master,再起sentinel
启动哨兵
查看整个集群的哨兵情况
查看日志
模拟故障切换(有延时),当再次改完配置文件还是无法启动,记得杀一下进程
关闭服务
看日志看主从情况,哨兵情况
哨兵模式投票选举出新的主之后,原主配置文件自动修改,自动指向新的祝
新的主配置文件,也会修改,原本的从指向消失