Redis --- 第三讲 --- 通用命令

一、get和set命令

Redis中最核心的两个命令

get 根据key来取value

set 把key和value存储进去

redis是按照键值对的方式存储数据的。必须要先进入到redis客户端。

语法 set key value ： key和value都是字符串。

对于上述这里的key value 不需要加上引号，就是表示字符串，加上引号也无伤大雅。redis中的命令不区分大小写。

使用get得到key对应的value值。

get命令直接输入key就能得到value。如果当前key不存在，返回nil，和null/NULL就是一个意思。

redis使用简单，学习成本很低。

二、全局命令

Redis全局命令

Redis是支持很多种数据结构的，整体上来说，Redis是键值对结构，key固定都是字符串，value实际上会有多种类型。比如字符串，哈希表，列表，集合，有序集合等等。每种数据结构都会对应着不同的命令，而全局命令就是能够搭配任意一个数据结构来使用的命令。

1）keys命令用来查询当前服务器上匹配的key

通过一些特殊符号来描述key的模样，匹配上述模样的key就能被查询出来。

语法：keys pattern

pattern 包含特殊符号的字符串，有的地方翻译成样式或者模式。重点去认识这个英文术语。存在的意义，是去描述另外的字符串长啥样。

pattern具体咋写，支持哪些通配符呢

？匹配任意一个字符

*匹配0个任意多个字符

[ae] 只能匹配到ae，别的不行，相当于给出固定选项了

[^e] 排除e，只有e匹配不了，其他的都能匹配。

[a - e] 匹配a - e这个范围内的字符，包含两侧边界。

设置这样的key，通过上述的匹配方法进行查询

上述的匹配规则不需要去背。要查询文档。

keys命令的时间复杂度是O(N)。所以在生产环境上，一般都会禁止使用keys命令，尤其是大杀器keys * 。查询redis中所有的key！生产环境上的key可能会非常多！而redis是一个单线程的服务器，执行keys * 的时间非常长，就是redis服务器被阻塞了。无法给其他客户端提供服务。这样的后果可能是灾难性的。redis经常会用于做缓存，挡在mysql前面。替mysql负重前行。万一redis被一个keys * 阻塞住了，此时其他的查询redis操作就超时了。此时这些请求就会直接查数据库。突然一大波请求到来，mysql措手不及，会把它给搞挂了。这个操作非常危险，容易把工作给搞丢。那你就得让你的媳妇吃土或者喝西北风了，很可能你的媳妇就跟别人跑了。（开个小玩笑）。

穿插一个概念，叫做生产环境（线上环境）：

未来的工作中会涉及到几个环境：

1、办公环境（入职之后，公司给你发个电脑）

笔记本电脑/台式机。

2、开发环境：有的时候，开发环境和办公环境是一个，有的时候，开发环境是单独的服务器，做前端/客户端，一般来说开发环境就是办公环境了。后端来说，很可能是单独的服务器，有的后端程序，会比较复杂。

1）一次时间特别久。

2）有的程序，启动要消耗很多的cpu和内存资源。办公电脑难以支撑。

3）有的程序比较依赖linux，在windows环境搭不起来。

3、测试环境（测试工程师用的）

4、线上环境/生产环境

（办公环境，开发环境，测试环境，统称为线下环境，外界用户无法访问到的）。线上环境则是外界用户能够访问到的。一旦生产环境出问题，一定会对于用户的使用产生影响！直接的影响到公司营收。

未来咱们去操作线上环境的任何一个设备/程序都要怀着12分的谨慎。

2）exists命令

exists判定key是否存在

语法：

返回值：key存在的个数。键值对存储的体系中（类似于哈希表）key得是唯一的呀。

这里的个数对于多个key来说是非常有用的。他的查询复杂度为O(1)，redis组织这些key就是按照哈希表的方式来组织的。

redis支持很多数据结构 =》指的是一个value可以是一些复杂的数据结构，redis自身的这些键值对，是通过哈希表的方式来组织的。redis具体的某个值，又可以是一些数据结构。

分开查询和一起查询会有什么区别吗。

我们要知道，redis是一个客户端，服务器结构的程序。客户端和服务器之间通过网络来进行通信！我们所敲的命令都会构建一个请求发送给服务器，服务器返回回复报文。要进行网络通信，它是相对于内存来说，效率比较低，成本比较高。

进行网络通信的时候，发送方发送一个数据，这个数据就要从应用层，到物理层，层层封装。势必会导致传输速度慢。所以我们要尽量少发请求。能用一个命令不用两个命令。

3）del（delete）删除指定的key

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

redis主要的应用场景，就是作为缓存，此时redis里存的只是一个热点数据，全量数据是在mysql数据库中。此时如果把redis中的key删除了几个，一般来说，问题不大。但是如果把所有的数据或者一大半数据一下都干没了，这种影响会很大。相比之下，如果是mysql这样的数据，哪怕误删了一个数据，都可能影响很大的。如果把redis作为数据库，此时误删数据的影响就大了。如果把redis作为消息队列，这种情况误删数据就得按情况来具体分析了。所以我们不能乱删数据。自己挖坑自己跳，得不偿失。

4）expire命令

作用是给指定的key设置过期时间，key存活时间超出这个指定的值，就会被自动删除。设置的时间单位是秒。基于redis实现分布式锁，为了避免出现不能正确解锁的情况，通常都会在加锁的时候设置一下过期时间（所谓的使用redis作为分布式锁，就是给redis里写一个特殊的key value）。

语法：

pexpire key mseconds 毫秒级

返回值：1成功，0失败

此处的设定的过期时间，必须是针对已经存在的key设置，设置成功返回1，设置失败返回0。时间复杂度也是O(1)。

过期后get不到value。

5）ttl命令

ttl time to live 存活时间。网络原理IP协议报头中，有一个字段TTL。IP中的TTL不是用时间衡量过期的，而是用次数。

ttl是一个时间。查看当前key的过期时间还剩多少

pttl查询毫秒级的key的过期时间。

时间复杂度也是O(1)。

redis的key的过期策略【经典面试题】

redis的key的过期策略是怎么实现的？

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

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

redis整体的策略是:

1、定期删除：此处也需要结合定期删除的操作，每次抽出一部分验证过期时间，保证这个抽取检查的过程足够快。对于定期删除的时间，有明确的要求：因为redis是单线程的程序。主要的任务（处理每个命令的任务，刚才扫描过期的key）如果扫描过期key消耗的时间太多了，就可能导致正常处理请求命令就被阻塞了，产生了类似key *这样的效果。

2、惰性删除：假设这个key已经到过期时间了，但是暂时还没删它，key还存在，紧接着，后面有一次访问，正好用到了这个key，于是这次访问就会让redis服务器触发删除key的操作，同时在返回一个nil。

虽然有了上述两种策略结合，整体的效果一般，仍然可能会有很多过期的key被残留了，没有及时删除掉，redis为了对上述进行补充，还提供了一系列的内存淘汰机制。

1）redis中并没有采取定时器的方式来实现过期key删除

2）如果有多个key过期，也可以通过一个定时器来高效/节省cpu的前提下来处理多个key。

为啥redis没有采取这种定时器的方式呢？

很难考证为啥，个人的猜测：基于定时器实现，势必就要引入多线程了。redis早期版本就是奠定了单线程的基调，引入多线程打破了作者的初衷。

定时器的实现原理：

定时器：在某个时间到达之后，执行指定的任务

1、基于优先级队列/堆

正常的队列是先进先出。而优先级队列则是按照指定的优先级，先出。啥叫优先级高？自定义的。在redis过期key的场景中，就可以通过“过期时间越早，就是优先级越高”。现在假定有很多key设置了过期时间，就可以把这些key加入到优先级队列中，指定优先级规则是过期时间早的先出队列。队首元素就是最早要过期的key！此时定时器中只要分配分配一个线程，让这个线程取检查队首元素，看是否过期即可！如果队首元素没有过期，后续元素一定没过期。此时扫描线程不需要遍历所有key只盯住这一个队首元素即可！另外在扫描线程检查队首元素过期时间的时候，也不能检查太频繁。此时做法就是可以根据当前时刻和队首元素的过期时间设置一个等待。当时间差不多到了，系统再唤醒这个线程。此时扫描线程，不需要高频扫描队首元素，把CPU的开销也节省下来了。

万一在线程休眠的时候，来了一个新的任务是11：30要执行。可以在新任务添加的时候，唤醒一下刚才的线程，重新检查一下队首元素，再根据时间差距重新调整阻塞时间即可。

2、基于时间轮实现的定时器

把时间划分成很多小段（划分的粒度，看实际需求）。