redis的性能管理: redis的数据缓存在内存当中
root@10 \~\]# ****redis-cli -h 192.168.233.10 -p 6379**** 192.168.233.10:6379\>****info memory**** （几个比较重要的指标） used_memory:853592 redis中数据占用的内存 used_memory_rss:17342464 redis向操作系统申请的内存 used_memory_peak:853592 redis使用内存的峰值 系统巡检: 硬件巡检，数据库 nginx redis docker k8s 内存碎片率：used_memory_rss/used_memory=内存碎片率 系统已经分配给了redis，但是redis未能够有效利用的内存 \[root@10 \~\]#****redis-cli info memory \| grep ratio**** ****allocator_frag_ratio:1.33**** ----- 分配器碎片的比例。redis主进程调度时产生的内存。这个比例越小越好（这里是1.33%），数值越大，说明内存的浪费越多 ****allocator_rss_ratio:4.43**** ----- 分配器占用物理内存的比例。主进程调度执行时占用了多少物理内存 ****rss_overhead_ratio:2.04**** ----- redis占用物理课件额外的开销比例。该比例越低越好，redis实际占用的物理内存和向系统申请的内存越接近，额外的开销越低 ****mem_fragmentation_ratio:17.76**** ----- 内存碎片的比例。该比例越低越好。比例越低，内存的使用率越高 自动清理碎片 \[root@10 \~\]#****vim /etc/redis/6379.conf**** ****G**** ****o**** ****activedefrag yes**** ****:wq!**** ****\[root@10 \~\]# /etc/init.d/redis_6379 restart**** 手动清理碎片 \[root@10 \~\]#****redis-cli memory purge**** 设置redis的最大内存阀值 旦到达阀值，自动清理碎片，开启kev的回收机制 \[root@10 \~\]#****vim /etc/redis/6379.conf**** ****567gg**** ****o**** ****maxmemory 1gb**** ****599gg**** ****o**** ****maxmemory-policy volatile-lru**** ****maxmemory-policy volatile-ttl**** ****maxmemory-policy volatile-random**** ****:wq!**** 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占用内存设置阀值 ****Q：redis占用内存的效率问题如何解决？**** ****A：1、日常巡检当中，对redis的占用情况做监控**** ****2、设置redis占用系统的阀值，避免占用系统全部内存**** ****3、内存碎片清理，手动\&自动**** ****4、配置合适的key回收机制**** ****redis故障**** ****1、redis雪崩（缓存雪崩）**** ****大量的应用请求无法在redis缓存中处理，请求会全部发送到后台数据库，数据库并发能力本身就很差，一旦高并发，数据库会很快崩溃**** ****发生原因：①redis集群人面积故障；②redis缓存中，大量数据同时过期，大量的请求无法得到处理；③redis实例岩机；④恶意删除flushall**** ****解决方案：①事前防护：高可用架构，防止整个缓存故障。主从复制和哨兵模式和redis集群；②事中：（主要是开发干）在国内用的较多的方式：HySTRIX，熔断、降级、限流三个手段用来降低雪崩的损失。数据库不死即可，慢可以，但是不能没有响应；③事后：redis备份、快速缓存预热**** ****2、redis缓存击穿【⭐】**** ****缓存击穿主要是热点数据缓存过期或者被删除。多个请求并发访问热点数据，请求也是转发到数据库了，导致数据库的性能快速下降。**** ****经常被请求的缓存数据最好设置为永不过期**** ****解决方法：**** ****经常被请求的缓存数据设置为永不过期**** ****3、redis的缓存穿透**** ****缓存中和数据库里都没有数据，但是有用户一直在发起都没有的请求，而且请求的数据格式还很大，一般是黑客利用漏洞进行攻击，压垮应用数据库**** redis的集群 高可用的方案 1、持久化 2、高可用 ----- 主从复制、哨兵模式、集群 主从复制是redis实现高可用的基础。哨兵模式和集群都是在主从复制的基础上实现高可用的 主从复制实现数据的多机备份以及数据的读写分离（主服务器负责写，从服务器只能读）。缺陷是故障无法自动恢复，需要人工干预，写操作的负载均衡 主从复制的工作原理 1、主节点master和从节点slave组成。数据复制是单向的。只能从主节点到从节点  **主从复制实验** 192.168.233.20 主 192.168.233.20 从1 192.168.233.30 从2         哨兵模式实验 现有主从，再有主从复制。在主从复制基础之上，实现主节点故障的自动切换 哨兵模式的原理 哨兵：是一个分布式系统，用于在主从结构之间对每台redis的服务进行监控。 主节点出现故障时，从节点通过投票的方式选择新的master 哨兵模式也需要至少三个节点 哨兵模式的结构： 1、哨兵节点 监控，不存储任何数据 2、数据节点 主节点和从节点都是数据节点 工作机制 每个哨兵节点每隔一秒，通过ping命令的方式检测主从之间的心跳线。如果主节点在一定时间内没有回复，或者回复了一个错误的信息，这个时候哨兵会主观的认为主节点下线了，超过半数的哨兵节点认为主节点下线了，这个时候才会认为主节点是客观下线  哨兵节点通过raft算法(选举算法)，每个节点共同投票选举出一个新的master,然后新的master实现主节点转移和故障恢复通知 主节点的选举过程 1、已经下线的从节点不会被选为主节点 2、选择配置文件中从节点优先级最高的 replica-priority 100 3、自动选择复制数据最完整那个从节点 sentinel monitor mymaster 192.168.233.10 6379 2 2表示至少需要2台服务器认为主已经下线，才会进行主从切换 小模式用哨兵，大模式用集群 此时主机从10转换成30      