TTL

ttl ---  time to line

网络原理的IP协议当中，IP协议报头中，就有一个字段，TTL

IP中的TTL不是用时间衡量过期的，而是用次数

功能：查看当前的key的过期时间还剩多少

语法： ttl key

时间复杂度：O（1）

返回值：剩余过期时间， -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集群通常通过主从复制和故障转移来提供高可用性。时间轮的方式可能会对故障转移过程中的定时任务触发和调度产生影响，需要额外的处理来确保任务的正确执行。