（一）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）故障恢复