我凭借这份PDF的复习思路,Redis从入门到精通,至少要看看这篇

本文详细介绍了Redis中的数据结构,包括String、Hash、List、Set和Sorted Set的使用场景与特点。还讨论了如何在海量Key中查找特定前缀的Key,以及如何通过Redis实现分布式锁和异步队列。此外,深入解析了Redis的持久化机制,如RDB和AOF的优缺点。最后,提到了面试和薪资谈判的建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

String

最基本的数据类型,其值最大可存储 512M,二进制安全(Redis 的 String 可以包含任何二进制数据,包含 jpg 对象等)。

Redis从入门到精通,至少要看看这篇

注:如果重复写入 key 相同的键值对,后写入的会将之前写入的覆盖。

Hash

String 元素组成的字典,适用于存储对象。

Redis从入门到精通,至少要看看这篇

List

列表,按照 String 元素插入顺序排序。其顺序为后进先出。由于其具有栈的特性,所以可以实现如“最新消息排行榜”这类的功能。

Redis从入门到精通,至少要看看这篇

Set

String 元素组成的无序集合,通过哈希表实现(增删改查时间复杂度为 O(1)),不允许重复。

Redis从入门到精通,至少要看看这篇

另外,当我们使用 Smembers 遍历 Set 中的元素时,其顺序也是不确定的,是通过 Hash 运算过后的结果。

Redis 还对集合提供了求交集、并集、差集等操作,可以实现如同共同关注,共同好友等功能。

Sorted Set

通过分数来为集合中的成员进行从小到大的排序。

Redis从入门到精通,至少要看看这篇

更高级的 Redis 类型

用于计数的 HyperLogLog、用于支持存储地理位置信息的 Geo。

从海量 Key 里查询出某一个固定前缀的 Key

假设 Redis 中有十亿条 Key,如何从这么多 Key 中找到固定前缀的 Key?

方法 1:使用 Keys [pattern]:查找所有符合给定模式 Pattern 的 Key

使用 Keys [pattern] 指令可以找到所有符合 Pattern 条件的 Key,但是 Keys 会一次性返回所有符合条件的 Key,所以会造成 Redis 的卡顿。

假设 Redis 此时正在生产环境下,使用该命令就会造成隐患,另外如果一次性返回所有 Key,对内存的消耗在某些条件下也是巨大的。

例:


keys test\* //返回所有以test为前缀的key 



方法 2:使用 SCAN cursor [MATCH pattern] [COUNT count]

注:

  • cursor:游标

  • MATCH pattern:查询 Key 的条件

  • Count:返回的条数

SCAN 是一个基于游标的迭代器,需要基于上一次的游标延续之前的迭代过程。

SCAN 以 0 作为游标,开始一次新的迭代,直到命令返回游标 0 完成一次遍历。

此命令并不保证每次执行都返回某个给定数量的元素,甚至会返回 0 个元素,但只要游标不是 0,程序都不会认为 SCAN 命令结束,但是返回的元素数量大概率符合 Count 参数。另外,SCAN 支持模糊查询。

例:


SCAN 0 MATCH test\* COUNT 10 //每次返回10条以test为前缀的key 



如何通过 Redis 实现分布式锁

分布式锁

分布式锁是控制分布式系统之间共同访问共享资源的一种锁的实现。如果一个系统,或者不同系统的不同主机之间共享某个资源时,往往需要互斥,来排除干扰,满足数据一致性。

分布式锁需要解决的问题如下:

  • 互斥性:任意时刻只有一个客户端获取到锁,不能有两个客户端同时获取到锁。

  • 安全性:锁只能被持有该锁的客户端删除,不能由其他客户端删除。

  • 死锁:获取锁的客户端因为某些原因而宕机继而无法释放锁,其他客户端再也无法获取锁而导致死锁,此时需要有特殊机制来避免死锁。

  • 容错:当各个节点,如某个 Redis 节点宕机的时候,客户端仍然能够获取锁或释放锁。

如何使用 Redis 实现分布式锁

使用 SETNX 实现,SETNX key value:如果 Key 不存在,则创建并赋值。

该命令时间复杂度为 O(1),如果设置成功,则返回 1,否则返回 0。

Redis从入门到精通,至少要看看这篇

由于 SETNX 指令操作简单,且是原子性的,所以初期的时候经常被人们作为分布式锁,我们在应用的时候,可以在某个共享资源区之前先使用 SETNX 指令,查看是否设置成功。

如果设置成功则说明前方没有客户端正在访问该资源,如果设置失败则说明有客户端正在访问该资源,那么当前客户端就需要等待。

但是如果真的这么做,就会存在一个问题,因为 SETNX 是长久存在的,所以假设一个客户端正在访问资源,并且上锁,那么当这个客户端结束访问时,该锁依旧存在,后来者也无法成功获取锁,这个该如何解决呢?

由于 SETNX 并不支持传入 EXPIRE 参数,所以我们可以直接使用 EXPIRE 指令来对特定的 Key 来设置过期时间。

用法:


EXPIRE key seconds 



Redis从入门到精通,至少要看看这篇

程序:


RedisService redisService = SpringUtils.getBean(RedisService.class); 

long status = redisService.setnx(key,"1"); 

if(status == 1){ 

 redisService.expire(key,expire); 

 doOcuppiedWork(); 

} 



这段程序存在的问题:假设程序运行到第二行出现异常,那么程序来不及设置过期时间就结束了,则 Key 会一直存在,等同于锁一直被持有无法释放。

出现此问题的根本原因为:原子性得不到满足。

解决:从 Redis 2.6.12 版本开始,我们就可以使用 Set 操作,将 SETNX 和 EXPIRE 融合在一起执行,具体做法如下:

  • EX second:设置键的过期时间为 Second 秒。

  • PX millisecond:设置键的过期时间为 MilliSecond 毫秒。

  • NX:只在键不存在时,才对键进行设置操作。

  • XX:只在键已经存在时,才对键进行设置操作。


SET KEY value \[EX seconds\] \[PX milliseconds\] \[NX|XX\] 



注:SET 操作成功完成时才会返回 OK,否则返回 nil。

有了 SET 我们就可以在程序中使用类似下面的代码实现分布式锁了:


RedisService redisService = SpringUtils.getBean(RedisService.class); 

String result = redisService.set(lockKey,requestId,SET\_IF\_NOT\_EXIST,SET\_WITH\_EXPIRE\_TIME,expireTime); 

if("OK.equals(result)"){ 

 doOcuppiredWork(); 

} 



如何实现异步队列

①使用 Redis 中的 List 作为队列

使用上文所说的 Redis 的数据结构中的 List 作为队列 Rpush 生产消息,LPOP 消费消息。

Redis从入门到精通,至少要看看这篇

此时我们可以看到,该队列是使用 Rpush 生产队列,使用 LPOP 消费队列。

在这个生产者-消费者队列里,当 LPOP 没有消息时,证明该队列中没有元素,并且生产者还没有来得及生产新的数据。

缺点:LPOP 不会等待队列中有值之后再消费,而是直接进行消费。

弥补:可以通过在应用层引入 Sleep 机制去调用 LPOP 重试。

②使用 BLPOP key [key…] timeout

BLPOP key [key …] timeout:阻塞直到队列有消息或者超时。

Redis从入门到精通,至少要看看这篇

Redis从入门到精通,至少要看看这篇

Redis从入门到精通,至少要看看这篇

缺点:按照此种方法,我们生产后的数据只能提供给各个单一消费者消费。能否实现生产一次就能让多个消费者消费呢?

③Pub/Sub:主题订阅者模式

发送者(Pub)发送消息,订阅者(Sub)接收消息。订阅者可以订阅任意数量的频道。

Redis从入门到精通,至少要看看这篇

Pub/Sub模式的缺点:消息的发布是无状态的,无法保证可达。对于发布者来说,消息是“即发即失”的。

此时如果某个消费者在生产者发布消息时下线,重新上线之后,是无法接收该消息的,要解决该问题需要使用专业的消息队列,如 Kafka…此处不再赘述。

Redis 持久化

什么是持久化

持久化,即将数据持久存储,而不因断电或其他各种复杂外部环境影响数据的完整性。

由于 Redis 将数据存储在内存而不是磁盘中,所以内存一旦断电,Redis 中存储的数据也随即消失,这往往是用户不期望的,所以 Redis 有持久化机制来保证数据的安全性。

Redis 如何做持久化

Redis 目前有两种持久化方式,即 RDB 和 AOF,RDB 是通过保存某个时间点的全量数据快照实现数据的持久化,当恢复数据时,直接通过 RDB 文件中的快照,将数据恢复。

RDB(快照)持久化

RDB持久化会在某个特定的间隔保存那个时间点的全量数据的快照。

RDB 配置文件,redis.conf:

save 900 1 #在900s内如果有1条数据被写入,则产生一次快照。 save 300 10 #在300s内如果有10条数据被写入,则产生一次快照 save 60 10000 #在60s内如果有10000条数据被写入,则产生一次快照

stop-writes-on-bgsave-error yes #stop-writes-on-bgsave-error : 如果为yes则表示,当备份进程出错的时候, 主进程就停止进行接受新的写入操作,这样是为了保护持久化的数据一致性的问题。

①RDB 的创建与载入

SAVE:阻塞 Redis 的服务器进程,直到 RDB 文件被创建完毕。SAVE 命令很少被使用,因为其会阻塞主线程来保证快照的写入,由于 Redis 是使用一个主线程来接收所有客户端请求,这样会阻塞所有客户端请求。

BGSAVE:该指令会 Fork 出一个子进程来创建 RDB 文件,不阻塞服务器进程,子进程接收请求并创建 RDB 快照,父进程继续接收客户端的请求。

子进程在完成文件的创建时会向父进程发送信号,父进程在接收客户端请求的过程中,在一定的时间间隔通过轮询来接收子进程的信号。

我们也可以通过使用 lastsave 指令来查看 BGSAVE 是否执行成功,lastsave 可以返回最后一次执行成功 BGSAVE 的时间。

②自动化触发 RDB 持久化的方式

自动化触发RDB持久化的方式如下:

  • 根据 redis.conf 配置里的 SAVE m n 定时触发(实际上使用的是 BGSAVE)。

  • 主从复制时,主节点自动触发。

  • 执行 Debug Reload。

  • 执行 Shutdown 且没有开启 AOF 持久化。

③BGSAVE 的原理

Redis从入门到精通,至少要看看这篇

启动:

  • 检查是否存在子进程正在执行 AOF 或者 RDB 的持久化任务。如果有则返回 false。

  • 调用 Redis 源码中的 rdbSaveBackground 方法,方法中执行 fork() 产生子进程执行 RDB 操作。

  • 关于 fork() 中的 Copy-On-Write。

fork() 在 Linux 中创建子进程采用 Copy-On-Write(写时拷贝技术),即如果有多个调用者同时要求相同资源(如内存或磁盘上的数据存储)。

他们会共同获取相同的指针指向相同的资源,直到某个调用者试图修改资源的内容时,系统才会真正复制一份专用副本给调用者,而其他调用者所见到的最初的资源仍然保持不变。

④RDB 持久化方式的缺点

RDB 持久化方式的缺点如下:

  • 内存数据全量同步,数据量大的状况下,会由于 I/O 而严重影响性能。

  • 可能会因为 Redis 宕机而丢失从当前至最近一次快照期间的数据。

AOF 持久化:保存写状态

AOF 持久化是通过保存 Redis 的写状态来记录数据库的。

相对 RDB 来说,RDB 持久化是通过备份数据库的状态来记录数据库,而 AOF 持久化是备份数据库接收到的指令:

  • AOF 记录除了查询以外的所有变更数据库状态的指令。

  • 以增量的形式追加保存到 AOF 文件中。

AOF 持久化:保存写状态

AOF 持久化是通过保存 Redis 的写状态来记录数据库的。

相对 RDB 来说,RDB 持久化是通过备份数据库的状态来记录数据库,而 AOF 持久化是备份数据库接收到的指令:

  • AOF 记录除了查询以外的所有变更数据库状态的指令。

  • 以增量的形式追加保存到 AOF 文件中。

开启 AOF 持久化

①打开 redis.conf 配置文件,将 appendonly 属性改为 yes。

②修改 appendfsync 属性,该属性可以接收三种参数,分别是 always,everysec,no。

always 表示总是即时将缓冲区内容写入 AOF 文件当中,everysec 表示每隔一秒将缓冲区内容写入 AOF 文件,no 表示将写入文件操作交由操作系统决定。

一般来说,操作系统考虑效率问题,会等待缓冲区被填满再将缓冲区数据写入 AOF 文件中。

总结

一般像这样的大企业都有好几轮面试,所以自己一定要花点时间去收集整理一下公司的背景,公司的企业文化,俗话说「知己知彼百战不殆」,不要盲目的去面试,还有很多人关心怎么去跟HR谈薪资。

这边给大家一个建议,如果你的理想薪资是30K,你完全可以跟HR谈33~35K,而不是一下子就把自己的底牌暴露了出来,不过肯定不能说的这么直接,比如原来你的公司是25K,你可以跟HR讲原来的薪资是多少,你们这边能给到我的是多少?你说我这边希望可以有一个20%涨薪。

最后再说几句关于招聘平台的,总之,简历投递给公司之前,请确认下这家公司到底咋样,先去百度了解下,别被坑了,每个平台都有一些居心不良的广告党等着你上钩,千万别上当!!!

提供【免费】的Java架构学习资料,学习技术内容包含有:Spring,Dubbo,MyBatis, RPC, 源码分析,高并发、高性能、分布式,性能优化,微服务 高级架构开发等等。

Java全套进阶资料点这里免费领取

还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。
件中。

总结

一般像这样的大企业都有好几轮面试,所以自己一定要花点时间去收集整理一下公司的背景,公司的企业文化,俗话说「知己知彼百战不殆」,不要盲目的去面试,还有很多人关心怎么去跟HR谈薪资。

这边给大家一个建议,如果你的理想薪资是30K,你完全可以跟HR谈33~35K,而不是一下子就把自己的底牌暴露了出来,不过肯定不能说的这么直接,比如原来你的公司是25K,你可以跟HR讲原来的薪资是多少,你们这边能给到我的是多少?你说我这边希望可以有一个20%涨薪。

最后再说几句关于招聘平台的,总之,简历投递给公司之前,请确认下这家公司到底咋样,先去百度了解下,别被坑了,每个平台都有一些居心不良的广告党等着你上钩,千万别上当!!!

提供【免费】的Java架构学习资料,学习技术内容包含有:Spring,Dubbo,MyBatis, RPC, 源码分析,高并发、高性能、分布式,性能优化,微服务 高级架构开发等等。

Java全套进阶资料点这里免费领取

还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值