如果你使用过 redis，那你一定知道过期策略这个命令吧，如果让你设计一个过期键接口，你有什么想法？
我们在使用 redis 时，一般会设置一个过期时间，当然也有不设置过期时间的，也就是永久不过期。
当我们设置了过期时间，redis 是如何判断是否过期，以及根据什么策略来进行删除的。
redis 设置过期时间：
expire key time(以秒为单位) – 这是最常用的方式
setex(String key, int seconds, String value) – 字符串独有的方式
除了字符串自己独有设置过期时间的方法外，其他方法都需要依靠 expire 方法来设置时间
如果没有设置时间，那缓存就是永不过期
如果设置了过期时间，之后又想让缓存永不过期，使用 persist key
三种过期策略：
定时删除
-
- 含义：在设置 key 的过期时间的同时，为该 key 创建一个定时器，让定时器在 key 的过期时间来临时，对 key 进行删除
- 优点：保证内存被尽快释放
- 缺点：若过期 key 很多，删除这些 key 会占用很多的 CPU 时间，在 CPU 时间紧张的情况下， CPU 不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些 key，定时器的创建耗时，若为每一个设置过期时间的 key 创建一个定时器（将会有大量的定时器产生），性能影响严重。
懒汉式式删除
-
- 含义：key 过期的时候不删除，每次通过 key 获取值的时候去检查是否过期，若过期，则删除，返回 null。
- 优点：删除操作只发生在通过 key 取值的时候发生，而且只删除当前 key，所以对 CPU 时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的 key 了）
- 缺点：若大量的 key 在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）
定期删除
-
- 含义：每隔一段时间执行一次删除过期 key 操作
- 优点：通过限制删除操作的时长和频率，来减少删除操作对 CPU 时间的占用–处理 “定时删除” 的缺点
- 缺点：在内存友好方面，不如 ”定时删除”（会造成一定的内存占用，但是没有懒汉式那么占用内存） 在 CPU 时间友好方面，不如 ”懒汉式删除”（会定期的去进行比较和删除操作，cpu 方面不如懒汉式，但是比定时好）
- 难点：合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了），每次执行时间太长，或者执行频率太高对 cpu 都是一种压力。每次进行定期删除操作执行之后，需要记录遍历循环到了哪个标志位，以便下一次定期时间来时，从上次位置开始进行循环遍历
- 说明：memcached 只是用了惰性删除，而 redis 同时使用了惰性删除与定期删除，这也是二者的一个不同点（可以看做是 redis 优于 memcached 的一点）；对于懒汉式删除而言，并不是只有获取 key 的时候才会检查 key 是否过期，在某些设置 key 的方法上也会检查（eg.setnx key2 value2：该方法类似于 memcached 的 add 方法，如果设置的 key2 已经存在，那么该方法返回false，什么都不做；如果设置的 key2 不存在，那么该方法设置缓存 key2-value2。假设调用此方法的时候，发现 redis 中已经存在了 key2，但是该key2已经过期了，如果此时不执行删除操作的话，setnx方法将会直接返回false，也就是说此时并没有重新设置 key2-value2 成功，所以对于一定要在 setnx 执行之前，对 key2 进行过期检查）。
Redis 采用的过期策略
- 懒汉式删除+定期删除
懒汉式删除流程：
-
- 在进行 get 或 setnx 等操作时，先检查 key 是否过期；
- 若过期，删除 key，然后执行相应操作；
- 若没过期，直接执行相应操作；
- 定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期 key）：
- 遍历每个数据库（就是 redis.conf 中配置的 ”database” 数量，默认为 16）
- 检查当前库中的指定个数个 key（默认是每个库检查 20 个 key，注意相当于该循环执行 20 次，循环体是下边的描述）
- 如果当前库中没有一个 key 设置了过期时间，直接执行下一个库的遍历
- 随机获取一个设置了过期时间的 key，检查该key是否过期，如果过期，删除 key
- 判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。
对于定期删除，在程序中有一个全局变量 current_db 来记录下一个将要遍历的库，假设有 16 个库，我们这一次定期删除遍历了 10 个，那此时的 current_db 就是 11，下一次定期删除就从第11个库开始遍历，假设 current_db 等于 15 了，那么之后遍历就再从 0 号库开始（此时 current_db==0）
总结
在实际中，如果我们要自己设计过期策略， 在使用 懒汉式删除+定期删除 时，控制时长和频率这个尤为关键，需要结合服务器性能，以及并发量等情况进行调整，以致最佳。
Redis 有四个不同的命令可以用于设置键的生存时间（键可以存在多久）或过期时间（键什么时候会被删除）：
EXPIRE＜key＞＜ttl＞命令用于将键 key 的生存时间设置为 ttl 秒。
PEXPIRE＜key＞＜ttl＞ 命令用于将键 key 的生存时间设置为 ttl 毫秒。
EXPIREAT＜key＞＜timestamp＞ 命令用于将键 key 的过期时间设置为 timestamp 所指定的秒数时间戳。
PEXPIREAT＜key＞＜timestamp＞ 命令用于将键 key 的过期时间设置为 timestamp 所指定的毫秒数时间戳。
原理：
虽然有多种不同单位和不同形式的设置命令，但实际上 EXPIRE、PEXPIRE、EXPIREAT 三个命令都是使用PEXPIREAT 命令来实现的：无论客户端执行的是以上四个命令中的哪一个，经过转换之后，最终的执行效果都和执行 PEXPIREAT 命令一样。
redisDb 结构的 expires 字典保存了数据库中所有键的过期时间，我们称这个字典为过期字典
过期字典的键是一个指针，这个指针指向键空间中的某个键对象（也即是某个数据库键）。
过期字典的值是一个 long long 类型的整数，这个整数保存了键所指向的数据库键的过期时间——一个毫秒精度的 UNIX 时间戳。
下图展示了一个带有过期字典的数据库例子，在这个例子中，键空间保存了数据库中的所有键值对，而过期字典则保存了数据库键的过期时间。
为了展示方便，图中的键空间和过期字典中重复出现了两次 alphabet 键对象和 book 键对象。在实际中，键空间的键和过期字典的键都指向同一个键对象，所以不会出现任何重复对象，也不会浪费任何空间。
图中的过期字典保存了两个键值对：
第一个键值对的键为 alphabet 键对象，值为1385877600000，这表示数据库键 alphabet 的过期时间为1385877600000（2013年12月1日零时）。
第二个键值对的键为 book 键对象，值为 1388556000000，这表示数据库键 book 的过期时间为1388556000000（2014年1月1日零时）。当客户端执行 PEXPIREAT 命令（或者其他三个会转换成 PEXPIREAT 命令的命令）为一个数据库键设置过期时间时，服务器会在数据库的过期字典中关联给定的数据库键和过期时间。
在服务器执行以下命令之后
过期字典将新增一个键值对，其中键为 message 键对象，而值则为 1391234400000（2014年2月1日零时），如图：
以下是 PEXPIREAT 命令的伪代码定义
PERSIST 命令可以移除一个键的过期时间
PERSIST 命令就是 PEXPIREAT 命令的反操作：PERSIST 命令在过期字典中查找给定的键，并解除键和值（过期时间）在过期字典中的关联。
过期键的判定
通过过期字典，程序可以用以下步骤检查一个给定键是否过期：
-
- 检查给定键是否存在于过期字典：如果存在，那么取得键的过期时间。
- 检查当前UNIX时间戳是否大于键的过期时间：如果是的话，那么键已经过期；否则的话，键未过期。可以用伪代码来描述这一过程：
