• redis之主从复制和哨兵模式


    (一)redis的性能管理

    1、redis的数据缓存在内存中

    2、查看redis的性能:info memory(重点)

    used_memory:904192(单位字节)

    redis中数据占用的内存

    used_memory_rss:10522624

    redis向操作系统申请的内存

    used_memory_peak:904192

    redis使用内存的峰值

    3、生产中的日常系统巡检:硬件巡检、数据库、nginx、redis、docker、k8s

    4、redis的内存碎片率:used_memory_rss/used_memory(重点)

    (1)内存碎片率:系统已经分配给了redis,但是redis未有效利用的内存
    (2)查看内存碎片率:redis-cli info memory | grep ratio

    allocator_frag_ratio:1.27

    分配器碎片的比例,redis主进程调度时产生的内存,比例越小越好,值越高说明碎片越多,内存的浪费越多

    allocator_rss_ratio:5.24

    分配器占用物理内存的比例,也就是主进程调度执行时占用了多少物理内存

    rss_overhead_ratio:1.17

    RSS是向系统申请的内存空间,表示redis占用物理空间额外的开销比例,比例越低越好,表示redis实际占用的物理内存和向系统申请的内存越接近,额外的开销就越低

    mem_fragmentation_ratio:12.49

    内存碎片的比例,比例越低越好,表示内存的使用率越高

    (3)清理碎片
    ①自动清理(修改配置文件)——设置redis的最大内存阀值

    设置redis的最大内存阀值:一旦到达阀值,自动清理碎片,开启key的回收机制

    生产中一定要给redis设置阀值,不设置最大阀值,内存会直接爆满——重点

    key回收的策略(重点)

    maxmemory-policy volatile-lru

    使用redis内置的LRU算法,把已经设置了过期时间的键值对进行淘汰数据,移除最近最少使用的键值对(针对已经设置了过期时间的键值对)

    maxmemory-policy volatile-ttl

    已经设置了过期时间的键值对,从当中挑选一个即将过期的键值对(针对已经设置过期时间的键值对)

    maxmemory-policy volatile-random

    从已经设置了过期时间的键值对当中,挑选数据随机的淘汰键值对(对设置了过期时间的键值对进行随机移除)

    allkeys-lru

    LRU算法当中,对所有的键值对进行淘汰,移除最少使用的键值对(针对所有的键值对)

    allkeys-random

    所有键值对当中任意选择数据进行淘汰

    maxmemory-policy noeviction

    禁止键值对回收(不删除任何键值对,直到redis把内存塞满,写不了报错为止)

    ②手动清理:redis-cli memory purge

    (4)redis占用内存的效率问题如何解决?
    ①日常巡检中,对redis的占用情况进行监控
    ②设置redis占用系统内存的阀值,避免占用系统全部内存
    ③内存碎片清理(手动、自动)
    ④配置适合的key回收机制

    5、redis雪崩(少见)

    (1)redis雪崩:缓存雪崩,是指大量的应用请求无法在redis缓存中处理,请求会全部发送到后台数据库,数据库的压力会激增,数据库并发能力本身就很差,一旦高并发,数据库会很快崩溃
    (2)雪崩产生的原因:
    ①redis集群大面积故障
    ②redis缓存中,大量数据同时过期,大量的请求无法得到处理
    ③redis实例宕机
    (3)解决方案
    ①事前:高可用架构,防止整个缓存故障,主从复制、哨兵模式和redis集群
    ②事中:在国内的通用方式:HySTRIX,熔断、降级、限流三个手段来降低雪崩发生之后的损失,数据库不死即可,可以慢,但是不能没有响应(开发做)
    ③事后:redis备份,快速缓存预热(开发做)

    6、redis的缓存击穿(常见)

    (1)原因:热点数据缓存过期或者被删除,多个请求并发访问热点数据,请求转发到后台
    数据库,导致数据库的性能快速下降
    (2)键值对还在,但值被替换,原有的请求找不到之后,同样请求后台数据库
    *经常被请求的缓存数据,最好设置为永不过期

    7、redis的缓存穿透(少见)

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

    (九)redis的集群架构(高可用)

    1、高可用方案:主从复制、哨兵模式、集群

    (十)redis之主从复制

    1、主从复制

    (1)是redis实现高可用的基础,哨兵模式和集群都是在主从复制的基础上实现高可用
    (2)实现数据的多机备份,以及读写分离(主服务器负责写,从服务器只能读,设置了从默认是只读模式)
    (3)缺点:故障无法恢复,需要人工干预,写操作无法实现负载均衡
    (4)主从复制需要至少3个节点

    2、主从复制的工作原理

    (1)主节点(master)、从节点(slave),数据的复制是单向的,只能从主节点到从节点

    3、主从复制的工作机制

    4、主从复制的架构
    (1)20.0.0.41:master
    (2)20.0.0.42:slave1
    (3)20.0.0.43:slave3

    5、实验过程

    (1)配置主节点

    (2)配置从服务器

    (3)测试

    (二)哨兵模式(先有主从、再有哨兵)

    1、哨兵模式

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

    2、哨兵模式的原理

    (1)哨兵:分布式系统,部署在每一个redis节点上,用于在主从结构之间,对每台redis的服务进行监控
    (2)主节点出现故障时,从节点通过投票的方式选择一个新的master
    (3)哨兵模式需要至少3个节点

    3、哨兵模式的结构

    (1)哨兵节点:监控节点,不存储数据
    (2)数据节点:主节点和从节点

    4、哨兵模式的工作机制

    (1)哨兵模式的原理:每一个哨兵节点每隔一秒,通过ping命令方式,检测主、从之间的心跳线。主节点在一定时间内没有回复或者回复了错误的消息,这个时候,哨兵就会主观的认为主节点下线了,超过半数的哨兵节点认为主节点下线了,这个时候才会认为主节点是客观下线
    (2)哨兵节点通过raft算法(选举算法),每个节点共同投票选举出一个新的master,然后新的master实现主节点转移和故障恢复通知
    (3)主节点的选举过程
    ①已经下线的从节点不会被选为主节点
    ②选择配置文件当中,从节点优先级最高的replica-priority 100
    ③选择一个复制数据最完整的从节点

    5、实验过程

    (1)配置主节点

    (2)配置从服务器

    起服务:先起master,再起slave:redis-sentinel sentinel.conf &

    (3)监控哨兵集群的信息

    (4)故障切换(有延迟)

    (5)故障恢复

  • 相关阅读:
    2022前端CSS经典面试题
    【ESP8266 快速入门】搭建VS code开发环境以及常用开发环境总结(基于安信可NodeMCU、C/C++)
    Python中不为人知的四个特性
    Bus 消息总线
    基于MS16F3211芯片的触摸控制灯的状态变化和亮度控制总结版(11.22)
    springboot整合
    Kubernetes(K8S)命令指南
    Q&A特辑 | 这场直播解决了我对于电商风控的大部分疑问
    JAVA微服务快速开发平台的功能特点
    一键实现冒泡排序算法,代码质量有保障!
  • 原文地址:https://blog.csdn.net/weixin_48145965/article/details/134550548