目录
redis性能管理
内存碎片率
如何清理内存
面试题
Redis雪崩
Redis集群大面积故障
面试：Redis的缓存击穿
Redis的缓存穿透
Redis的集群高可用方案
redis的主从复制
哨兵模式
redis性能管理
| redis的数据缓存在内存当中 |
info memory
#在redis数据库中查看的命令,可以看到当前它使用系统内存的情况
used_memory:1800800
#表示redis数据占用的内存,单位是字节
used_memory:_rss:5783552
#表示redis向操作系统申请的内存
used_memory_peak:1800800
#redis使用内存的峰值,最高值
#运维工作日常:系统巡检,还有关键组件巡检,数据库,nginx,redis,docker,k8s内存碎片率
used_memory:_rss / used_memory
#用向操作系统申请的内存除以redis数据占用的内存得出为内存碎片率
#内存的碎片率指系统已经分配给了redis,但是redis未能够有效利用的内存
工作中非常重要的指标
allocator_frag_ration:1.19
#分配器碎片的比率,redis主进程调度时产生的内存空间,比例越小越好,值越高,内存的浪费越多
allocator_rss_ration:7.15
#分配器占用的物理内存的比率,告诉你主进程调度执行时占用了多少物理内存
ass_overhead_ration:0.31
#rss是向系统申请的内存空间,redis占用物理空间额外的开销比例,比率越低越好,表示redis实际占用的物理内存和向系统申请的内存越接近,额外的开销越低，
mem_fragmentation_ratio:3.33
#内存碎片的比例,越低越好,内存的使用率越低越好如何清理内存
| 自动清理 | 自动清理需要配置redis文件 且一定需要设置redis的最大内存阀值 vim /etc/redis/6379.conf |
| 手动清理 | 客户端输入命令 redis-cli memory purge |
#配置文件一定要设置阀值
Vim /etc/redis/6379.conf
activedefrag yes
#最后一行插入 ,开启自动清理,只要达到一定的阀值(需要手动配置,如下)
maxmemory 1gb
#567行 达到阀值,会自动清理碎片，需要配合开启key的回收机制
maxmemory-policy volatile-lru
#599行左右,使用redis内置的LRU算法,把已经设置了过期时间的键值对中淘汰数据,移除最近最少使用键值对（针对已经设置了过期时间的键值对）(推荐该配置)
maxmemory-policy volatile-ttl
#已经设置了过期时间的键值对,从当中挑选一个即将过期的键值对。(针对有设置生命周期的键值对)
maxmemory-policy volatile-random
#从已经设置了过期时间的键值对当中,挑选数据随机淘汰键值对(对设置了过期时间的键值对进行随机移除)
allkeys-lru
#根据LRU算法当中对所有的键值对,进行淘汰,移除最少使用的键值对,(针对所有的键值对)
allkeys-random
#对所有键值对当中任意选择数据进行淘汰
aaxmemory-policy noeviction
#禁止键值对回收，不删除任何键值对,直到redis把内存塞满,写不了,报错为止.(推荐这个配置)面试题
| 你在工作当中发现redis占用内存过高的效率问题,如何解决 | |
| 1 | 日常巡检当中,对redis占用情况做监控 |
| 2 | 设置redis占用系统内存的阀值,避免占用系统全部内存 |
| 3 | 内存碎片清理,有手动清理和自动清理 |
| 4 | 配合合适的key回收机制 |
Redis雪崩
| 也叫缓存雪崩,大量的应用请求无法再redis缓存当中处理,请求会全部发送到后台数据库,数据库并发能力本身就很差,一旦高并发,数据库很快崩溃 |
Redis集群大面积故障
| 原因 | 在redis缓存中,大量数据同时过期,大量的请求无法得到处理,还有可能是redis实例宕机,或者恶意删除了键值对。 |
| 解决方案 | |
| 事前 | 高可用架构,防止整个缓存故障,主从复制和哨兵模式,redis集群 |
| 事中 | 在国内用的比较多的方式 HySTRIX(基于代码机制实现)，熔断机制(到达请求阀值立即断开)，降级(到达阀值之后自动降低并发请求数量)，限流(只允许一定数量的请求到服务器上)，这几个方式来降低雪崩发生之后的损失，确保数据库存活，速度慢一点，效率低一点可以接收，但不能没有响应 |
| 事后 | 通过redis备份，快速缓存预热 |
面试：Redis的缓存击穿
| 1 | 缓存击穿主要是热点数据缓存过期，或者被删除，当多个请求并发访问热点数据，请求转发到了后台数据库，从而导致数据库的性能快速下降 |
| 2 | 键值对还在，但是值被替换了,原有的请求找不到之后，同样也会去请求后台数据库 |
| 经常被请求的缓存数据最好设置为永不过期 |
Redis的缓存穿透
| 缓存中没有数据,数据库也没有对应的数据，但是有用户一直发起这个没有的请求，而且请求的数据格式很大，这就是黑客在利用漏洞攻击，用来压垮应用数据库 |
Redis的集群高可用方案
| 1 | 持久化 |
| 2 | 高可用 主从复制，哨兵模式，集群 |
redis的主从复制
| 概念 | 它是redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础之上实现高可用 主从复制实现数据的多机备份以及读写分离(主服务器负责写，从服务器只能读)，缺点是故障无法自动恢复，需要人工干预，写操作的负载均衡 |
| 原理 | 主节点(master)从节点(slave)组成，数据复制是单向的，只能从主节点到从节点，从节点只能读 |
| 工作流程 | 首先slave1会向主发送一个syn command 请求建立连接,主节点收到之后不管slave是第一次连接还是从新连接，主节点都会启动一个后台进程，执行Bgsave，并且主节点会把所有修改数据的命令加载到缓存和数据文件之中，数据文件创建完毕之后由master传送给slave，slave会把这个数据文件，先保存到硬盘，再加载到内存 主从复制推荐使用AOF |
实验
主机1
[root@c1 ~]# systemctl stop firewalld
[root@c1 ~]# setenforce 0
[root@c1 ~]# vim /etc/redis/6379.conf
bind 0.0.0.0
#70行,监听地址改成所有网段都可以通信
daemonize yes
#137行,打开
logfile /var/log/redis_6379.log
#172行,日志文件要打开
dir /var/lib/redis/6379
#264行,这是工作目录
appendonly yes
#AOF持久化模式打开
[root@c1 ~]# /etc/init.d/redis_6379 restart
主机2
[root@c2 ~]# systemctl stop firewalld
[root@c2 ~]# setenforce 0
[root@c2 ~]# vim /etc/redis/6379.conf
bind 0.0.0.0
#70行,所有网段都可以通信
daemonize yes
#137行,守护进程打开
dir /vr/lib/redis/6379
#264行,日志文件要打开
replicaof 192.168.233.66 6379
#在288行,开启后从节点将成为只读模式,指向主的ip,6379是主的端口号
appendonly yes
#AOF同步要打开
[root@c2 ~]# /etc/init.d/redis_6379 restart
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
主机3
[root@c3 ~]# systemctl stop firewalld
[root@c3 ~]# setenforce 0
[root@c3 ~]# vim /etc/redis/6379.conf
bind 0.0.0.0
#70行
daemonize yes
#288行,后台同步打开
replicaof 192.168.233.66 6379
#288行,打开
appendonly yes
#700行,打开
[root@c3 ~]# /etc/init.d/redis_6379 restart
Stopping ...
Redis stopped
Starting Redis server...
#如果要确定是否配置成功可以查看一下日志
主机1
[root@c1 ~]# tail -f /var/log/redis_6379.log
4928:M 22 Nov 2023 23:14:28.212 * Synchronization with replica 192.168.233.67:6379 succeeded
4928:M 22 Nov 2023 23:18:54.708 * Synchronization with replica 192.168.233.68:6379 succeeded
#表示已经配置且同步成功
#然后直接验证主从是否可以进行复制，从是否为只读且不能写入
哨兵模式
| 概念 | 先有主从复制再有哨兵模式，在主从复制的基础之上，从而实现主节点故障的自动切换 |
| 原理 | 哨兵模式是一个分布式系统,用于在主从结构之间，对每台redis的服务进行监控，主节点出现故障时，从节点通过投票的方式选择一个新的master，哨兵模式也需要至少三个节点 |
| 结构 | 哨兵节点：监控，不存储任何数据 数据节点：主节点和从节点都是数据节点 |
| 工作流程 | 每个哨兵节点之间每隔一秒,会通过ping命令方式，互相监控主从之间的节点心跳线，主节点在一定时间内没有回复或者回复了错误的消息，这个时候，哨兵就会主观的认为主节点下线了，而超过半数的哨兵节点认为主节点下线，则会被认为主节点客观下线，一旦被认为客观下线,哨兵节点会通过raft算法(选举算法)，每个节点共同投票选举出一个新的master，然后新的master实现主节点转义和故障恢复通知 |
| 主节点的选举过程 1.已经下线的从节点不会被选为主节点 2.选择配置文件当中，从节点优先级最高的replica-prioity 100 3.选择一个复制数据最完整的从节点 |
实验
主机1
[root@c1 ~]# vim /opt/redis-5.0.7/sentinel.conf
protected-mode no
#17行,取消注释,关闭保护模式
port 26379
#21行,哨兵模式的默认端口
daemonize yes
#26,指定哨兵模式是否后台运行改成也是
pidfile /var/run/redis-sentinel.pid
#31行,哨兵模式的进程文件
logfile "/var/log/sentinel.log"
#36行,指定他的日志文件的存放路径
dir "/var/lib/redis/6379"
#65行,指定它的数据库存放路径
sentinel monitor mymaster 192.168.233.66 6379 2
#84行,指定初始的主服务器,ip要指向主,6379为主的端口,2表示最少需要2台服务器认为主已经下线,才会进行主从切换,6台服务器就要3台或者4台
sentinel down-after-milliseconds mymaster 30000
#113行,判断服务器宕机的最小超时时间30000毫秒,也就是30秒内没有反应就会主观认为主服务器已下线
sentinel failover-timeout mymaster 180000
#146行,判断服务器宕机的最大超时时间180000毫秒,也就是180秒内没有反应,两台从节点就会共同投票主节点下线,进行主从切换
[root@c1 redis-5.0.7]# cd /opt/redis-5.0.7/
[root@c1 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 17695
主机2
[root@c2 redis-5.0.7]# vim /opt/redis-5.0.7/sentinel.conf
protected-mode no
#17行,取消注释保护模式关闭
daemonize yes
#26行,后台运行打开
logfile "/var/log/sentinel.log"
#36行,指定日志文件路径
dir /var/lib/redis/6379
#65行,指定数据库的工作目录
sentinel monitor mymaster 192.168.233.66 6379 2
#84行,指向原主服务器ip
#最小超时时间与最大超时时间需要打开113行最小,146行最大
[root@c2 opt]# cd /opt/redis-5.0.7/
[root@c2 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 57998
主机3
[root@c3 ~]# vim /opt/redis-5.0.7/sentinel.conf
protected-mode no
#17行,取消注释保护模式关闭
daemonize yes
#26行,后台运行打开
logfile "/var/log/sentinel.log"
#36行,指定日志文件路径
dir /var/lib/redis/6379
#65行,指定数据库的工作目录
sentinel monitor mymaster 192.168.233.66 6379 2
#84行,指向原主服务器ip
#最小超时时间与最大超时时间需要打开113行最小,146行最大
[root@c3 redis-5.0.7]# redis-sentinel sentinel.conf &
[1] 48920
主机1
[root@c1 redis-5.0.7]# redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.233.66:6379,slaves=2,sentinels=2
#表示为主服务器,ip为66,有两个从服务器,2台机器(一主两从应该是3)
[root@c1 redis-5.0.7]# tail -f /var/log/sentinel.log
#看从节点的信息，ID is cf399f2635f3f5004a61346698b524701afbbb67 id等于ip地址
#之后就可以验证主从复制与故障切换,可能会有延迟
