1.定时删除
2.惰性删除
3.定期删除
创建一个定时器,当key设置有过期时间,且过期时间到达时,由定时器任务立即执行对键的删除操作。定时监控expires内存中相应的时间 ,时间到了就根据对应的内存地址找到对应的数据将其删除 。
优点:节约内存,到时就删除,快速释放掉不必要的内存占用
缺点:CPU压力很大,无论CPU此时负载量多高,均占用CPU,会影响redis服务器响应时间和指令吞吐量
总结:用处理器性能换取存储空间(拿时间换空间)
数据到达过期时间,不做处理。等下次访问该数据时,我们需要判断
如果未过期,返回数据
发现已过期,删除,返回不存在
优点:节约CPU性能,发现必须删除的时候才删除
缺点:内存压力很大,出现长期占用内存的数据
总结:用存储空间换取处理器性能(拿空间换时间)
定期删除就是周期性轮询redis库中的时效性数据,采用随机抽取的策略,利用过期数据占比的方式控制删除频度
特点1:CPU性能占用设置有峰值,检测频度可自定义设置
特点2:内存压力不是很大,长期占用内存的冷数据会被持续清理
总结:周期性抽查存储空间(随机抽查,重点抽查)
1:定时删除:
节约内存,无占用,
不分时段占用CPU资源,频度高,
拿时间换空间
2:惰性删除:
内存占用严重
延时执行,CPU利用率高
拿空间换时间
3:定期删除:
内存定期随机清理
每秒花费固定的CPU资源维护内存
随机抽查,重点抽查
Redis淘汰策略是指 如果内存不满足新 加入数据的最低存储要求,redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。
淘汰策略有3类8种:
第一类:检测易失数据
volatile-lru:挑选最近最少使用的数据淘汰
volatile-lfu:挑选最近使用次数最少的数据淘汰
volatile-ttl:挑选将要过期的数据淘汰
volatile-random:任意选择数据淘汰
第二类:检测全库数据
allkeys-lru:挑选最近最少使用的数据淘汰
allkeLyRs-lfu::挑选最近使用次数最少的数据淘汰
allkeys-random:任意选择数据淘汰,相当于随机
第三类:放弃数据驱逐
no-enviction(驱逐):禁止驱逐数据,就是不淘汰数据(redis4.0中默认策略),会引发OOM(Out Of Memory)
高并发
应用要提供某一业务要能支持很多客户端同时访问的能力,我们称为并发,高并发意思就很明确了
高性能
性能带给我们最直观的感受就是:速度快,时间短
高可用
步骤1:设置master的地址和端口,保存master信息
步骤2:建立socket连接
步骤3:发送ping命令(定时器任务)
步骤4:身份验证
步骤5:发送slave端口信息
步骤1:请求同步数据
步骤2:创建RDB同步数据
步骤3:恢复RDB同步数据
步骤4:请求部分同步数据
步骤5:恢复部分同步数据
当master数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的状态,同步的动作称为命令传播
master将接收到的数据变更命令发送给slave,slave接收命令后执行命令
runid和offset有一个变化:执行全量复制
runid不变offset变化:执行部分复制
哨兵的作用:
监控:监控master和slave
不断的检查master和slave是否正常运行
master存活检测、master与slave运行情况检测
通知(提醒):当被监控的服务器出现问题时,向其他(哨兵间,客户端)发送通知
自动故障转移:断开master与slave连接,选取一个slave作为master,将其他slave连接新的master,并告知客户端新的服务器地址
哨兵在进行主从切换过程中经历三个阶段
监控:
获取各个sentinel的状态(是否在线)
获取master的状态
获取所有slave的状态
通知:
哨兵(sentinel)在通知阶段要不断的去获取master/slave的信息,然后在各个哨兵之间进行共享.
故障转移:
判断master是否挂了
选举出决定更换master的sentinel
由选举胜出的sentinel去从slave中选一个新的master
集群就是使用网络将若干台计算机联通起来,并提供统一的管理方式,使其对外呈现单机的服务效果
集群作用:
分散单台服务器的访问压力,实现负载均衡
分散单台服务器的存储压力,实现可扩展性
降低单台服务器宕机带来的业务灾难
通过算法设计,计算出key应该保存的位置
将所有的存储空间计划切割成16384份,每台主机保存一部分
注意:每份代表的是一个存储空间,不是一个key的保存空间
将key按照计算出的结果放到对应的存储空间
各个数据库相互通信,保存各个库中槽的编号数据
一次命中,直接返回
一次未命中,告知具体位置
场景:
请求数量太高,而缓存中又没有这些数据,此时从数据库中查找数据然后将数据再存入缓存,造成了短期内对redis的高强度操作从而导致服务器宕机
解决方案:
系统启动前,提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!
场景:
1.系统平稳运行过程中,忽然数据库连接量激增
2.应用服务器无法及时处理请求
3.大量408,500错误页面出现
4.客户反复刷新页面获取数据
5.数据库 服务器 redis redis集群崩溃
解决方案:
1.LRU与LFU切换
2.数据有效期策略调整
3.超热数据使用永久key
4.定期维护(自动+人工)
场景:
1.系统平稳运行过程中
2.数据库连接量瞬间激增
3.Redis服务器CPU正常
4.数据库崩溃
解决方案:
1.预先设定
加大高热信息key的过期时长
2.现场调整
监控访问量,对自然流量激增的数据延长过期时间或设置为永久性key
3.后台刷新数据
启动定时任务,高峰期来临之前,刷新数据有效期,确保不丢失
设置不同的失效时间,保障不会被同时淘汰就行
5.加锁
分布式锁,防止被击穿,但是要注意也是性能瓶颈,慎重!
场景:
(缓存穿透是指访问了不存在的数据,跳过了合法数据的redis数据缓存阶段,每次访问数据库,导致对数据库服务器造成压力。)
1.系统平稳运行过程中
2.应用服务器流量随时间增量较大
3.Redis服务器命中率随时间逐步降低
4.Redis服务器CPU占用激增
5.数据库服务器压力激增,导致数据库崩溃
解决方案:
1.缓存null
2.白名单策略
3.实施监控
原文:https://www.cnblogs.com/sunhao410526/p/14611913.html