当前位置: 首页 > news >正文

【redis】全局命令exists、del、expire、ttl(惰性删除和定期删除)

exists——判定 key 是否存在

语法:

exists key [key...]
# 返回值:key 存在的个数
  • 针对多个 key 来说,是非常有用的
  • 时间复杂度 O ( 1 ) O(1) O(1)image.png
    Redis 组织这些 key 就是按照哈希表的方式来组织的。Redis 支持很多数据结构指的是 value 可以是一些复杂的数据结构
    Redis 自身的这些键值对,是通过哈希表的方式来组织的,Redis 具体的值,又可以是一些数据结构
  • Redis 是一个客户端-服务器结构的程序,客户端和服务器之间通过网络来进行通信
  • 每次我们敲的命令,都是由 Redis 客户端包装成一个请求,发送给 Redis 服务器,服务器再返回响应
  • 因此最好不要把 key 分开写。分开写会产生更多轮次的网络通信,效率比较低,成本比较高

[!qoute] 封装和分用

  • 进行网络通信的时候,发送方发送一个数据,这个数据就要从应用层,到物理层,层层封装(每一层协议都要加上报头或者尾)==>发送一个快递,要包装一下,要包装好多层
  • 接收方收到一个数据,这个数据就要从物理层,到应用层,层层分用(把每一层协议中的报头或者尾给拆掉)==>收到一个快递,要拆快递,拆很多层
  • 这些过程都是要消耗时间,消耗 CPU

Redis 自身也非常清楚上述问题,所以 Redis 的很多命令都支持一次就能操作多个 key 的/多种操作

del——删除指定的 key

可以一次删除一个或者多个


语法:

del key [key...]
  • 时间复杂度 O ( 1 ) O(1) O(1)
  • 返回值:删除掉的 key 的个数

MySQL 中,删除类的操作

  • drop database
  • drop table
  • drop from
    这些都是非常危险的操作,一旦删除之后,数据就没了。但在 Redis 中,危险程度就小很多了
  • 因为 Redis 的主要应用场景,就是作为缓存,里面存的只是一个热点数据,而全量数据是在 MySQL 中。如果把 Redis 中的 key 删除了几个,问题不大,大不了再从 MySQL 中读就可以了。
  • 但是如果把所有的数据,或者一大半数据都干没了,这种影响就会很大。本来是靠 RedisMySQL 负重前行,Redis 没数据了,大部分请求就直接打给 MySQL 了,然后就容易把 MySQL 搞挂
  • 相比之下,如果是 MySQL 这样的数据,哪怕误删了一个数据,都可能影响是很大的
  • 但如果是把 Redis 作为数据库,此时误删数据的影响就大了

expire——给 key 设置过期时间

单位为秒

key 存活时间超过这个 expire 指定的值,就会被自动删除

  • 在很多业务场景,都是有时间限制的
    • 验证码。要实现验证码一分钟失效的功能,我们就可以把这个验证码信息存储到 Redis 中,将 expire 设置为 60,等到一分钟后 Redis 里面的验证码信息被删除,就查询不到了
    • 点外卖。优惠券,在指定时间有效
    • 分布式锁。基于 Redis 实现分布式锁,为了避免出现不能正确解锁的情况,通常都会在加锁的时候设置一下过期事假(所谓的使用 Redis 作为分布式锁,就是给 Redis 里写一个特殊的 key value

语法:

expire key seconds
pexpire key 毫秒
  • 对于计算机来说,秒是一个非常长的时间,下面的时间单位是毫秒

ttl——查询过期时间

time to live

在网络原理,IP 协议报头中,就有一个 TTL 字段

  • IP 中的 TTL 不是用时间衡量过期的,而是次数

查询当前 key 的过期时间还剩多少
语法:

ttl key    //秒
pttl key   //毫秒
  • 返回剩余过期时间
  • 返回 -1 表示没有关联过期时间
  • 返回 -2 表示 key 不存在

过期策略是如何实现的

#高频面试
一个 Redis 中可能同时存在很多很多 key,这些 key 中有很大一部分都有过期时间。此时,Redis 服务器怎么知道哪些 key 已经过期要被删除,哪些 key 还没过期?

  • 如果直接遍历所有的 key,显然是行不通的,效率非常低
  • Redis 整体的策略是两方面
    1. 定期删除
    2. 惰性删除

惰性删除

  • 假设这个 key 已经到达过期时间了,但是暂时还没删除它,key 还在
  • 紧接着,后面又一次访问,正好用到了这个 key,于是这次访问就会让 Redis 服务器触发删除 key 的操作,同时再放回一个 nil
  • 你去超市买水,正要付钱的时候,看了一眼日期,发现过期了,于是老板就说不卖了,于是就把这瓶水下架了,这就是“惰性删除
  • 老板也不清楚哪些过期了,哪些没过期,就在卖出的时候做一次检查,如果过期了就不卖了,如果还没过期,就继续卖

但显然,单靠惰性删除肯定是不靠谱的,一个超市这么多商品,怎么可能全去靠用户去检查,所以肯定还得要有一个辅助的机制——定期删除

定期删除

这个超市老板,要定期查看超市里面的商品,看是否有过期产品

  • 但是如果超市商品很多,那么每次遍历一遍就非常慢
  • 所以,每次抽取一部分,进行验证过期时间。保证抽取检查的过程足够快

为什么这对定期删除的时间有明确的要求呢?

  • 因为 Redis 是单线程程序,主要的任务是处理每个命令的任务(刚才扫描过期 key…)
  • 如果扫描过期 key 消耗的时间太多了,就可能导致正常处理请求命令就被阻塞了(产生了类似 key * 的效果)

虽然有了上述两种策略结合,但整体的效果仍一般。仍然有可能会有很多过期的 key 被残留了,没有及时删除掉

但是 Redis 为了对上述进行补充,还提供了一系列的内存淘汰策略

相关文章:

  • Java 深度复制对象:从基础到实战
  • Pytorch 第八回:卷积神经网络——GoogleNet模型
  • Vue 框架深度解析:源码分析与实现原理详解
  • C++修炼之路:初识C++
  • Cpu100%问题(包括-线上docker服务以及Arthas方式进行处理)
  • Android networkSecurityConfig 代码配置
  • Hadoop八股
  • Redis|Springboot集成Redis
  • React基础之useInperativehandlle
  • 【前端】【vue-i8n】【element】Element 框架国际化配置指南:从 element-ui 到 element-plus
  • 运行OpenManus项目(使用Conda)
  • 国家二级运动员证书有什么用·棒球1号位
  • QP 问题(Quadratic Programming, 二次规划)
  • QEMU源码全解析 —— 块设备虚拟化(2)
  • Scade 状态机 - 同步迁移
  • Maven安装和配置详细教程
  • 第十五届蓝桥杯省赛电子类单片机学习过程记录(客观题)
  • 游戏引擎学习第145天
  • 基于昇腾MindIE与GPUStack的大模型容器化部署从入门到入土
  • GPU编程实战指南01:CUDA编程极简手册
  • 中小型网站建设与管理/搜索网站排名优化
  • 正版视频素材网站/汕头网站建设技术外包
  • 电脑记事本做网站/关键词排名seo优化
  • 做五金的有哪些外贸网站/云客网平台
  • 网站建设年度报告/介绍网络营销
  • 域名服务网站建设科技公司/什么叫营销