0.Redis 实战操作

通过 redis-cli 客户端和 redis 服务器交互

涉及到很多的 redis 的命令

【redis 的命令非常非常多!!!

1.掌握常用命令(多操作多练习)

2.学会使用 redis 的文档->

阅读文档, 是程序猿的基操!!
redis 的命令非常非常多!!!
1.掌握常用命令(多操作多练习)
2.学会使用 redis 的文档
任何一个工具软件,去查找相关资料,一定是官方网站!!!

【Redis - The Real-time Data Platform】【Commands | Docs (redis.io)】

1.Redis 中最核心的两个命令.

redis 是按照键值对的方式存储数据的.

get根据 key 来取 value

set把 key 和 value 存储进去

必须要先进入 redis-cli 客户端程序,才能输入 redis 命令

• set key value【key 和 value 都是字符串】 

对于上述这里的 key value,不需要加上引号, 就是表示字符串的类型~~

当然,如果要是给 key 和 value 加上引号, 也是可以的(单引号或者双引号都行)
redis 中的命令不区分大小写.

• get key

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

2.Redis全局命令 

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

Redis 支持很多种数据结构~~

整体上来说, Redis 是键值对结构.

key 固定就是字符串.value 实际上会有多种类型【字符串、哈希表、列表、集合、有序集合】

2.1 keys 用来查询当前服务器上匹配的 key

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

1.pattern

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

【符合的保留 不符合的排除】

• pattern具体怎么写，支持哪些通配符 ？？？

【注意事项】

keys 命令的时间复杂度是 O(N)

所以,在生产环境上,一般都会禁止使用 keys 命令.尤其是大杀器 keys* （査询 redis 中所有的 key !!!）

生产环境上的 key 可能会非常多!!

而 redis 是一个单线程的服务器,执行 keys *的时间非常长,就使 redis 服务器被阻塞了无法给其他客户端提供服务!!（这样的后果可能是灾难性的~~）

redis 经常会用于做缓存.

挡在mysql前面,替mysql负重前行的人~~万一redis 被一个 keys*阻塞住了,此时其他的査询 redis 操作就超时了,此时这些请求就会直接查数据库~~突然一大波请求过来了,mysql措手不及,就容易挂了~~整个系统就基本瘫痪了

如果你要是没能及时发现,及时恢复的话,后果很严重！！！~~

3.生产环境 (线上环境)

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

1.办公环境

办公环境(入职公司之后, 公司给你发个电脑)

笔记本(windows,mac)/台式机

现在办公电脑,一般 8C16G512G

2.开发环境

开发环境有的时候,开发环境和办公环境是一个~~

有的时候,开发环境是单独的服务器.【28C128G4T配置更高】

做前端/做客户端, 一般来说, 开发环境就是办公环境了

后端来说,很可能是单独的服务器.

有的后端程序,会比较复杂~~

1.编译一次时间特别久(C++)=>C++ 23 オ会引入 module(#include 要接锅)使用高性能的服务器,进行编译~~

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

我们之前做的商业搜索, 我们的服务器通常启动起来要吃 100G 的内存~~

3.有的程序比较依赖 linux,在 windows 环境搭不起来

3.测试环境

测试工程师使用的

28C128G4T

4.线上环境/生产环境

(办公环境, 开发环境, 测试环境, 也统称为 线下环境,外界用户无法访问到的)

线上环境则是 外界用户 能够访问到的,

一旦生产环境上出问题,一定会对于用户的使用产生影响!!

直接的影响到公司营收!!!

很多公司的营收都是靠广告,广告一般是按照 展示/点击 次数来计费的~~

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

5.exists

exists 判定 key 是否存在

EXISTS key [key ...](可以判断1个key，也可以判断多个key)

• 键值对存储的体系中 (类似于 哈希表)->key 得是唯一的~~
• 返回值:key 存在的个数。->针对多个 key 来说, 是非常有用的~~
• 时间复杂度:O(1)
• redis 组织这些 key 就是按照 哈希表 的方式来组织的
• redis 支持很多数据结构 =>指的是一个 value 可以是一些复杂的数据结构.
  redis 自身的这些键值对, 是通过 哈希表 的方式来组织的.
  redis 具体的某个值,又可以是一些数据结构.
• redis 是一个 客户端 服务器 结构的程序
  客户端和服务器之间通过网络来进行通信!
• 
• 
• 分开的写法是两次请求两次响应，而一起写是一次请求1此响应，网络通信基于其他来说效率低
• 封装和分用
  进行网络通信的时候,发送方发送一个数据,这个数据就要从应用层, 到物理层, 层层封装(每一层协议都要加上报头或者尾)=>发一个快递,要包装一下,要包装好几层
  接收方收到一个数据,这个数据就要从物理层,到应用层层层分用(把每一层协议中的报头或者尾给拆掉)=>收到一个快递,要拆快递,要拆很多层
  网卡 是 IO 设备~~
  更何况,你的客户端和服务器不一定在一个主机上,中间可能隔着很远~~（网络传输消耗的时间更多了）
  redis 自身也非常清楚上述问题.redis 的很多命令都是支持一次就能操作多个 key 的/多种操作
• 快慢要有参照物

6.del-删除指定的key

7.expire -给指定的 key 设置过期时间

给指定的 key 设置过期时间,key 存活时间超出这个指定的值, 就会被自动删除.

设置的时间单位是 秒

【典型的应用场景】

很多业务场景,是有时间限制的.
手机验证码~~ 该验证码,5 分钟内有效~~
点外卖,优惠券~在指定时间之内有效~~
基于 redis 实现 分布式锁,为了避免出现不能正确解锁的情况, 通常都会在加锁的时候设置一下过期时间.(所谓的使用 redis 作为分布式锁,就是给 redis 里写一个特殊的 key value)

EXPIRE key seconds

对于计算机来说,秒是一个非常长的时间~~

pexpire key 毫秒 

此处的设定过期时间,必须是针对已经存在的 key 设置设置成功返回 1,设置失败返回 0. 

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

 8.ttl 【time to live】查询过期时间

查看当前 key 的过期时间还剩多少 

网络原理,IP 协议.
IP 协议报头中,就有一个字段,TTL
IP 中的 TTL 不是用时间衡量过期的,而是用次数

返回-1表示没有设置过期时间

返回-2表示key不存在

• redis 的 key 的过期策略

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

一个 redis 中可能同时存在很多很多 key.

这些 key 中可能有很大一部分都有过期时间.

此时,redis 服务器咋知道哪些key 已经过期要被删除, 哪些 key 还没过期?? 

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

redis 整体的策略是
1.定期删除（此处也需要结合定期删除的操作~~）->(每次抽取一部分,进行验证过期时间~~保证这个抽取检查的过程,足够快!!)【不是一次删除完】

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

虽然有了上述两种策略结合,整体的效果一般~~

仍然可能会有很多过期的 key 被残留了,没有及时删除掉~~

【定时删除说法是错误的】

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

2.如果有多个 key 过期,也可以通过一个定时器来高效/节省cpu的前提下来处理多个 key ~~ （基于 优先级队列 或者 基于 时间轮 都可以实现比较高效的定时器~~）

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

很难考证为什么.

有可能是因为基于定时器实现,势必就要引入多线程了.
redis 早期版本就是奠定了单线程的基调~~引入多线程就打破了作者的初衷~~

2.惰性删除

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

• 定时器的实现原理

1.基于优先级队列/堆

正常的队列是先进先出.

优先级队列则是按照指定的优先级，先出

啥叫优先级高?自定义的~~

在 redis 过期 key 的场景中,就可以通过"过期时间越早,就是优先级越高"

现在假定有很多 key 设置了过期时间.

就可以把这些 key 加入到一个优先级队列中,指定优先级规则是过期时间早的,先出队列.

队首元素,就是最早的要过期的key!!

key1: 12:00
key2: 13:00
key3: 14:00

此时定时器中只要分配一个线程,让这个线程去检查队首元素, 看是否过期即可!!

如果队首元素还没过期,后续元素一定没过期!

此时 扫描线程 不需要遍历所有 key 只盯住这一个队首元素即可!!

另外在扫描线程检查队首元素过期时间的时候,也不能检查的太频繁~~

此时做法就是可以根据当前时刻和队首元素的过期时间,设置一个等待~~

当时间差不多到了,系统再唤醒这个线程

此时 扫描线程 不需要高频扫描队首元素.把 cpu 的开销也节省下来了

万一在线程休眠的时候,来了一个新的任务,是 11:30 要执行~~

可以在新任务添加的时候,唤醒一下刚才的线程~~ 重新检査一下队首元素,再根据时间差距重新调整阻塞时间即可.

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

把时间划分成很多小段~~(划分的粒度,看实际需求)

此处大家一定要注意!!
Redis 并没有采取上述的方案!!
但是要了解这两种方案,都是属于高效的定时器的实现方式, 很多场景可能都会用到.
在 Redis 源码中,有一个比较核心的机制,是 事件循环

9.type

type key

返回 key 对应的数据类型。
此处 redis 所有的 key 都是 string
key 对应的 value 可能会存在多种类型~~none,string,list,set,zset,hash and stream..

lpush相当于链表的头插一样

redis 作为消息队列的时候,使用这个类型的 value
在 redis 中,上述类型操作方式差别很大,使用的命令,都是完全不同的.
type的时间复杂度也是O(1) 

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

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

del: 删除指定的 key

expire: 给 key 设置过期时间,

ttl: 查询 key 的过期时间.

type: 查询 key 对应的 value 的类型 

【使用 keys 的风险~
del 的风险
redis key 过期策略如何实现~
定时器的实现思路】