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占用内存的效率问题，如何解决

1. 日常巡检当中，对Redis的占用情况监控
2. 设置Redis占用系统的阀值，避免占用系统的全部内存
3. 内存碎片清理，手动，自动
4. 配置合适的key回收机制

Redis的故障报错问题：

Redis雪崩：

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

雪崩出现的原因：

Redis集群大面积故障

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

Redis实例宕机

解决雪崩方法：

事前：高可用架构，防止整个缓存故障，主从复制和哨兵模式，Redis集群

事中：在国内用的比较多的方式：HySTRIX，熔断，降级，限流用这三个手段来降低雪崩发生之后的损失，数据库不急即可，但是很慢，不能没有反应，类似于春运期间的12306

事后：Redis备份，快速缓存预热

Redis的缓存击穿：

缓存击穿主要是热点数据缓存过期，或者被删除，多个请求并发访问热点数据，请求也是转发到数据库了，导致数据库的性能下降，经常被请求的缓存数据，最好设置为永不过期

键值对还在，但是值被替换了，原有的请求找不到之后，同时也会请求后台数据库，也是击穿类型的一种

Redis的缓存穿透：

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

Redis的集群：

高可用方案：

1. 持久化
2. 高可用 主从复制 哨兵模式 集群

主从复制：

主从复制是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

启动哨兵

查看整个集群的哨兵情况

查看日志

模拟故障切换（有延时），当再次改完配置文件还是无法启动，记得杀一下进程

关闭服务

看日志看主从情况，哨兵情况

哨兵模式投票选举出新的主之后，原主配置文件自动修改，自动指向新的祝

新的主配置文件，也会修改，原本的从指向消失