Redis主从,缓存击穿,雪崩,哨兵等问题

Redis的性能管理:

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未能够有效利用的内存

Redis主从,缓存击穿,雪崩,哨兵等问题_第1张图片

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主从,缓存击穿,雪崩,哨兵等问题_第2张图片

设置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占用内存的效率问题,如何解决

  1. 日常巡检当中,对Redis的占用情况监控
  2. 设置Redis占用系统的阀值,避免占用系统的全部内存
  3. 内存碎片清理,手动,自动
  4. 配置合适的key回收机制

Redis的故障报错问题:

Redis雪崩:

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

雪崩出现的原因:

Redis集群大面积故障

Redis缓存中,大量的数据同时过期,大量的请求无法得到处理

Redis实例宕机

解决雪崩方法:

事前:高可用架构,防止整个缓存故障,主从复制和哨兵模式,Redis集群

事中:在国内用的比较多的方式:HySTRIX,熔断,降级,限流用这三个手段来降低雪崩发生之后的损失,数据库不急即可,但是很慢,不能没有反应,类似于春运期间的12306

事后:Redis备份,快速缓存预热

Redis的缓存击穿:

缓存击穿主要是热点数据缓存过期,或者被删除,多个请求并发访问热点数据,请求也是转发到数据库了,导致数据库的性能下降,经常被请求的缓存数据,最好设置为永不过期

键值对还在,但是值被替换了,原有的请求找不到之后,同时也会请求后台数据库,也是击穿类型的一种

Redis的缓存穿透:

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

Redis的集群:

高可用方案:

  1. 持久化
  2. 高可用 主从复制 哨兵模式 集群

主从复制:

主从复制是Redis实现高可用的基础,哨兵模式和集群都是在主从复制的基础上实现高可用,主从复制实现数据的多机备份,以及读写分离(主服务器负责写,从服务器只能读)

缺陷:主从复制故障之后无法自动恢复,需要人工干预,写操作的负载均衡

主从复制的工作原理:

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

核心图:

Redis主从,缓存击穿,雪崩,哨兵等问题_第3张图片

实现主从复制:

20.0.0.51主

20.0.0.52 从1

20.0.0.53 从2

主:

Redis主从,缓存击穿,雪崩,哨兵等问题_第4张图片

vim /etc/redis/6379.conf

监听地址噶为0.0.0.0

然后

重启服务

Redis主从,缓存击穿,雪崩,哨兵等问题_第5张图片

从1

打开AOF

指向主:

从节点直接自动变成只读模式

然后

/etc/init.d/redis_6379 restart

从2

Redis主从,缓存击穿,雪崩,哨兵等问题_第6张图片

/etc/init.d/redis_6379 restart

验证效果,看日志

tail -f /var/log/redis_6379.log

Redis主从,缓存击穿,雪崩,哨兵等问题_第7张图片

主从复制搭建完成

三台Redis登录Redis验证效果

Redis主从,缓存击穿,雪崩,哨兵等问题_第8张图片

验证主从复制,

Redis主从,缓存击穿,雪崩,哨兵等问题_第9张图片

验证只读模式

Redis主从,缓存击穿,雪崩,哨兵等问题_第10张图片

Set失败,只有主节点可以写,从节点写失败

查看主从策略

redis-cli info replication

Redis主从,缓存击穿,雪崩,哨兵等问题_第11张图片

从策略查看

redis-cli info replication

Redis主从,缓存击穿,雪崩,哨兵等问题_第12张图片

当从1或从2停机一台服务,不影响主从复制功能,而且服务打开后,照样同步

哨兵模式:

先有主从,再有哨兵

在主从复制的基础上,实现主节点故障的自动切换

哨兵模式原理:

哨兵:是一个分布式系统,用于分布式系统,用于在主从结构之间,对每台Redis的服务器进行监控,主节点出现故障时,从节点通过投票的方式选择一个新的master

哨兵模式需要事少三个节点服务器

哨兵模式的结构:

哨兵节点:监控(监控的是Redis节点,不是监控哨兵),不存储数据

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

核心图:

Redis主从,缓存击穿,雪崩,哨兵等问题_第13张图片

演示哨兵模式:

Redis主从,缓存击穿,雪崩,哨兵等问题_第14张图片

取消注释,取消保护模式

哨兵模式端口

哨兵模式后台运行

日志文件运行打开

指定工作目录

指定初识的主服务器

2表示至少需要两台服务器认为主已经下线,才会进行主从切换

最小时间限制,30秒后就认为已挂,主官认为已挂

最大时间限制

先启主节点,再起从节点,先器master,再起sentinel

启动哨兵

查看整个集群的哨兵情况

Redis主从,缓存击穿,雪崩,哨兵等问题_第15张图片

查看日志

Redis主从,缓存击穿,雪崩,哨兵等问题_第16张图片

模拟故障切换(有延时),当再次改完配置文件还是无法启动,记得杀一下进程

Redis主从,缓存击穿,雪崩,哨兵等问题_第17张图片

关闭服务

Redis主从,缓存击穿,雪崩,哨兵等问题_第18张图片

看日志看主从情况,哨兵情况

Redis主从,缓存击穿,雪崩,哨兵等问题_第19张图片

Redis主从,缓存击穿,雪崩,哨兵等问题_第20张图片

哨兵模式投票选举出新的主之后,原主配置文件自动修改,自动指向新的祝

Redis主从,缓存击穿,雪崩,哨兵等问题_第21张图片

新的主配置文件,也会修改,原本的从指向消失

你可能感兴趣的:(缓存,redis,java)