redis 高可用

redis 的性能管理：redis的数据缓存在内存当中。

查看redis性能指标：info memory

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-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

内存碎片的比例，越低越好，内存的使用率越高。

如何清理碎片

手动：redis-cli memory purge

自动：

vim /etc/redis/6379 . conf

在最后一行插入

activedefrag yes

设置redis的最大内存阈值（设置多少看需求）：

一旦到达阈值，自动清理碎片，开启key的回收机制。

key回收机制：不用随机清理的方法

maxmemory-policy volatile-lru: 使用redis内置的LR算法，把已经设置了过期时间的键值对中淘汰数据，一次最近最少使用键值对（针对已经设置了过期时间的键值对）

maxmemory-policy volatile-ttI : 已经设置了过期时间的键值对，从当中挑选一个即将过期的键值对（针对有设置时间的键值对）

maxmemory-policy volatile-random:从已经设置了过期时间的键值对当中，挑选数据随机淘汰键值对。（对设置了过期时间的键值对进行随机淘汰，不怎么用）

allkeys-lru：LRU算法当中，对所有的键值对进行淘汰，移除最少使用的键值对。（针对所有的键值对）

allkeys-random：对所有键值对随机选择淘汰。不用

maxmemory-policy noeviction : 禁止键值对回收（不删除任何键值对，直到redis把内存塞满，写不了，报错为止）

在工作中，一定要给redis占用内存设置阈值

面试题：你在工作中如果redis占用内存满了，效率问题如何解决：

1，日常巡检当中，对redis的占用情况做监控

2，设置redis占用系统内存的阈值，避免占用系统全部内存

3，内存碎片清理，手动 自动。

4，配置合适的key回收机制。

redis的雪崩：

缓存雪崩：大量的应用请求无法在redis缓存当中处理，请求会全部发送到后台数据库，数据库并发能力本身就很差。大量的读写的压力就会激增，一旦高并发，数据库很快崩溃

redis集群大面积故障

redis缓存中，大量随机提升过期，大量的请求无法得到处理

redis实时宕机。

解决方案：

事前：高可用架构，防止整个缓存故障。主从复制和哨兵面试 redis集群。

事中：在国内用的比较多的方式：HySTRIX，熔断，降级，限流三个手段来降低雪崩发生之后的损失。数据库不死即可，慢，但有响应。

事后，redis备份。快速缓存预热。

redis的缓存击穿：面试可能问

缓存击穿主要是热点数据的缓存过期，或者被删除，多个请求并发访问热点事件，请求也是转发到了数据库了，导致数据库的性能快速下降。

经常被请求的缓存数据，最好设置为永不过期。

键值对还在，但是值被替换了，原有的请求找不到了，同样也回去请求后台数据库。数据恢复即可。

redis的缓存穿透：

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

redis的集群：

高可用方案

1，持久化

2，高可用 主从复制 哨兵模式 集群

主从复制：是redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础之上实现高可用。

主从复制实现数据的多机备份，以及读写分离（主服务器负责写，从服务器只能读）。

缺陷：故障无法自动恢复，需要人工干预，写操作的负载均衡。

主从复制的工作原理：

1，主节点（master）从节点（slave）组成，数据复制是单项的，只能从主节点到从节点

关闭防火墙：

systemctl stop firewalld

setenforce 0

vim /etc/redis/6379.conf

主：

修改监听地址

bind 0.0.0.0

打开aof同步

appendonly yes

/etc/init.d/redis_6379 restart 重启

从：

bind 0.0.0.0

配置指向主的IP地址和端口

288 行

replicaof 192.168.176.71 6379

700行 打开aof同步

appendonly yes

/etc/init.d/redis_6379 restart 重启

验证主从模式：

从不能写

为了应对主挂了之后，应用了哨兵模式，

先有主从再有哨兵

再主从复制的基础之上，实现主节点故障的自动切换。

哨兵模式的原理：

哨兵：是一个分布式系统，用于再主从结构之间，对每台redis的服务进行监控。

主节点出现故障时，从节点通过投票的方式选择一个新的master

哨兵模式也需要至少三个节点。

哨兵模式的结构：

哨兵节点：监控，不存储数据

数据节点：阿虎节点和从节点的都是数据节点

哨兵模式的原理：

每个设备节点每隔一秒，通过平目录方式，检测主从之间的心跳线。主节点在一定时间内没有回复，或者回复了一个错误信息，哨兵就会主观的认为主节点下线的，只有超过半数的哨兵阶段的认为主节点下线了，这个时候才会认为主节点是客观下线。

哨兵节点如何切换

哨兵节点会通过raft算法（选举算法）每个节点都会投票，共同投票，选举出一个新的master，然后新的master实现主节点转移和故障恢复通知。

主节点的选举过程：

1，已经下线的主节点，不会选为主节点

2，会选择配置文件当中，从节点优先级最高的replica-priority （默认都是100 所以不推荐）

3，选择一个复制数据最完整的从节点

哨兵监控的是节点心跳线：

故障恢复需要时间。

依据的是源码包

vim sentinel.conf

关闭默认模式

protected-mode no

哨兵模式的默认端口

port 26379

指定哨兵模式后台运行

daemonize yes

指定日志文件存放路径

logfile "/var/log/sentinel.log"

数据库存放的目录

dir "/var/lib/redis/6379"

指定初始主服务器

sentinel monitor mymaster 192.168.176.71 6379 2

原始主

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

30秒之内没有进行响应，主观认为主挂了

sentinel down-after-milliseconds mymaster 30000

180内所有的都认为主挂了切换

sentinel failover-timeout mymaster 180000

启动哨兵（先启主，在起从）

redis-sentinel sentinel.conf &

查看整个集群的哨兵模式情况

redis-cli -p 26379 info Sentinel

查看哨兵日志

tail -f /var/log/sentinel.log

模拟故障切换：

/etc/init.d/redis_6379 stop

查看端口：

ps -elf | grep redis

打开日志查看切换

tail -f /var/log/sentinel.log

主以自动切换。