国外 设计 网站,如何创建网络,建设银行公积金网站,网站关键字优化合同TTL
ttl --- time to line 网络原理的IP协议当中#xff0c;IP协议报头中#xff0c;就有一个字段#xff0c;TTL IP中的TTL不是用时间衡量过期的#xff0c;而是用次数 功能#xff1a;查看当前的key的过期时间还剩多少
语法#xff1a; ttl key
时间复杂度#xf…TTL
ttl --- time to line 网络原理的IP协议当中IP协议报头中就有一个字段TTL IP中的TTL不是用时间衡量过期的而是用次数 功能查看当前的key的过期时间还剩多少
语法 ttl key
时间复杂度O1
返回值剩余过期时间 -1表示没有关联过期时间-2表示key不存在。
redis的key过期策略是怎么实现的 一个redis中可能同时存在多个key这些key中可能有很大一部分都有过期时间此时redis服务器怎么知道哪些key已经过期要被删除哪些key还没过期 如果直接遍历所有的key显然是行不通的效率非常的低。 redis的整体策略1.定期删除2.惰性删除
惰性删除
惰性删除也就是说假设有一个key已经到了过期的时间但是暂时还没删除它key还存在后面一次访问正好用到了这个key于是这次访问就会让redis服务器触发删除key的操作同时返回一个nil
定期删除
定期删除每次会抽取一部分进行验证过期时间保证每次抽取检查的时候足够快。
为啥对定期删除的时间有明确的要求
因为redis是一个单线程的程序主要的任务处理每个命令的任务扫秒每个过期的key...。 如果扫秒过期的key消耗的时间过多就可能导致正常处理请求命令阻塞。
redis为了上述进行补充还提供了一系列的内存淘汰策略
补充
1.redis中并没有采取定时器的方式来实现过期key的删除
2.如果有多个key过期也可以通过一个定时器来高效/节省CPU的前提下来处理多个key 既然redis没有采取定时器的方式来实现过期key的删除我们是否能够设计一个基于定时器的方式
当然我们可以基于 优先级队列 或者基于 时间轮 都可以实现比较高效的定时器。
基于优先级队列、时间轮实现高效的定时器
先来了解一下什么叫做定时器 定时器在某个时间到达后执行指定的任务 1.基于优先级队列 /堆 正常的队列是先进先出优先级队列是指定的优先级先出。 在redis过期key的场景中就可以通过过期时间越早就是优先级越高 此时定时器只要分配一个线程让这个线程去检查队首元素看是否过期就可以了。
如果队首元素还没过期后续元素就没有过期。
此时扫秒线程 不需要遍历所有的key只需要盯住一个队首元素即可。 但是这个扫秒也不能太频繁不然也会挂掉所以可以考虑根据队首元素的过期时间设置一个等待当时间差不多到了系统就唤醒这个线程。 但是万一线程休眠的时候来了一个新任务比队首元素的优先级更高怎么办
可以在新任务添加的时候唤醒一下刚才的线程重新检查一下队首元素再根据时间差距调整阻塞时间即可。
2.基于时间轮实现的定时器
时间轮的初始化:创建一个固定大小的时间轮每个槽位表示一定时间间隔例如100毫秒。将指针指向当前槽位。 定时任务添加:当添加一个定时任务时计算任务的触发时间与当前时间的时间差将任务放入相应的槽位中。 时间轮的转动:定时器以固定的时间间隔进行轮转指针按顺时针方向移动一个槽位。当指针指向的槽位中存在任务时执行这些任务。定时任务触发:当指针指向的槽位中存在任务时执行这些任务并将任务从位中移除。如果任务是重复性任务则重新计算下一次触发的时间将任务添加到相应的槽位中。 时间轮的级联:为了支持更大范围的定时任务可以使用多级时间轮。当当前时间轮的指针转到下一级时间轮的槽位时将下一级时间轮中对应的槽位的任务触发。 把时间划分成很多个小段划分的粒度看实际需求 对于时间轮来说每个格子是多少时间一共有多少格子都是需要根据实际场景来设置的。 3.Redis不使用的原因仅代表个人观点
1.简单性和轻量性:Redis的设计目标之一是简单和轻量级它的核心功能是支持高效的键值存储和快速的数据访问。为了保持代码的简洁性和性能的高效性Redis采用了一种简单的过期策略即在对键进行访问时检查其过期时间并在需要时进行过期处理。这种单的策略不需要引入复杂的定时器实现可以更好地满足Redis的设计目标。
2.内存效率:Redis在内存管理方面非常高效采用了各种优化技术来降低内存占用。使用基于优先级队列或时间轮的定时器可能会引入额外的数据结构和内存开销增加了Redis的复杂性和内存消耗。简单的过期策略可以更好地与Redis的内存模型相匹配保持较低的内存占用。
3.分布式一致性:Redis集群的核心目标是提供高可用性和数据一致性。使用时间轮定时器可能会引入分布式一致性的挑战因为不同节点上的定时器可能存在触发时机的差异可能导致数据的不一致性。 4.协调开销:时间轮的方式通常需要定时器线程在每个节点上执行这可能引入额外的协调开销。如果需要在整个集群中保持定时任务的一致性可能需要额外的通信和同步机制增加了系统的复杂性和开销。 5.高可用性:Redis集群通常通过主从复制和故障转移来提供高可用性。时间轮的方式可能会对故障转移过程中的定时任务触发和调度产生影响需要额外的处理来确保任务的正确执行。
