KEY

返回所有满⾜样式（pattern）的key。⽀持如下统配样式。

• h?llo 匹配 hello , hallo 和 hxllo
• h*llo 匹配 hllo 和 heeeello
• h[ae]llo 匹配 hello 和 hallo 但不匹配 hillo
• h[^e]llo 匹配 hallo , hbllo ,…但不匹配 hello
• h[a-b]llo 匹配 hallo 和 hbllo

语法：

 KEYS pattern

时间复杂度：O(N)

返回值：匹配pattern的所有key。

⽰例：

redis> MSET firstname Jack lastname Stuntman age 35
"OK"
redis> KEYS *name*
1) "firstname"
2) "lastname"
redis> KEYS a??
1) "age"
redis> KEYS *
1) "age"
2) "firstname"
3) "lastname"

EXISTS

判断某个key是否存在。

语法：

 EXISTS key [key ...]

时间复杂度：O(1)

返回值：key存在的个数。

⽰例：

redis> SET key1 "Hello"
"OK"
redis> EXISTS key1
(integer) 1
redis> EXISTS nosuchkey
(integer) 0
redis> SET key2 "World"
"OK"
redis> EXISTS key1 key2 nosuchkey
(integer) 2

贴士：一个exists语句就是一次网络请求响应，因此尽量用一个exists语句来判断多个key是否存在。

DEL

删除指定的key。

语法：

 DEL key [key ...]

时间复杂度：O(1)

返回值：删除掉的key的个数。

⽰例：

redis> SET key1 "Hello"
"OK"
redis> SET key2 "World"
"OK"
redis> DEL key1 key2 key3
(integer) 2

EXPIRE

为指定的key添加秒级的过期时间

语法：

EXPIRE key seconds

时间复杂度：O(1)

返回值：1表⽰设置成功。0表⽰设置失败

实例：

我们不设置expire它的默认有效期是永久，即ttl后会返回-1代表永久有效。

TTL

获取指定key的过期时间，秒级。

语法：

TTL key

时间复杂度：O(1)

返回值：剩余过期时间。-1表⽰没有关联过期时间，-2表⽰key不存在。

实例：

---

EXPIRE和TTL命令都有对应的⽀持毫秒为单位的版本：PEXPIRE和PTTL

---

Redis的key过期策略

一个redis中可能同时存在很多很多key. 这些key中可能有很大一部分都有过期时间. 此时, redis 服务器咋知道哪些key已经过期要被删除,哪些key还没过期??

如果直接遍历所有的key ,显然是行不通的.效率非常低~~

过期策略一般有以下三种：

1，定时过期

• 每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

2，惰性过期

• 只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

3，定期过期

• 每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

Redis中同时使用了惰性过期和定期过期两种过期策略。

Redis过期删除采用的是定期删除，默认是每100ms检测一次，遇到过期的key则进行删除，这里的检测并不是顺序检测，而是随机检测。那这样会不会有漏网之鱼？显然Redis也考虑到了这一点，当我们去读/写一个已经过期的key时，会触发Redis的惰性删除策略，直接会干掉过期的key。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

定期删除：redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key，然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

---

缓存淘汰 eviction

Redis自身实现了缓存淘汰

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

• noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。
• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。
• redis 4.x 后支持LFU策略，最少频率使用，allkeys-lfu，volatile-lfu

---

TYPE

返回key对应value的数据类型。

语法：

TYPE key

时间复杂度：O(1)

返回值： none ,string , list , set ,zset ,hash and stream。

redis> SET key1 "value"
"OK"
redis> LPUSH key2 "value"
(integer) 1
redis> SADD key3 "value"
(integer) 1
redis> TYPE key1
"string"
redis> TYPE key2
"list"
redis> TYPE key3
"set"

---

the end!