Redis的性能管理：
Redis的数据缓存在内存当中
INFO memory
used_memory:853808
Redis中数据占用的内存
used_memory_rss:3715072
Redis向操作系统申请的内容
used_memory_peak:853808
Redis使用的内存的峰值
系统巡检：硬件巡检，数据库，Nginx，Redis,docker,k8s
内存碎片率：used_memory_rss/used_memory
系统已经分配给了Redis，但是Redis未能够有效利用的内存
allocator_frag_ratio:1.26
分配碎片的比例，Redis主进程调度时产生的内存，比例越小越好，值越高，内存的浪费越多
allocator_rss_ratio:6.02
分配占用物理内存的比例，告诉你主进程调度执行时占用了多少物理内存
rss_overhead_ratio:0.43
Rss是向系统申请的内存空间，Redis占用物理空间额外的开销比例，比例越低越好，Redis实际占用的内存和向系统申请的内存越接近，额外的开销越低
mem_fragmentation_ratio:4.69
内存碎片的比例，越低越好，内存的使用率越高
自动清理内存碎片：
vim /etc/redis/6379.conf
最后一行添加
activedefrag yes
手动碎片清理：
redis-cli memory purge
设置Redis的最大内存阀值：
vim /etc/redis/6379.conf
一旦达到设置的阀值，自动清理碎片，开启key的回收机制
Key回收的策略：
vim /etc/redis/6379.conf
599行添加：
maxmemory-policy volatile-lru：使用Redis内置lRU算法，把已经过期的键值对中淘汰数据，移除最近最少使用键值对（针对已经设置了过期时间的键值对）
maxmemory-policy volatile-ttl:已经设置了过期时间的键值对，从当中挑选一个即将过期的键值对（针对设置过期的键值对）
maxmemory-policy volatile-random：从已经设置了过期时间的键值对当中，挑选数据随机淘汰键值对（对设置了过期时间的键值对进行随机移除）
allkeys-lru:LRU算法当中，对所有的键值对进行淘汰，移除最少使用的键值对（针对所有的键值对）
allkeys-random:从所有键值对当中任意选择数据进行淘汰（没人用）
maxmemory-policy noeviction：禁止键值对回收，（不删除任何键值对，直到Redis把内存写满为止）
思考题：
Redis占用内存的效率问题，如何解决
- 日常巡检当中，对Redis的占用情况监控
- 设置Redis占用系统的阀值，避免占用系统的全部内存
- 内存碎片清理，手动，自动
- 配置合适的key回收机制
Redis的故障报错问题：
Redis雪崩：
缓存雪崩：大量的应用请求无法在Redis缓存当中处理，请求全部发送到后台数据库，数据库的并发能力本身就很差，一旦高并发，数据库就会很快崩溃
雪崩出现的原因：
Redis集群大面积故障
Redis缓存中，大量的数据同时过期，大量的请求无法得到处理
Redis实例宕机
解决雪崩方法：
事前：高可用架构，防止整个缓存故障，主从复制和哨兵模式，Redis集群
事中：在国内用的比较多的方式：HySTRIX，熔断，降级，限流用这三个手段来降低雪崩发生之后的损失，数据库不急即可，但是很慢，不能没有反应，类似于春运期间的12306
事后：Redis备份，快速缓存预热
Redis的缓存击穿：
缓存击穿主要是热点数据缓存过期，或者被删除，多个请求并发访问热点数据，请求也是转发到数据库了，导致数据库的性能下降，经常被请求的缓存数据，最好设置为永不过期
键值对还在，但是值被替换了，原有的请求找不到之后，同时也会请求后台数据库，也是击穿类型的一种
Redis的缓存穿透：
缓存当中没有数据，数据库当中也没有对应数据，但是有用户一直发起这个都没有的请求，而且请求的数据格式很大，黑客在利用漏洞在攻击，压垮应用数据库
Redis的集群：
高可用方案：
- 持久化
- 高可用 主从复制 哨兵模式 集群
主从复制：
主从复制是Redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础上实现高可用，主从复制实现数据的多机备份，以及读写分离（主服务器负责写，从服务器只能读）
缺陷：主从复制故障之后无法自动恢复，需要人工干预，写操作的负载均衡
主从复制的工作原理：
1.主节点（MAster）从节点（slave）组成，数据复制是单向的，只能从主节点到从节点
核心图：
实现主从复制：
20.0.0.51主
20.0.0.52 从1
20.0.0.53 从2
主：
vim /etc/redis/6379.conf
监听地址噶为0.0.0.0
然后
重启服务
从1
打开AOF
指向主：
从节点直接自动变成只读模式
然后
/etc/init.d/redis_6379 restart
从2
/etc/init.d/redis_6379 restart
验证效果，看日志
tail -f /var/log/redis_6379.log
主从复制搭建完成
三台Redis登录Redis验证效果
验证主从复制，
验证只读模式
Set失败，只有主节点可以写，从节点写失败
查看主从策略
redis-cli info replication
从策略查看
redis-cli info replication
当从1或从2停机一台服务，不影响主从复制功能，而且服务打开后，照样同步
哨兵模式：
先有主从，再有哨兵
在主从复制的基础上，实现主节点故障的自动切换
哨兵模式原理：
哨兵：是一个分布式系统，用于分布式系统，用于在主从结构之间，对每台Redis的服务器进行监控，主节点出现故障时，从节点通过投票的方式选择一个新的master
哨兵模式需要事少三个节点服务器
哨兵模式的结构：
哨兵节点：监控（监控的是Redis节点，不是监控哨兵），不存储数据
数据节点：主节点和从节点都是数据节点
核心图：
演示哨兵模式：
取消注释，取消保护模式
哨兵模式端口
哨兵模式后台运行
日志文件运行打开
指定工作目录
指定初识的主服务器
2表示至少需要两台服务器认为主已经下线，才会进行主从切换
最小时间限制，30秒后就认为已挂，主官认为已挂
最大时间限制
先启主节点，再起从节点，先器master，再起sentinel
启动哨兵
查看整个集群的哨兵情况
查看日志
模拟故障切换（有延时），当再次改完配置文件还是无法启动，记得杀一下进程
关闭服务
看日志看主从情况，哨兵情况
哨兵模式投票选举出新的主之后，原主配置文件自动修改，自动指向新的祝
新的主配置文件，也会修改，原本的从指向消失
