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