⭐️前言⭐️

本文主要介绍Redis的通用命令

🍉欢迎点赞 👍 收藏 ⭐留言评论

🍉博主将持续更新学习记录收获，友友们有任何问题可以在评论区留言

🍉博客中涉及源码及博主日常练习代码均已上传GitHub

---

🍅通用命令

🍅1.启动和停止服务器

启动redis服务器

redis-server /etc/redis/redis.conf

停止redis服务器

先通过netstat或者ps查询redis服务器的pid

netstat -anp | grep redis
ps aux | grep redis

再根据pid进行kill即可

kill 进程id

连接Redis服务器

在输入Redis命令之前，需要先连接上Redis服务器

redis-cli

断开连接

ctrl+D

🍅2.get和set

Redis是按照键值对的方式来存储数据的，通过get和set这两个核心的命令来存储键值对和取值

set key value	 	 //key和value都是字符串

Redis中的命令不区分大小写，而且对于上述这里的key和value，不需要加上引号，就是表示字符串的类型。

get key      		 //根据key获取value

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

示例：

🍅3.全局命令

Redis支持很多种数据结构，整体上来说，Redis是键值对结构，key固定就是字符串，value实际上会有很多种类型（包括字符串、哈希表、列表、集合、有序集合等），操作不同的数据结构，就会有不同的命令；

全局命令，就是能够搭配任意一个数据结构来使用的命令。

keys

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

语法：

keys pattern

返回所有满足样式(pattern)的key，支持如下统配样式。

• h?llo匹配hello、hallo等，?匹配任意一个字符
• h*llo匹配hllo、heeeello等，?匹配任意个任意字符
• h[abe]llo匹配hallo、hbllo、hello等，[abe]只能匹配到a、b、e，相当于给了固定选项
• h[^e]llo匹配除hello以外的，[^e]排除e，只有e匹配不了，其他的都能匹配
• h[a-c]llo匹配hallo、hbllo、hcllo，[a-c]匹配a-c这个范围内的字符，包含两侧边界

示例：

注意事项：

keys命令的时间复杂度是O(N)，所以在生产环境上，一般都会禁止使用keys命令，尤其是keys *(该命令会查询redis中的所有key)

生产环境上的key可能会非常多，而Redis是一个单线程的服务器，执行keys *的时间非常长，就会使redis服务器被阻塞了，无法给其他客户端提供服务。

Redis经常会用于做缓存，挡在MySQL前面，万一redis被一个keys *阻塞住了，此时其他的查询redis操作就超时了，此时这些请求就会直接查数据库。如果一大波请求直接过来，就会导致MySQL措手不及，很容易就挂了，这样整个系统基本就瘫痪了。

exists

判断key是否存在

语法：

exists key [此处key可以是一个或者多个，用空格隔开]

时间复杂度：O(1)

返回值：key存在的个数

示例：

---

exists key1 key2 和分开写exists key1;exists key2有什么区别呢？

redis是一个客户端-服务器结构的程序，客户端和服务器之间通过网络来进行通信，如果分开的话，会产生更多轮次的网络通信，效率更低。

提到网络通信，就得提一下封装和分用

封装：进行网络通信的时候，发送方发送一个数据，这个数据就要从应用层到物理层层层封装，每一层协议都要加上报头或者尾，类似于我们发一个快递，需要包装一下，要包装好几层

**分用：**接收方收到一个数据，这个数据就要从物理层到应用层层层分用，把每一层协议中的报头或者尾给拆掉，类似于我们收到快递，要拆快递，拆很多层

del

删除指定的key

语法：

del key [此处key可以是一个或者多个]

时间复杂度：O(1)

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

示例：

---

在MySQL中，删除类的操作比如drop database、drop table、delete from...都是非常危险的操作，一旦删除了之后，数据就没了；

而redis主要的应用场景，就是作为缓存，此时redis里存的只是热点数据，全量数据是在MySQL数据库中，此时如果把redis中的key删除了几个，一般来说，问题都不大；

但是当然如果把所有的数据或者一大半数据都删除了，这种影响会很大；本来redis是帮MySQL负重前行的，redis没数据了，大部分的请求就直接打给MySQL了，然后很容易把MySQL搞挂

相比之下，如果是MySQL这样的数据，哪怕误删了一个数据，都可能是影响很大的

如果是把redis作为数据库，此时误删数据的影响就很大了；

如果是把redis作为消息队列(mq)，这种情况误删数据影响大不大，就需要具体问题具体分析了

expire

为指定的key添加秒级的过期时间(Time To Live ；TTL)

这里的key必须是针对已经存在的key设置

key存活时间超出这个指定的值，就会被自动删除

语法：

expire key seconds
pexpire key 毫秒

时间复杂度：O(1)

返回值：1表示设置成功，0表示设置失败

示例见ttl处

---

过期时间这个实现，有很多的业务场景：

1、在进行登录时，经常会用到手机验证码，该验证码5分钟内有效；

2、点外卖，有优惠券在指定时间内有效；

3、基于redis实现分布式锁，为了避免出现不能正确解锁的情况，通常都会在加锁的时候设置一下过期时间（所谓的使用redis作为分布式锁，就是给redis里写一个特殊的key value）

ttl

获取指定key的过期时间，秒级 Time To Live TTL

语法：

ttl key

pttl key毫秒级

时间复杂度：O(1)

返回值：查询当前key的剩余过期时间，-1表示没有关联过期时间，-2表示key不存在（时间到被自动删除了）

示例：

type

返回key对应value的数据类型

语法：

type key

时间复杂度：O(1)

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

示例：

小结

当前已经学习了redis中几个基本的全局命令：

keys：用来查看匹配规则的key

exists：用来判定指定key是否存在

del：删除指定的key

expire：给key设置过期时间

ttl：查询key的过期时间

type：查询key对应的value类型

🍅4.key的过期策略【经典面试题】

一个redis中可能同时存在很多很多的key，这些key中可能有很大一部分都有过期时间，此时redis服务器咋知道哪些key已经过期要被删除，哪些key还没过期呢？如果直接遍历所有的key，效率很低显然是行不通的。

Redis整体的策略是定期删除和惰性删除相结合：

定期删除：

每次抽取一部分，进行验证过期时间，需要保证这个抽取检查的过程足够快。

为什么这里对于定期删除的时间有明确的要求呢，这是因为redis是单线程的程序，主要的任务是处理每个命令，还有包括扫描过期的key等，如果扫描过期的key消耗的时间太多了，就可能导致正常处理请求的命令就被阻塞了(产生了类似于执行keys *这样的效果)

惰性删除：

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

这个过程就类似于我们去超市买一瓶饮料的场景，我拿到了饮料，在正要付钱的时候看了一眼生产日期，发现过期了，于是老板就没卖这瓶饮料；因为超市里面商品很多，老板也不知道哪些商品已经过期了，而在客户付款的时候发现商品过期了，老板再进行物品删除，这个场景和惰性删除类似。

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

🍅5.定时器的实现原理

定时器就类似于一个闹钟，在某个时间到达之后，会执行指定的任务；

定时器的实现方式有以下两种（redis不是基于以下两种，但和第二种的实现有相像之处）：

1、基于优先级队列/堆

正常的队列是先进先出，而优先级队列则是按照指定的优先级先出

这里的优先级是可以自定义的，在redis过期key的场景中，就可以通过“过期时间越早，优先级越高”来进行优先级定义。

现在假定有很多key设置了过期时间，就可以把这些key加入到一个优先级队列中，指定优先级规则是过期时间早的先出队列，那么队首元素就是最早的要过期的key。

定时器中只要分配一个线程，让这个线程去检查队首元素，看是否过期即可，如果队首元素还没过期，后续元素一定没过期。（此时扫描线程不需要遍历所有key，就只盯住这一个队首元素即可）

另外在扫描线程检查队首元素过期时间的时候，也不能检查的太频繁，此时的做法就是可以根据当前时刻和队首元素的过期时间，设置一个等待，当时间差不多到了，系统再唤醒这个线程。（此时扫描线程也不需要高频扫描队首元素，把CPU的开销也节省下来了）

万一线程在休眠的时候，来了一个新的任务，这时候需要唤醒一下刚才的线程，重新检查一下队首元素，再根据时间差距重新调整阻塞时间即可。

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

这种方式是把时间划分成很多小段（划分的粒度要看实际需求），每个小段上都挂着一个链表，链表的每个节点都代表一个要执行的任务。

假设需要添加一个key，这个key在300ms之后过期，就会放在第三个小段中；

此时这个指针，就会每隔固定的时间间隔（此处约定是100ms）走到下一个格子，每次走到一个格子，就会把这个格子上链表的任务尝试执行一下。

对于时间轮来说，每个格子是多少时间，一共多少个格子，都是需要根据实际场景，灵活调配的。

此处需要注意，Redis并没有采取上述的方案，但是要了解这两种方案，都是属于高效的定时器的实现方式，很多场景可能都会用到；

在Redis源码中，有一个比较核心的机制，叫做事件循环，其实现就和时间轮的实现比较相似

---

⭐️最后的话⭐️
总结不易，希望uu们不要吝啬你们的👍哟(＾Ｕ＾)ノ~ＹＯ！！如有问题，欢迎评论区批评指正😁