redis的性能管理及集群架构（主从复制、哨兵模式）

一、redis的性能管理

1、内存指标info memory

内存指标（重要）
used_memory:853736	数据占用的内存
used_memory_rss:10551296	redis向操作系统申请的内存
used_memory_peak:853736	redis使用内存的峰值
注：单位：字节

系统巡检：硬件巡检、数据库、中间件（nginx、redis）、docker、k8s

2、内存碎片率

（1）定义：系统已分配给redis，但reids未能有效利用的内存

（2）计算格式：内存碎片率=used_memory_rss/used_memory

（3）监控指标redis-cli info memory|grep ratio（生产环境常用）

监控指标		定义
allocator_frag_ratio:1.29	分配器碎片的比例 （越小越好，值越高，内存浪费越多）	redis主进程调度时产生的内存
allocator_rss_ratio:5.49	分配器占用物理内存的比例	主进程调度时占用的物理内存
rss_overhead_ratio:1.38	redis占用物理空间额外的开销比例（比例越低越好，redis实际占用的物理内存和向系统申请的内存越接近，额外的开销越低）	RSS是redis向系统申请的内存空间
mem_fragmentation_ratio:15.59	内存碎片率 （越低越好，内存使用率越高）

3、清理内存的两种方式

（1）自动清理碎片vim /etc/redis/6379.conf

末尾添加activedefrag yes自动清理碎片的配置

（2）手动清理碎片redis-cli memory purge

4、设置redis的最大内存阀值

（在工作中一定要设置redis的占用内存阈值。若不设置阈值，会塞满内存，直到炸）

（1）先设置最大内存阀值vim /etc/redis/6379.conf

添加maxmemory 1gb

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

（2）再开启key的回收机制

key的回收机制
maxmemory-policy volatile-lru （常用）	使用redis内置的lru算法，在已设置过期时间的键值对中淘汰数据中，移除最近最少使用的键值对
maxmemory-policy volatile-ttl （常用）	使用redis内置的ttl算法，在已设置过期时间的键值对中挑选一个即将过期的键值对
maxmemory-policy volatile-random （少用）	在已设置过期时间的键值对中，挑选数据，随机淘汰键值对
注：以上算法只针对已设置过期时间的键值对，永不过期的不在此范围内
allkeys-lru	使用redis内置的lru算法，对所有的键值对进行淘汰，移除最少使用的键值对
allkeys-random （更少用）	在所有键值对中任意选择数据进行淘汰
注：以上算法针对所有的键值对，无论是否设置过期时间
maxmemory-policy noeviction （最常用）	禁止键值对回收（不删除任何键值对，直到redis把内存塞满，写满报错为止）

【面试题】redis占用内存的效率问题如何解决？（经验）

①日常巡检中，监控redis的占用情况

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

③手动/自动清理内存碎片

④配置合适的key回收机制

5、redis雪崩（缓存雪崩）（少见）

（1）定义

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

（2）产生雪崩的原因

①redis集群大面积故障

②在redis缓存中，大量数据同时过期，大量的请求无法得到处理

③redis实例宕机

（3）解决雪崩的方式

①事前预防：采用高可用架构（主从复制、哨兵模式、redis集群），防止整个缓存故障

②事中处理（开发）：在国内通用方式——HySTRIX（熔断、降级、限流），降低雪崩发生后的损失，确保数据库不死，可以慢，但不能没有响应

③事后解决：以redis备份的方式恢复数据（运维）或快速缓存预热（开发）

6、redis的缓存击穿（重点）

（1）产生原因

①热点数据缓存过期或被删除，当多个请求并发访问热点数据时，请求转发到数据库，导致数据库性能快速下降。经常被请求的缓存数据最好设置为永不过期

②键值对还在，但值被替换，原有的请求找不到之后，同样会请求后台数据库，导致数据库性能快速下降

（2）解决方式

①热点数据设置成永不过期

②恢复原有的值

7、redis的缓存穿透（恶意攻击）（很少见）

（1）定义

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

（2）解决方式：专门的安全人员处理

二、redis的集群架构

1、高可用方案

（1）主从复制

（2）哨兵模式

（3）redis集群

2、主从复制

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

（2）主从复制实现数据的多机备份和读写分离（主服务器——写，从服务器——读）

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

3、主从复制的工作原理

由主节点master和从节点slave组成，数据复制是单向的，只能从主节点到从节点

4、哨兵模式

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

（1）哨兵模式定义

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

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

（2）哨兵模式的结构

①哨兵节点：监控主、从节点，不存储数据

②数据节点：主节点和从节点，都是数据节点

（哨兵1监控从1，从2节点；哨兵2监控主节点，从2 节点；哨兵3监控主节点，从1节点）

（2）哨兵模式工作原理

每个哨兵节点每隔一秒，通过ping命令方式，检测主、从之间的心跳线，主节点在一定时间内没有回复或回复了错误消息，这个时候哨兵会主观认为主节点下线了；超过半数的哨兵节点认为主节点下线了，这个时候才会认为主节点是客观下线

故障恢复可能会有延迟，因为有一个选举过程

（4）如何选举新的主节点

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

（5）主节点的选举过程

①已下线的从节点不会被选为主节点

②选择配置文件中从节点优先级最高的replica-priority 100

③自动选择一个复制数据最完整的从节点

三、主从复制+哨兵模式实验

基于主从复制做哨兵模式实验

实验目的：解决redis单节点故障问题

实验条件：

IP地址	作用	组件
20.0.0.14	主服务器	redis服务
20.0.0.24	从服务器1	redis服务
20.0.0.34	从服务器2	redis服务

实验步骤：

1、主从复制实验

（1）配置主服务器

（2）配置从服务器

从1

从2

replicaof 20.0.0.14 6379表示只读（20.0.0.14是主服务器的IP地址）

主从复制完成

（3）测试

2、哨兵模式实验

（1）配置主服务器

这个2：一般设置成集群的一半

最小切换时间30秒

最大切换时间180秒

（2）配置从服务器

从1

从2（与从1同样的配置）

（3）启动主从服务器（先启动主再启动从）

redis-sentinel sentinel.conf &

监控哨兵集群的信息redis-cli -p 26379 info Sentinel

哨兵模式搭建完毕

查看从节点信息tail -f /var/log/sentinel.log

（4）故障切换

模拟故障

看日志是否主从切换，有延迟

tail -f /var/log/sentinel.log

目前，新主的IP地址是20.0.0.34

（5）测试

①测试新主能不能写

能

恢复原主

②测试原主能否继续写

不能

原因：配置文件/etc/redis/6379.conf发生变化

原主（现从2）

从1

原从2（新主）