• redis的性能管理和雪崩

    redis的性能管理

    redis的数据是缓存在内存当中的

    系统巡检：

    硬件巡检、数据库、nginx、redis、docker、k8s

    运维人员必须要关注的redis指标

    在日常巡检中需要经常查看这些指标使用情况

    1. info memory
    2. #查看redis使用内存的指标
    3. used_memory:11285512
    4. #数据占用的内存（单位是字节）
    5. used_memory_rss:24285184
    6. #向操作系统申请的内存（单位是字节）
    7. used_memory_peak:23952088
    8. #redis使用内存的峰值（单位是字节）
    9.  
    10. 内存碎片率：used_mem0ry_rss/used_memory
    11. #系统已经分配给了redis，但是未能够有效利用的内存

    如何查看内存碎片率？

    1. 内存碎片率：used_mem0ry_rss/used_memory
    2. #系统已经分配给了redis，但是未能够有效利用的内存
    3.  
    4. redis-cli info memory | grep ratio
    5. #查看内存碎片率
    6.  
    7. allocator_frag_ratio:1.03
    8. #分配器碎片比例。由redis主进程调度时产生的内存，比例越小越好，值越高，内存浪费越多。
    9. allocator_rss_ratio:1.80
    10. #表示分配器占用物理内存的比例，主进程调度过程中占用了多少物理内存
    11. rss_overhead_ratio:1.13
    12. #RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
    13. mem_fragmentation_ratio:2.16
    14. #内存碎片的比例。值越低越好。表示内存的使用率越高

    如何来进行清理碎片？

    1. 自动清理碎片
    2. vim /etc/redis/6379.conf
    3. 最后一行插入
    4. activedefrag yes
    5. #自动清理碎片
    6. /etc/init.d/redis_6379.conf restart
    7. #重启redis服务
    8.  
    9. 手动清理碎片
    10. redis-cli memory purge
    11. #手动清理碎片

    设置redis的最大内存阈值

    1. vim /etc/redis/6379.conf
    2. 567行
    3. maxmemory 1gb
    4. #一旦到达阈值会开始自动清理，开启key的回收机制

    key的回收机制是什么？

    就是回收键值对

    key回收的策略

    1. vim /etc/redis/6379.conf
    2.  
    3. 598行
    4. maxmemory-policy volatile-lru
    5. #使用redis内置的LRU算法。把已经设置了过期时间的键值对淘汰出去。移除最近最少使用的键值对（只是针对已经设置了过期时间的键值对）
    6.  
    7. maxmemory-policy volatile-ttl
    8. #在已经设置了过期时间的键值对中，挑选一个即将过期的键值对（针对的是有设置生命周期的键值对）。
    9.  
    10. maxmemory-policy volatile-random
    11. #在已经设置了过期时间的键值对中，挑选数据然后随机淘汰一个键值对（对设置了过期时间的键值对进行随机移除）
    12.  
    13. allkeys-lru
    14. #根据redis内置的lru算法，对所有的键值对进行淘汰。移除最少使用的键值对。（针对所有的键值对）
    15.  
    16. allkeys-random
    17. #在所有键值对中，任意选择数据进行淘汰
    18.  
    19. maxmemory-policy noeviction
    20. #禁止对键值对回收（不删除任何键值对，知道redis把内存塞满，写不下，报错为止）

    工作用要么保证数据完整性使用maxmemory-policy noeviction 要么使用maxmemory-policy volatile-ttl挑选一个即将过期的键值对清除

    在工作当中一定要给redis占用内存设置阈值否则会将整个系统内存占满为止

    redis的雪崩

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

    什么情况可能会导致雪崩出现？

    1、 redis集群大面积故障

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

    3、 redis实例宕机

    防止雪崩出现的方法

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

    事中：在国内用得较多的方式：HySTRIX有三种方式：熔断、降级、限流。可以使用这三个手段来降低雪崩发生之后的损失。确保数据库不死即可，慢可以，但是不能没有响应。

    事后：redis数据备份的方式来恢复数据或使用快速缓存预热的方式

    redis的缓存击穿

    缓存击穿主要是热点数据缓存过期或者被删除，多个请求并发访问热点数据。请求也是转发到后台数据库了，导致数据库的性能快速下降。

    经常被请求的缓存数据最好设置为永不过期

    redis缓存穿透

    缓存中没有数据，数据库中也没有对应数据，但是有用户一直发起这个没有的请求，而且请求的数据格式很大。

    可能是黑客在利用漏洞攻击，压垮应用数据库。

    redis的集群架构

    高可用方案：

    1、 持久化

    2、 高可用：主从复制、哨兵模式、集群

    主从复制

    主从复制是redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础上实现高可用。

    主从复制实现数据的多机备份，以及读写分离（主服务器负责写，从服务器只能读）

    缺陷：故障无法自动恢复，需要人工干预。无法实现写操作的负载均衡

    主从复制的工作原理

    1、 主节点（master）和从节点（slave）组成。数据的复制时单项的，只能从主节点到从节点。

    主从复制节点最少要有三台

    主从复制的数据流向和工作流程图：

    1、 从与主建立连接。从会发送一个syn command，请求和主建立连接

    2、 主节点收到请求之后，不管slave是第一次连接还是重新连接。主节点都会启动一个后台进程。执行BGsave。

    3、 主节点会把所有修改数据记录的命令也加载到缓存和数据文件之中。

    4、 数据文件创建完毕之后，是由主系欸但把数据文件传送给从节点，从节点会把数据文件保存到硬盘当中后再加载到内存中去。

    主从复制推荐使用AOF，通过AOF文件实现实时持久化，主从节点都开启AOF持久化服务。从节点同步的就是aof文件。

    主从复制工作流程图：

    主从复制实验

    1. 实验准备：
    2. 20.0.0.26  master
    3. 20.0.0.27  slave1
    4. 20.0.0.28  slave2
    5. 三台机器都需要安装redis服务
    6.  
    7. 做完后拍个快照
    8.  
    9. systemctl stop firewalld
    10. setenforce 0
    11. #关闭三台机器的防火墙和安全机制
    12.  
    13. 主节点：
    14. vim /etc/redis/6379.conf
    15. 修改网段 0.0.0.0
    16. daemonize yes
    17. 700行
    18. 开启aof模式
    19. /etc/init.d/redis_6379 restart
    20.  
    21. 从节点1：
    22. vim /etc/redis/6379.conf
    23. 修改网段 0.0.0.0
    24. 288行
    25. replicaof  
    26. replicaof 20.0.0.26 6379
    27. #指向主的ip和端口
    28. 700行
    29. 开启aof模式
    30. /etc/init.d/redis_6379 restart
    31. 开启了指向后从节点将变为只读模式
    32.  
    33. 从节点2：
    34. vim /etc/redis/6379.conf
    35. 修改网段 0.0.0.0
    36. 288行
    37. replicaof  
    38. replicaof 20.0.0.26 6379
    39. #指向主的ip和端口
    40. 700行
    41. 开启aof模式
    42. /etc/init.d/redis_6379 restart
    43. 开启了指向后从节点将变为只读模式
    44.  
    45. 主节点：
    46. tail -f /var/log/redis_6379.log
    47. #查看主节点日志，看是否指向成功
    48.  
    49. 验证效果：
    50. 主从都登录redis
    51. 主节点：
    52. set test1 1
    53. #创建一个键值对
    54. 主上创建成功后到两台从节点查看一下看是否可以查看到
    55.  
    56. 从节点：
    57. set test2 2
    58. #在从节点上测试是否为只读模式
    59. 报错，说明搭建成功从节点已经设置为只读模式了
    60.  
    61. 实验完成！
    62.  
    63. redis-cli info replication
    64. #查看主从配置信息
    65.  
    66. 停止一个从节点来测试。停机期间插入的数据，服务重启后依旧可以同步

    哨兵模式

    哨兵模式依赖于主从模式，先有主从再有哨兵

    哨兵模式是在主从复制的基础上实现主节点故障的自动切换

    哨兵模式的工作原理

    哨兵：是一个分布式系统。部署在每一个redis节点上用于在主从结构之间对每台redis的服务进行监控。

    哨兵模式的投票机制

    主节点出现故障时，从节点通过投票的方式选择一个新的master

    哨兵模式也需要至少三个节点

    哨兵模式的结构

    哨兵节点和数据节点

    哨兵节点：监控，不存储数据

    数据节点：主节点和从节点，都是数据节点

    哨兵模式的工作机制

    哨兵模式的架构和工作机制图：

    哨兵1节点会对应监控从节点1和从节点2

    哨兵2节点会对应监控主节点和从节点2

    哨兵3节点会监控主节点和从节点1

    哨兵节点会互相监控架构内的其他节点主机

    哨兵模式的投票机制：

    1、 每个哨兵节点每隔1秒，通过ping命令的方式检测主从之间的心跳线。

    2、 当主节点在一定时间内没有回复或者回复了错误的信息。哨兵会主观的认为主节点下线了。

    3、 当有超过半数的哨兵节点认为主节点下线了，才会认为主节点是客观下线了

    主节点选举过程：

    哨兵节点会通过redis自带的raft算法(选举算法)，每个节点共同投票，选举出一个新的master。

    新的master来实现主节点的转移和故障恢复通知

    1、 已经下线的从节点，不会被选择为主节点

    2、 选择配置文件当中，从节点优先级最高的 replica-priority 100

    3、 选择一个复制数据最完整的从节点

    哨兵模式监控的是节点不是哨兵

    故障恢复可能会优点延迟

    最好是以复制数据最完整的从节点作为新的主节点

    哨兵模式实验

    1. 主节点：
    2. cd redis-5.0.7
    3. vim sentinel.conf
    4. #哨兵模式的配置文件
    5.  
    6. 17行
    7. protected-mode no
    8. #解除注释
    9.  
    10. daemonize yes
    11. #开启后台运行逃兵模式
    12.  
    13. 36行
    14. logfile "/var/log/sentinel.log"
    15. #指定日志文件的存放位置
    16.  
    17. 65行
    18. dir"/var/lib/redis/6379"
    19. #指定数据库存放的位置
    20.  
    21. 85行
    22. sentinel monitor mymaster 20.0.0.26 6379 2
    23. #声明主节点的IP和端口号.2代表至少要有2台服务认为主已经下线才会进行主从切换。一般配置为主从服务器的一半
    24.  
    25. 113行
    26. sentinel down-after-milliseconds mymaster 30000
    27. #服务器宕机的最小时间。单位是毫秒。30秒之内如果主节点但没有响应，主观认为主下线了。时间可以改可以自定义
    28.  
    29. 146行
    30. sentinel failover-timeout mymaster 180000
    31. #服务器宕机的最大时间，180秒之内如果主节点但没有响应，从节点开始投票，客观认为主下线了。时间可以改可以自定义
    32.  
    33. 两台从节点配置和主节点配置一致即可
    34.  
    35. 三台配置完成后需要先起主节点再起从节点
    36.  
    37. 三台主机在redis的源码包中启动哨兵模式
    38. redis-sentinel sentinel.conf &
    39. #启动哨兵模式。&表示后台运行
    40.  
    41. 主节点：
    42. redis-cli -p 26379 info Sentinel
    43. #查看整个集群的哨兵情况
    44.  
    45. 查看主从信息：
    46. tail -f /var/log/redis_6379.log
    47. #查看主节点日志，查看主从信息
    48.  
    49. 模拟故障切换：
    50. 可能会有延迟不是立刻切换
    51. ps-elf | grep redis
    52. #查看主节点
    53. kill -9 redis的主进程或者/etc/init.d/redis_6379 stop停止redis都可以测试
    54.  
    55. 测试新主是否可以正常插入数据
    56. 测试两从是否可以数据同步
    57. 测试旧主机是否还有插入数据
    58.  
    59. 旧主失去写的功能，新主增加写的功能。从2的配置文件指向了新的主
    60. 而旧主的配置文件中指向自己的配置将会消失

    小模式用哨兵，大模式用集群

    总结

    运维人员日常巡检中关注的指标

    1. #查看redis使用内存的指标
    2. used_memory:11285512
    3. #数据占用的内存（单位是字节）
    4. used_memory_rss:24285184
    5. #向操作系统申请的内存（单位是字节）
    6. used_memory_peak:23952088
    7. #redis使用内存的峰值（单位是字节）

    内存碎片：

    1. 内存碎片率：used_mem0ry_rss/used_memory
    2. #系统已经分配给了redis，但是未能够有效利用的内存
    3.  
    4. redis-cli info memory | grep ratio
    5. #查看内存碎片率
    6.  
    7. allocator_frag_ratio:1.03
    8. #分配器碎片比例。由redis主进程调度时产生的内存，比例越小越好，值越高，内存浪费越多。
    9. allocator_rss_ratio:1.80
    10. #表示分配器占用物理内存的比例，主进程调度过程中占用了多少物理内存
    11. rss_overhead_ratio:1.13
    12. #RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
    13. mem_fragmentation_ratio:2.16
    14. #内存碎片的比例。值越低越好。表示内存的使用率越高

    如何清理碎片：

    1. 自动清理碎片
    2. vim /etc/redis/6379.conf
    3. 最后一行插入
    4. activedefrag yes
    5. #自动清理碎片
    6. /etc/init.d/redis_6379.conf restart
    7. #重启redis服务
    8.  
    9. 手动清理碎片
    10. redis-cli memory purge
    11. #手动清理碎片

    如何设置阈值：

    1. vim /etc/redis/6379.conf567行maxmemory 1gb
    2. #一旦到达阈值会开始自动清理，开启key的回收机制

    工作用要么保证数据完整性使用maxmemory-policy noeviction 要么使用maxmemory-policy volatile-ttl挑选一个即将过期的键值对清除

    在工作当中一定要给redis占用内存设置阈值否则会将整个系统内存占满为止

    redis的缓存击穿：

    缓存击穿主要是热点数据缓存过期或者被删除，多个请求并发访问热点数据。请求也是转发到后台数据库了，导致数据库的性能快速下降。

    经常被请求的缓存数据最好设置为永不过期

    主从复制：

    主从复制是redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础上实现高可用。

    主从复制实现数据的多机备份，以及读写分离（主服务器负责写，从服务器只能读）

    缺陷：故障无法自动恢复，需要人工干预。无法实现写操作的负载均衡

    哨兵模式：

    哨兵模式监控的是节点不是哨兵

    故障恢复可能会优点延迟

    最好是以复制数据最完整的从节点作为新的主节点

    拓展

    运维人员必须要关注的redis指标：

    在日常巡检中需要经常查看这些指标使用情况

    1. info memory
    2. #查看redis使用内存的指标
    3. used_memory:11285512
    4. #数据占用的内存（单位是字节）
    5. used_memory_rss:24285184
    6. #向操作系统申请的内存（单位是字节）
    7. used_memory_peak:23952088
    8. #redis使用内存的峰值（单位是字节）

    如何查看内存碎片率？

    1. 内存碎片率：used_mem0ry_rss/used_memory
    2. #系统已经分配给了redis，但是未能够有效利用的内存
    3.  
    4. redis-cli info memory | grep ratio
    5. #查看内存碎片率
    6.  
    7. allocator_frag_ratio:1.03
    8. #分配器碎片比例。由redis主进程调度时产生的内存，比例越小越好，值越高，内存浪费越多。
    9. allocator_rss_ratio:1.80
    10. #表示分配器占用物理内存的比例，主进程调度过程中占用了多少物理内存
    11. rss_overhead_ratio:1.13
    12. #RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
    13. mem_fragmentation_ratio:2.16
    14. #内存碎片的比例。值越低越好。表示内存的使用率越高

    redis占用的内存效率问题如何解决？

    1、 日常巡检中，针对redis的占用情况做监控

    2、 给redis设置一个占用系统内存的阈值，避免占用系统的全部内容

    3、 内存碎片清理，分为手动和自动两种模式

    4、配置一个合适的key的回收机制。一般都是设置写满报错的方式（maxmemory-policy noeviction），通过运维人员手动维护。或者挑选一个即将过期的键值对清除（maxmemory-policy volatile-ttl）。

    redis的缓存击穿

    缓存击穿主要是热点数据缓存过期或者被删除，多个请求并发访问热点数据。请求也是转发到后台数据库了，导致数据库的性能快速下降。

    经常被请求的缓存数据最好设置为永不过期

  • 相关阅读:
    Linux内存管理（二十四）：slub 分配器之kmem_cache_free
    基于ssm疫情居家办公OA系统获取（java毕业设计）
    C++征途 --- deque容器
    HTML 入门
    关于正则的两道笔试面试题
    LCR 041.数据流中的移动平均值
    【自动化脚本】常用自动化脚本一览【持续更新】
    前端uniapp提交表单调用接口方法最新
    爬虫入门一
    区间内的真素数问题（C#）
  • 原文地址：https://blog.csdn.net/m0_75209491/article/details/134545400