怎么建设一个手机网站,营销案例分析,ps做网站首页,做网站需要投入多少钱一、redis的性能管理
redis的数据时缓存在内存中的
查看系统内存情况
info memory used_memory:853688 redis中数据占用的内存
used_memory_rss:10522624 redis向操作系统申请的内存
used_memory_peak:853688 redis使用内存的峰值 系统巡检#xff1a;硬件巡检、数据库 n…
一、redis的性能管理
redis的数据时缓存在内存中的
查看系统内存情况
info memory used_memory:853688 redis中数据占用的内存
used_memory_rss:10522624 redis向操作系统申请的内存
used_memory_peak:853688 redis使用内存的峰值 系统巡检硬件巡检、数据库 nginx redis docker k8s等软件巡检 内存碎片率used_memory_rss/used_memory内存碎片率
系统已经分配给了redis但是redis未能够有效利用的内存 查询比率
redis-cli info memory | grep ratio
allocator_frag_ratio:1.26
分配器碎片的比例redis的主进程调度时产生的内存。比例要越小越好值越高说明内存的浪费越多
allocator_rss_ratio:4.54
分配器占用物理内存的比例告诉你主进程调度执行时占用了多少物理内存
rss_overhead_ratio:1.36
RSS是向系统申请的内存空间redis占用物理空间额外的开销比例比例要越低越好表示redis实际占用的内存和向系统申请的内存越接近额外的开销越低
mem_fragmentation_ratio:15.16
内存碎片的比例越低越好内存的使用率越高 清理碎片
自动清理碎片
vim /etc/redis/6379.conf
最后一行插入
activedefrag yes
开启自动清理
要设置redis最大内存阀值
一旦到达阀值自动清理碎片开启key的回收机制 567行
设置占用最大内存
maxmemory 1gb
一定要设置占用内存的阀值 598行
设置开启key的回收机制
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占用内存设置阀值 手动配置
redis-cli memory purge 工作中reids占用内存效率问题如何处理
1、日常巡检中对redis的占用情况做监控
2、设置redis占用系统内存的阀值避免占用系统全部内存
3、内存碎片清理手动和自动清理
4、配置合适的key回收机制 redis雪崩
也是缓存雪崩大量的应用请求无法在redis缓存中处理请求会全部发送到后台数据库
数据库本身并发能力就差一旦高并发数据库会很快崩溃 导致雪崩的原因
redis集群大面积故障
redi缓存中大量数据同时过期大量的请求无法得到处理
redis实例宕机。 解决方法
事前高可用架构防止整个缓存故障。只从复制和哨兵模式。redis集群
事中在国内用的比较多的方式HySTRIX熔断降级限流三个手段来降低雪崩发生过后的损失
事后redis备份。快速缓存预热 redis的缓存击穿
导致原因
主要是热点数据缓存过期或者被删除多个请求并发访问热点数据请求也是转发到数据库导致数据库的性能快速下降
经常被请求的缓存数据最好设置为永不过期 redis缓存穿透
缓存中没有数据数据库也诶呦对应数据但是有用户一直在发起这个都没有的请求而且请求的数据格式很大。一般是黑客再利用漏洞攻击以压垮应用数据库 键值对还在但是值被替换了原有的请求找不到之后同样也会去请求后台的数据库也是击穿的一种 redis的集群
高可用方案
持久化高可用 主从复制 哨兵模式 集群
主从复制时redis实现高可用的基础哨兵模式和集群都是在主从复制的基础上实现高可用的
主从复制实现数据的多级备份以及读写分离主负责写从负责读 缺点故障无法自动恢复。需要人工干预写操作无法实现负载均衡 主从复制的工作原理
主节点 master 从节点slave组成数据的复制时单向的只能从主节点到从节点 架构配置
主从复制
主 20.0.0.41
从1 20.0.0.42
从2 20.0.0.43 关防火墙和安全机制
修改master节点的配置文件
vim /etc/redis/6379.conf bind 0.0.0.0 #70行,修改监听地址为0.0.0.0生产环境中尤其是多网卡最好填写物理网卡的IP daemonize yes #137行开启守护进程后台启动 logfile /var/log/redis_6379.log #172行指定日志文件存放目录 dir /var/lib/redis/6379 #264行指定工作目录 appendonly yes #700行开启AOF持久化功能 /etc/init.d/redis_6379 restart #重启redis服务 改两个slave节点的配置文件
#修改slave1的配置文件
vim /etc/redis/6379.conf bind 0.0.0.0 #70行,修改监听地址为0.0.0.0生产环境中需要填写物理网卡的IP daemonize yes #137行,开启守护进程后台启动 logfile /var/log/redis_6379.log #172行,指定日志文件目录 dir /var/lib/redis/6379 #264行,指定工作目录 replicaof 20.0.0.41 6379 #288行,指定要同步的Master节点的IP和端口 appendonly yes #700行,修改为yes开启AOF持久化功能 /etc/init.d/redis_6379 restart #重启redis
netstat -natp | grep redis #查看主从服务器是否已建立连接 tail -f /var/log/redis_6379.log 实验测试
主节点创建数据从节点是否同步 只有主节点能读写从节点只能读 查看主从状态信息
redis-cli info replication 哨兵模式
先有主从然后再有哨兵在主从复制的基础只上实现主节点故障的自动切换。 哨兵模式的原理
是一个分布式系统每个节点上都有哨兵用于在主从结构之间对每台redis服务进行服务监控 主节点出现故障时从节点通过投票的方式选择一个新的master
哨兵模式也需要至少三个节点 哨兵模式的结构 哨兵节点监控不存储任何数据
数据节点主节点和从节点都是数据节点 redis工作机制 哨兵监控的是redis的节点不是监控哨兵
每个哨兵每隔一秒通过ping命令的方式检测主从之间的心跳线
主节点在一定时间内没有回复或则回复了错误消息。这个时候哨兵会主观的任务主节点下线了。如果有超过半数的哨兵节点认为主节点下线了在个时候才会认为主节点是客观下线
哨兵节点通过raft算法选举算法每个节点共同投票选举出一个新的master。然后新的master来实现主节点的转义和故障恢复通知 主节点选举的过程
已经下线的从节点不会被选为主节点选择配置微文件中从节点优先级最高的replica-priority 100选择一个复制数据最完整的从节点 哨兵模式源码包里自带
主从配置方式一致
vim /opt/redis-5.0.7/sentinel.conf 17行 protected-mode no
取消注释
关闭保护模式 21行
哨兵模式默认端口 26行
指定哨兵模式是否后台运行 改成yes 36行
是日志文件 65行
设置工作目录 84行
指定初始的主服务器 这里的2表示至少需要2台服务器认为主已经下线才会进行主从切换 113行
判断服务器宕掉的服务周期 146行
故障节点的最大超时时间 配置完之后
重启服务
要先启master 再启slave
都在redis原码包目录下启动的
要在reids原码包目录下启动
redis-sentinel sentinel.conf 监控哨兵集群
查看整个集群的哨兵情况
redis-cli -p 26379 info Sentinel 模拟故障 先杀进程或暂停节点 然后投票选举一个master 测试结果新master创建数据slave同步数据 故障恢复重启源master服务器
