redis的高可用（主从复制和哨兵模式）
redis的性能管理：redis的数据缓存在内存当中
INFO memory：查看redis内存使用情况
used_memory:1800800：redis中数据占用的内存
used_memory_rss:5783552：redis向操作系统申请的内存
used_memory_peak:1800800：redis使用内存的峰值
系统巡检：硬件巡检，数据库，nginx，redis，docker，k8s
redis-cli info memory | grep ratio：过滤内存碎片
内存碎片率：used_memory_rss/used_memory
系统已经分配给了redis，但是redis未能够有效利用的内存
allocator_frag ratio:1.19
分配器碎片的比例，redis主进程调度时产生的内存,比例越小越好，值越高，内存的浪费越多
allocator_rss_ratio:7.15
分配器占用物理内存的比例，告诉你主进程调度执行时占用了多少物理内存
rss_overhead_ratio:0.31
RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例，比例越低越好，redis实际占用的物理内存和向系统申请的内存越接近，额外的开销就越低
mem_fragmentation_ratio:3.33
内存碎片的比例，越低越好，内存的使用率越高
碎片可以自动清理（手动清理redis-cli memory purge和自动清理在配置文件redis最后一行添加activedefrag yes）
设置redis的最大内存阀值：（在/etc/redis/6379.conf中568行maxmemory 1gb）
一旦到达阀值，自动清理碎片，开启key的回收机制
key回收的策略：（要先设置上面的阀值）
配置文件redis/5379.conf，598行增加
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占用的内存的效率问题如何解决？
1、日常巡检当中，对redis的占用情况做监控
2、设置redis占用系统内存的阀值（在/etc/redis/6379.conf中568行maxmemory 1gb），避免占用系统全部内存
3、内存碎片清理（手动清理redis-cli memory purge和自动清理在配置文件redis最后一行添加activedefrag yes）
4、设置合适的key回收机制
maxmemory-policy noeviction：禁止键值对回收（不擅长任何键值对，直到redis把内存塞满，写不了，报错为止）
maxmemory-policy volatile-lru：使用redis内置的LRU算法，把已经设置了过期时间的键值对中淘汰数据，移除最近最少使用键值对（针对已经设置了过期时间的键值对）
redis雪崩（缓存雪崩）：
大量的应用请求无法在redis缓存当中处理，请求会全部发送到后台数据库，数据库并发能力本身就差。一旦高并发，数据库会很快崩溃
redis集群大面积故障
redis缓存中，大量数据同时过期，大量的请求无法得到处理
redis实例宕机
解决方案：
事前：采用高可用架构，防止整个缓存故障。主从复制和哨兵模式 redis集群
事中：在国内用的比较多哥方式：HYSTRIX，熔断，降级，限流三个手段来降低雪崩发生之后的损失。
数据库不死即可，慢可以，但是不能没有响应
事后：redis备份，快速缓存预热
redis的缓存击穿：
缓存击穿主要是热点数据缓存过期，或者被删除，多个请求并发访问数据，请求也是转发到数据库了，导致数据库的性能快速下降
经常被请求的缓存数据，最好设置为永不过期
redis的缓存穿透：
缓存中没有数据，数据库也没有对应数据，但是有用户一直在发起这个都没有的请求，而且请求的数据格式很大
一般这种情况就是黑客利用漏洞进行攻击，压垮应用数据库
redis的集群：
1、持久化
2、高可用 主从复制 哨兵模式 集群
主从复制：主从复制是redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础之上实现高可用
主从复制实现数据的多机备份，以及读写分离（主服务器负责写，从服务器只能读）
缺陷：故障无法自动恢复，需要人工干预，无法实现写操作的负载均衡
主从复制的工作原理：
- 主节点（master）从节点（slave）组成，数据复制是单向的，只能从主节点到从节点
主从复制的实验：
（主）打开配置文件：vim /etc/redis/6379.conf
70行 IP地址改为0.0.0.0，让所有的主机都可以使用
137行 daemonize yes打开
700行 appendonly no打开变成yes
重启配置文件：/etc/init.d/redis_6379 restart
（从）打开配置文件：vim /etc/redis/6379.conf
70行 IP地址改为0.0.0.0，让所有的主机都可以使用
137行 daemonize yes打开
288行添加一行replicaof 192.168.233.11 6379
700行 appendonly no打开变成yes
哨兵模式：先有主从再有哨兵
在主从复制的基础之上，实现主节点故障的自动切换
哨兵模式的原理：
哨兵：分布式系统，用于在主从结构之间，对每台redis的服务进行监控
主节点出现故障时，从节点通过投票的方式选择一个新的master
哨兵模式也需要至少三个节点
哨兵模式的结构：
哨兵节点：监控，不存储数据
数据节点：主节点和从节点，都是数据节点
主：192.168.233.11
从：192.168.233.12
从：192.168.233.13
哨兵模式的实验：
（主）cd /opt/
cd redis-5.0.7/
vim sentinel.conf
17行注释取消掉protected-mode no
26行daemonize no改成yes
36行logfile "/var/log/sentinel.log"
65行dir "/var/lib/redis/6379"
84行sentinel monitor mymaster 192.168.233.11 6379 2
启动配置文件redis-sentinel sentinel.conf &
redis-cli -p 26379 info Sentinel
ps -elf | grep redis
（从）cd /opt/
cd redis-5.0.7/
vim sentinel.conf
17行注释掉protected-mode no
26行 daemonize no改为yes
36行logfile "/var/log/sentinel.log"
65行dir "/var/lib/redis/6379"
84行sentinel monitor mymaster 192.168.233.11 6379 2
启动配置文件redis-sentinel sentinel.conf &
