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)
标签：通用,过期,Redis,redis,value,命令,时间,key From： https://blog.csdn.net/m0_47017197/article/details/139203141keys: 用来查看匹配规则的 key
exists: 用来判定指定 key 是否存在
del: 删除指定的 key
expire: 给 key 设置过期时间,
ttl: 查询 key 的过期时间.
type: 查询 key 对应的 value 的类型
【使用 keys 的风险~
del 的风险
redis key 过期策略如何实现~
定时器的实现思路】