关于美术馆网站建设的方案,wordpress站内信群发,网站快速备案多少钱,青州网站建设推广redis的性能管理
redis的数据是缓存在内存当中的
系统巡检#xff1a;
硬件巡检、数据库、nginx、redis、docker、k8s
运维人员必须要关注的redis指标
在日常巡检中需要经常查看这些指标使用情况
info memory
#查看redis使用内存的指标
used_memory:11285512
#数据占用的…redis的性能管理
redis的数据是缓存在内存当中的
系统巡检
硬件巡检、数据库、nginx、redis、docker、k8s
运维人员必须要关注的redis指标
在日常巡检中需要经常查看这些指标使用情况
info memory
#查看redis使用内存的指标
used_memory:11285512
#数据占用的内存单位是字节
used_memory_rss:24285184
#向操作系统申请的内存单位是字节
used_memory_peak:23952088
#redis使用内存的峰值单位是字节内存碎片率used_mem0ry_rss/used_memory
#系统已经分配给了redis但是未能够有效利用的内存
如何查看内存碎片率
内存碎片率used_mem0ry_rss/used_memory
#系统已经分配给了redis但是未能够有效利用的内存redis-cli info memory | grep ratio
#查看内存碎片率allocator_frag_ratio:1.03
#分配器碎片比例。由redis主进程调度时产生的内存比例越小越好值越高内存浪费越多。
allocator_rss_ratio:1.80
#表示分配器占用物理内存的比例主进程调度过程中占用了多少物理内存
rss_overhead_ratio:1.13
#RSS是向系统申请的内存空间redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
mem_fragmentation_ratio:2.16
#内存碎片的比例。值越低越好。表示内存的使用率越高
如何来进行清理碎片
自动清理碎片
vim /etc/redis/6379.conf
最后一行插入
activedefrag yes
#自动清理碎片
/etc/init.d/redis_6379.conf restart
#重启redis服务手动清理碎片
redis-cli memory purge
#手动清理碎片
设置redis的最大内存阈值
vim /etc/redis/6379.conf
567行
maxmemory 1gb
#一旦到达阈值会开始自动清理开启key的回收机制
key的回收机制是什么
就是回收键值对
key回收的策略
vim /etc/redis/6379.conf598行
maxmemory-policy volatile-lru
#使用redis内置的LRU算法。把已经设置了过期时间的键值对淘汰出去。移除最近最少使用的键值对只是针对已经设置了过期时间的键值对maxmemory-policy volatile-ttl
#在已经设置了过期时间的键值对中挑选一个即将过期的键值对针对的是有设置生命周期的键值对。maxmemory-policy volatile-random
#在已经设置了过期时间的键值对中挑选数据然后随机淘汰一个键值对对设置了过期时间的键值对进行随机移除allkeys-lru
#根据redis内置的lru算法对所有的键值对进行淘汰。移除最少使用的键值对。针对所有的键值对allkeys-random
#在所有键值对中任意选择数据进行淘汰maxmemory-policy noeviction
#禁止对键值对回收不删除任何键值对知道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文件。
主从复制工作流程图 主从复制实验
实验准备
20.0.0.26 master
20.0.0.27 slave1
20.0.0.28 slave2
三台机器都需要安装redis服务做完后拍个快照systemctl stop firewalld
setenforce 0
#关闭三台机器的防火墙和安全机制主节点
vim /etc/redis/6379.conf
修改网段 0.0.0.0
daemonize yes
700行
开启aof模式
/etc/init.d/redis_6379 restart从节点1
vim /etc/redis/6379.conf
修改网段 0.0.0.0
288行
replicaof masterip masterport
replicaof 20.0.0.26 6379
#指向主的ip和端口
700行
开启aof模式
/etc/init.d/redis_6379 restart
开启了指向后从节点将变为只读模式从节点2
vim /etc/redis/6379.conf
修改网段 0.0.0.0
288行
replicaof masterip masterport
replicaof 20.0.0.26 6379
#指向主的ip和端口
700行
开启aof模式
/etc/init.d/redis_6379 restart
开启了指向后从节点将变为只读模式主节点
tail -f /var/log/redis_6379.log
#查看主节点日志看是否指向成功验证效果
主从都登录redis
主节点
set test1 1
#创建一个键值对
主上创建成功后到两台从节点查看一下看是否可以查看到从节点
set test2 2
#在从节点上测试是否为只读模式
报错说明搭建成功从节点已经设置为只读模式了实验完成redis-cli info replication
#查看主从配置信息停止一个从节点来测试。停机期间插入的数据服务重启后依旧可以同步
哨兵模式
哨兵模式依赖于主从模式先有主从再有哨兵
哨兵模式是在主从复制的基础上实现主节点故障的自动切换
哨兵模式的工作原理
哨兵是一个分布式系统。部署在每一个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、 选择一个复制数据最完整的从节点
哨兵模式监控的是节点不是哨兵
故障恢复可能会优点延迟
最好是以复制数据最完整的从节点作为新的主节点
哨兵模式实验
主节点
cd redis-5.0.7
vim sentinel.conf
#哨兵模式的配置文件17行
protected-mode no
#解除注释daemonize yes
#开启后台运行逃兵模式36行
logfile /var/log/sentinel.log
#指定日志文件的存放位置65行
dir/var/lib/redis/6379
#指定数据库存放的位置85行
sentinel monitor mymaster 20.0.0.26 6379 2
#声明主节点的IP和端口号.2代表至少要有2台服务认为主已经下线才会进行主从切换。一般配置为主从服务器的一半113行
sentinel down-after-milliseconds mymaster 30000
#服务器宕机的最小时间。单位是毫秒。30秒之内如果主节点但没有响应主观认为主下线了。时间可以改可以自定义146行
sentinel failover-timeout mymaster 180000
#服务器宕机的最大时间180秒之内如果主节点但没有响应从节点开始投票客观认为主下线了。时间可以改可以自定义两台从节点配置和主节点配置一致即可三台配置完成后需要先起主节点再起从节点三台主机在redis的源码包中启动哨兵模式
redis-sentinel sentinel.conf
#启动哨兵模式。表示后台运行主节点
redis-cli -p 26379 info Sentinel
#查看整个集群的哨兵情况查看主从信息
tail -f /var/log/redis_6379.log
#查看主节点日志查看主从信息模拟故障切换
可能会有延迟不是立刻切换
ps-elf | grep redis
#查看主节点
kill -9 redis的主进程或者/etc/init.d/redis_6379 stop停止redis都可以测试测试新主是否可以正常插入数据
测试两从是否可以数据同步
测试旧主机是否还有插入数据旧主失去写的功能新主增加写的功能。从2的配置文件指向了新的主
而旧主的配置文件中指向自己的配置将会消失
小模式用哨兵大模式用集群
总结
运维人员日常巡检中关注的指标
#查看redis使用内存的指标
used_memory:11285512
#数据占用的内存单位是字节
used_memory_rss:24285184
#向操作系统申请的内存单位是字节
used_memory_peak:23952088
#redis使用内存的峰值单位是字节内存碎片
内存碎片率used_mem0ry_rss/used_memory
#系统已经分配给了redis但是未能够有效利用的内存redis-cli info memory | grep ratio
#查看内存碎片率allocator_frag_ratio:1.03
#分配器碎片比例。由redis主进程调度时产生的内存比例越小越好值越高内存浪费越多。
allocator_rss_ratio:1.80
#表示分配器占用物理内存的比例主进程调度过程中占用了多少物理内存
rss_overhead_ratio:1.13
#RSS是向系统申请的内存空间redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
mem_fragmentation_ratio:2.16
#内存碎片的比例。值越低越好。表示内存的使用率越高
如何清理碎片
自动清理碎片
vim /etc/redis/6379.conf
最后一行插入
activedefrag yes
#自动清理碎片
/etc/init.d/redis_6379.conf restart
#重启redis服务手动清理碎片
redis-cli memory purge
#手动清理碎片
如何设置阈值
vim /etc/redis/6379.conf567行maxmemory 1gb
#一旦到达阈值会开始自动清理开启key的回收机制
工作用要么保证数据完整性使用maxmemory-policy noeviction 要么使用maxmemory-policy volatile-ttl挑选一个即将过期的键值对清除
在工作当中一定要给redis占用内存设置阈值否则会将整个系统内存占满为止
redis的缓存击穿
缓存击穿主要是热点数据缓存过期或者被删除多个请求并发访问热点数据。请求也是转发到后台数据库了导致数据库的性能快速下降。
经常被请求的缓存数据最好设置为永不过期
主从复制
主从复制是redis实现高可用的基础哨兵模式和集群都是在主从复制的基础上实现高可用。
主从复制实现数据的多机备份以及读写分离主服务器负责写从服务器只能读
缺陷故障无法自动恢复需要人工干预。无法实现写操作的负载均衡
哨兵模式
哨兵模式监控的是节点不是哨兵
故障恢复可能会优点延迟
最好是以复制数据最完整的从节点作为新的主节点
拓展
运维人员必须要关注的redis指标
在日常巡检中需要经常查看这些指标使用情况
info memory
#查看redis使用内存的指标
used_memory:11285512
#数据占用的内存单位是字节
used_memory_rss:24285184
#向操作系统申请的内存单位是字节
used_memory_peak:23952088
#redis使用内存的峰值单位是字节
如何查看内存碎片率
内存碎片率used_mem0ry_rss/used_memory
#系统已经分配给了redis但是未能够有效利用的内存redis-cli info memory | grep ratio
#查看内存碎片率allocator_frag_ratio:1.03
#分配器碎片比例。由redis主进程调度时产生的内存比例越小越好值越高内存浪费越多。
allocator_rss_ratio:1.80
#表示分配器占用物理内存的比例主进程调度过程中占用了多少物理内存
rss_overhead_ratio:1.13
#RSS是向系统申请的内存空间redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
mem_fragmentation_ratio:2.16
#内存碎片的比例。值越低越好。表示内存的使用率越高
redis占用的内存效率问题如何解决
1、 日常巡检中针对redis的占用情况做监控
2、 给redis设置一个占用系统内存的阈值避免占用系统的全部内容
3、 内存碎片清理分为手动和自动两种模式
4、配置一个合适的key的回收机制。一般都是设置写满报错的方式maxmemory-policy noeviction通过运维人员手动维护。或者挑选一个即将过期的键值对清除maxmemory-policy volatile-ttl。
redis的缓存击穿
缓存击穿主要是热点数据缓存过期或者被删除多个请求并发访问热点数据。请求也是转发到后台数据库了导致数据库的性能快速下降。
经常被请求的缓存数据最好设置为永不过期
