全是干货的技术号： 本文已收录在github，欢迎 star/fork： https://github.com/Wasabi1234/Java-Interview-Tutorialjava
1 设置带过时时间的 key
expire key seconds 时间复杂度：O（1）
设置key的过时时间。超时后，将会自动删除该key。在Redis的术语中一个key的相关超时是volatile的。git
超时后只有对key执行DEL、SET、GETSET时才会清除。 这意味着，从概念上讲全部改变key而不用新值替换的全部操做都将保持超时不变。 例如，使用 INCR 递增key的值，执行 LPUSH 将新值推到 list 中或用 HSET 改变hash的field，这些操做都使超时保持不变。github
- 使用
PERSIST命令能够清除超时，使其变成一个永久key - 若
key被RENAME命令修改，相关的超时时间会转移到新key - 若
key被RENAME命令修改，好比原来就存在Key_A，而后调用RENAME Key_B Key_A命令，这时无论原来Key_A是永久的仍是设为超时的，都会由Key_B的有效期状态覆盖
注意，使用非正超时调用 EXPIRE/PEXPIRE 或具备过去时间的 EXPIREAT/PEXPIREAT 将致使key被删除而不是过时（所以，发出的key事件将是 del，而不是过时）。redis
1.1 刷新过时时间
对已经有过时时间的key执行EXPIRE操做，将会更新它的过时时间。有不少应用有这种业务场景，例如记录会话的session。算法
1.2 Redis 以前的 2.1.3 的差别
在 Redis 版本以前 2.1.3 中，使用更改其值的命令更改具备过时集的密钥具备彻底删除key的效果。因为如今修复的复制层中存在限制，所以须要此语义。spring
EXPIRE 将返回 0，而且不会更改具备超时集的键的超时。shell
1.3 返回值
1若是成功设置过时时间。0若是key不存在或者不能设置过时时间。
1.4 示例
假设有一 Web 服务，对用户最近访问的最新 N 页感兴趣，这样每一个相邻页面视图在上一个页面以后不超过 60 秒。从概念上讲，能够将这组页面视图视为用户的导航会话，该会话可能包含有关ta当前正在寻找的产品的有趣信息，以便你能够推荐相关产品。缓存
可以使用如下策略轻松在 Redis 中对此模式建模：每次用户执行页面视图时，您都会调用如下命令：session
MULTI RPUSH pagewviews.user:<userid> http://..... EXPIRE pagewviews.user:<userid> 60 EXEC
若是用户空闲超过 60 秒，则将删除该key，而且仅记录差别小于 60 秒的后续页面视图。 此模式很容易修改，使用 INCR 而不是使用 RPUSH 的列表。dom
1.5 带过时时间的 key
一般，建立 Redis 键时没有关联的存活时间。key将永存，除非用户以显式方式（例如 DEL 命令）将其删除。 EXPIRE 族的命令可以将过时项与给定key关联，但代价是该key使用的额外内存。当key具备过时集时，Redis 将确保在通过指定时间时删除该key。 可以使用 EXPIRE 和 PERSIST 命令（或其余严格命令）更新或彻底删除生存的关键时间。
1.6 过时精度
在 Redis 2.4 中，过时可能不许确，而且可能介于 0 到 1 秒之间。 因为 Redis 2.6，过时偏差从 0 到 1 毫秒。
1.7 过时和持久化
过时信息的键存储为绝对 Unix 时间戳（Redis 版本 2.6 或更高版本为毫秒）。这意味着即便 Redis 实例不处于活动状态，时间也在流动。 要使过时工做良好，必须稳定计算机时间。若将 RDB 文件从两台计算机上移动，其时钟中具备大 desync，则可能会发生有趣的事情（如加载时加载到过时的全部key）。 即便运行时的实例，也始终会检查计算机时钟，例如，若是将一个key设置为 1000 秒，而后在未来设置计算机时间 2000 秒，则该key将当即过时，而不是持续 1000 秒。
2 Redis 如何使key过时
键的过时方式有两种：被动方式 - 惰性删除，主动方式 - 按期删除。
2.1 惰性删除
当客户端尝试访问key时，key会被动过时，即Redis会检查该key是否设置了过时时间，若是过时了就会删除，也不会返回任何东西。 注意并不是是key到期了就会被自动删除，而是当查询该key时，Redis再很懒惰地检查是否删除。这和 spring 的延迟初始化有着殊途同归之妙。
固然，这是不够的，由于有过时的key，永远不会再访问。不管如何，这些key都应过时，所以请按期 Redis 在具备过时集的key之间随机测试几个key。已过时的全部key将从key空间中删除。
2.2 按期删除
具体来讲，以下 Redis 每秒 10 次：
- 测试 20 个带有过时的随机键
- 删除找到的全部已过时key
- 若是超过 25% 的key已过时，从步骤 1 从新开始
这是一个微不足道的几率算法，基本上假设咱们的样本表明整个key空间，继续过时，直到可能过时的key百分比低于 25%。 这意味着在任何给定时刻，使用内存的已过时的最大键量等于最大写入操做量/秒除以 4。
2.3 在复制链路和 AOF 文件中处理过时的方式
为了在不牺牲一致性的状况下得到正确行为，当key过时时，DEL 操做将同时在 AOF 文件中合成并获取全部附加的从节点。这样，过时的这个处理过程集中到主节点中，尚未一致性错误的可能性。
可是，虽然链接到主节点的从节点不会独立过时key（但会等待来自master的 DEL），但它们仍将使用数据集中现有过时的完整状态，所以，当选择slave做为master时，它将可以独立过时key，彻底充当master。
但是，不少过时key，你没及时去查，按期删除也漏掉了，大量过时key堆积内存，Redis内存殆耗尽！
所以还需有内存淘汰机制！
3 内存淘汰
3.1 内存淘汰策略
noeviction（Redis默认策略）
不会继续服务写请求 (DEL 请求能够继续服务)，读请求能够继续进行。这样 能够保证不会丢失数据，可是会让线上的业务不能持续进行。
- config.c
createEnumConfig("maxmemory-policy", NULL,
MODIFIABLE_CONFIG, maxmemory_policy_enum,
server.maxmemory_policy,
MAXMEMORY_NO_EVICTION, NULL, NULL),
allkeys-random
当内存不足以容纳新写入数据时，在键空间中，随机移除某key。凭啥随机呢，至少也是把最近最少使用的key删除。
allkeys-lru(Least Recently Used)
当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key，没有设置过时时间的 key 也会被淘汰。
allkeys-lfu(Least Frequently Used)
LRU的关键是看页面最后一次被使用到发生调度的时间长短，而LFU关键是看必定时间段内页面被使用的频率。
volatile-lru
尝试淘汰设置了过时时间的 key，最少使用的 key 优先被淘汰。 没有设置过时时间的 key 不会被淘汰，这样能够保证须要持久化的数据不会忽然丢失。 区别于 allkey-lru，这个策略要淘汰只是过时的 key 集合。
volatile-lfu
volatile-random
淘汰的 key 是过时 key 集合中随机的 key。
volatile-ttl
淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。
volatile-xxx 策略只会针对带过时时间的 key 进行淘汰，allkeys-xxx 策略会对全部的 key 进行淘汰。
- 若是你只是拿 Redis 作缓存，那应该使用 allkeys-xxx，客户端写缓存时没必要携带过时时间。
- 若是你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样能够保留没有设置过时时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。
3.2 手写LRU
确实有时会问这个，由于有些候选人若是确实过五关斩六将，前面的问题都答的很好，那么其实让他写一下LRU算法，能够考察一下编码功底
你能够现场手写最原始的LRU算法，那个代码量太大了，不太现实
public class LRUCache<K, V> extends LinkedHashMap<K, V> {
private final int CACHE_SIZE;
// 这里就是传递进来最多能缓存多少数据
public LRUCache(int cacheSize) {
// true指linkedhashmap将元素按访问顺序排序
super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
CACHE_SIZE = cacheSize;
}
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
// 当KV数据量大于指定缓存个数时，就自动删除最老数据
return size() > CACHE_SIZE;
}
}
参考