继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

redis 面试题(2020持续更新)

Robot_sh
关注TA
已关注
手记 6
粉丝 6
获赞 17

1.redis 是什么?

>redis 是 nosql(也是个巨大的 map) 单线程,但是可处理 1 秒 10w 的并发(数
据都在内存中)
使用 java 对 redis 进行操作类似 jdbc 接口标准对 mysql,有各类实现他的实现
类,我们常用的是 druid
其中对 redis,我们通常用 Jedis(也为我们提供了连接池 JedisPool)
在 redis 中,key 就是 byte
redis 的数据结构(value):
String,list,set,orderset,hash
每种数据结构对应不同的命令语句

2.redis 怎么使用?

>先安装好 redis,然后运行,在 pom 文件中引入依赖,在要使用 redis 缓存的类
的 mapper.xml 文件配置 redis 的全限定名。引入 redis 的 redis.properties 文
件(如果要更改配置就可以使用)

3.应用场景

>list(双向链表)

>1 可以使用 redis 的 list 模拟队列,堆,栈

>2 朋友圈点赞(一条朋友圈内容语句,若干点赞语句)
规定:朋友圈内容的格式:

>1,内容: user❌post:x content 来存储;点赞: post❌good list 来存储;(把相应头像取出来显示)

4.为什么 redis 是单线程的都那么快

  • 1.数据存于内存
  • 2.用了多路复用 I/O
  • 3.单线程

5.redis 也可以进行发布订阅消息吗?

>可以,(然后可以引出哨兵模式(后面会讲)怎么互相监督的,就是因为每隔 2
秒哨兵节点会发布对某节点的判断和自身的信息到某频道,每个哨兵订阅该频道
获取其他哨兵节点和主从节点的信息,以达到哨兵间互相监控和对主从节点的监
控)和很多专业的消息队列系统(例如 Kafka、RocketMQ)相比,Redis 的发
布订阅略显粗糙,例如无法实现消息堆积和回溯。但胜在足够简单

6.redis 能否将数据持久化,如何实现

能,将内存中的数据异步写入硬盘中,两种方式:RDB(默认)和 AOF

RDB 持久化原理:通过 bgsave 命令触发,然后父进程执行 fork 操作创建
子进程,子进程创建 RDB 文件,根据父进程内存生成临时快照文件,完成后对
原有文件进行原子替换(定时一次性将所有数据进行快照生成一份副本存储在硬
盘中)

>优点:是一个紧凑压缩的二进制文件,Redis 加载 RDB 恢复数据远远快于 AOF
的方式。

>缺点:由于每次生成 RDB 开销较大,非实时持久化,

AOF 持久化原理:开启后,Redis 每执行一个修改数据的命令,都会把这
个命令添加到 AOF 文件中。

>优点:实时持久化。

>缺点:所以 AOF 文件体积逐渐变大,需要定期执行重写操作来降低文件体积,
加载慢

7.主从复制模式下,主挂了怎么办?

>redis 提供了
哨兵模式(高可用)
何谓哨兵模式?就是通过哨兵节点进行自主监控主从节点以及其他哨兵节点,发
现主节点故障时自主进行故障转移

8.哨兵模式实现原理?(2.8 版本或更高才有)

1.三个定时监控任务:

  • 1.1 每隔 10s,每个 S 节点(哨兵节点)会向主节点和从节点发送 info 命令获
    取最新的拓扑结构
  • 1.2 每隔 2s,每个 S 节点会向某频道上发送该 S 节点对于主节点的判断以及当
    前 Sl 节点的信息,
    同时每个 Sentinel 节点也会订阅该频道,来了解其他 S 节点以及它们对主节点
    的判断(做客观下线依据)
  • 1.3 每隔 1s,每个 S 节点会向主节点、从节点、其余 S 节点发送一条 ping 命令
    做一次心跳检测(心跳检测机制),来确认这些节点当前是否可达

2.主客观下线

  • 2.1 主观下线:根据第三个定时任务对没有有效回复的节点做主观下线处理
  • 2.2 客观下线:若主观下线的是主节点,会咨询其他 S 节点对该主节点的判断,
    超过半数,对该主节点做客观下线

3.选举出某一哨兵节点作为领导者

  • 来进行故障转移。选举方式:raft
    算法。每个 S 节点有一票同意权,哪个 S 节点做出主观下线的时候,就会询问其
    他 S 节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客
    观下线,谁成为领导者

9.redis 集群(采用虚拟槽方式,高可用)原理(和哨兵模式原理类似,3.0 版本或以上才有)

1.Redis 集群内节点通过 ping/pong 消息实现节点通信,消息不但可以传播节
点槽信息,还可以传播其他状态如:主从状态、节点故障等。因此故障发现也是
通过消息传播机制实现的,主要环节包括:主观下线(pfail)和客观下线(fail)

2.主客观下线:

  • 2.1 主观下线:集群中每个节点都会定期向其他节点发送 ping 消息,接收节点
    回复 pong 消息作为响应。如果通信一直失败,则发送节点会把接收节点标记为
    主观下线(pfail)状态。
  • 2.2 客观下线:超过半数,对该主节点做客观下线
  • 3.主节点选举出某一主节点作为领导者,来进行故障转移。
  • 4.故障转移(选举从节点作为新主节点)

10.缓存更新策略(即如何让缓存和 mysql 保持一致性)?

10.1 key 过期清除(超时剔除)策略

>惰性过期(类比懒加载,这是懒过期):只有当访问一个 key 时,才会判断该 key
是否已过期,过期则清除。该策略可以最大化地节省 CPU 资源,却对内存非常
不友好。极端情况可能出现大量的过期 key 没有再次被访问,从而不会被清除,
占用大量内存。
定期过期:每隔一定的时间,会扫描一定数量的数据库的 expires 字典中一定数
量的 key,并清除其中已过期的 key。该策略是前两者的一个折中方案。通过调
整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得 CPU 和
内存资源达到最优的平衡效果。
(expires 字典会保存所有设置了过期时间的 key 的过期时间数据,其中,key 是
指向键空间中的某个键的指针,value 是该键的毫秒精度的 UNIX 时间戳表示的
过期时间。键空间是指该 Redis 集群中保存的所有键。)
问:比如这么个场景,我设计了很多 key,过期时间是 5 分钟,当前内存占用率
是 50%。但是 5 分钟到了,内存占用率还是很高,请问为什么?
Redis 中同时使用了惰性过期和定期过期两种过期策略,即使过期时间到了,但
是有部分并没有真正删除,等待惰性删除。
为什么有定期还要有惰性呢?其实很简单,比如 10 万个 key 就要过期了,Redis
默认是 100ms 检查一波。如果他检查出 10 万个即将要清除,那他接下来的时
间基本都是在干这些清空内存的事了,那肯定影响性能,所以他只会部分删除,
剩下的等惰性

10.2 Redis 的内存淘汰策略

Redis 的内存淘汰策略是指在 Redis 的用于缓存的内存不足时,怎么处理需要新
写入且需要申请额外空间的数据。

  • noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
  • allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用
    的 key。
  • allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个
    key。
  • volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,
    移除最近最少使用的 key。
  • volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空
    间中,随机移除某个 key。
  • volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,
    有更早过期时间的 key 优先移除

11.如何防止缓存穿透?

(缓存穿透指的是查询一个根本不存在的数据,缓存层不命中,又去查存储层,
又不命中。但如果有大量这种查询不存在的数据的请求过来,会对存储层有较大
压力,若是恶意攻击,后果就)

  • 采用布隆过滤器,将所有可能存在的数据存到一个bitMap中,不存在的数据就会进行拦截。
  • 对查询结果为空的情况也进行缓存,缓存时间设置短一点,不超过5分钟。

12.无底洞优化?

>造成原因:redis 分布式越来越多,导致性能反而下降,因为键值分布到更多的
节点上,所以无论是 Memcache 还是 Redis 的分布式,批量操作通常需要从不
同节点上获取,相比于单机批量操作只涉及一次网络操作,分布式批量操作 会
涉及多次网络时间。 即分布式过犹不及。

>用一句通俗的话总结就是,更多的节点不代表更高的性能,所谓“无底 洞”就是说投入越多不一定产出越多。但是分布式又是不可以避免的,因为 访问量和数据量越来越大,一个节点根本抗不住,所以如何高效地在分布式缓存中批量操作是一个难点
优化思路

命令本身的优化,例如优化SQL语句等

  • 减少网络通信次数
  • 降低接入成本,例如客户端使用长连/连接池、NIO等

这里我们假设命令、客户端连接已经为最优,重点讨论减少网络操作次数
以Redis批量获取n个字符串为例,有三种实现方法,如下图所示:

  • 客户端n次get:n次网络+n次get命令本身
  • 客户端1次pipeline get:1次网络+n次get命令本身
  • 客户端1次mget:1次网络+1次mget命令本身

13.雪崩优化

>如果缓存层由于某些原因不能提供服务,于是所有的请求都会达到存储层,存储
层的调用量会暴增,造成存储层也会级联宕机的情况

  • 1、保持缓存层服务器的高可用。
    –监控、集群、哨兵。当一个集群里面有一台服务器有问题,让哨兵踢出去。
  • 2、依赖隔离组件为后端限流并降级。
    比如推荐服务中,如果个性化推荐服务不可用,可以降级为热点数据。
  • 3、提前演练。
    演练 缓存层crash后,应用以及后端的负载情况以及可能出现的问题。
    对此做一些预案设定。

14.热点 key 优化

>当前 key 是一个热点 key(例如一个热门的娱乐新闻),并发量非常大

  • 1、互斥锁:
    只允许一个请求重建缓存。
    其他请求等待缓存重建执行完,重新从缓存获取数据即可。

  • 2、用户过期
    “物理”不过期,
    逻辑设置过期时间(根据上一次更新时间,构建一个队列,主动去更新)

15.Redis 持久化机制

Redis 是一个支持持久化的内存数据库,通过持久化机制把内存中的数据同步到
硬盘文件来保证数据持久化。当 Redis 重启后通过把硬盘文件重新加载到内存,
就能达到恢复数据的目的。
实现:单独创建 fork()一个子进程,将当前父进程的数据库数据复制到子进程的
内存中,然后由子进程写入到临时文件中,持久化的过程结束了,再用这个临时
文件替换上次的快照文件,然后子进程退出,内存释放。
>RDB 是 Redis 默认的持久化方式。按照一定的时间周期策略把内存的数据以快
照的形式保存到硬盘的二进制文件。即 Snapshot 快照存储,对应产生的数据文
件为 dump.rdb,通过配置文件中的 save 参数来定义快照的周期。( 快照可以
是其所表示的数据的一个副本,也可以是数据的一个复制品。

>AOF:Redis 会将每一个收到的写命令都通过 Write 函数追加到文件最后,类似
于 MySQL 的 binlog。当 Redis 重启是会通过重新执行文件中保存的写命令来
在内存中重建整个数据库的内容。
当两种方式同时开启时,数据恢复 Redis 会优先选择 AOF 恢复

16 缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题

一、缓存雪崩
>我们可以简单的理解为:由于原有缓存失效,新缓存未到期间
(例如:我们设置缓存时采用了相同的过期时间,在同一时刻出现大面积的缓存
过期),所有原本应该访问缓存的请求都去查询数据库了,而对数据库 CPU 和内
存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整
个系统崩溃。

>解决办法:
大多数系统设计者考虑用加锁( 最多的解决方案)或者队列的方式保证来保证
不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落
到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开。

二、缓存穿透
>缓存穿透是指用户查询数据,在数据库没有,自然在缓存中也不会有。这样就导
致用户查询的时候,在缓存中找不到,每次都要去数据库再查询一遍,然后返回
空(相当于进行了两次无用的查询)。这样请求就绕过缓存直接查数据库,这也
是经常提的缓存命中率问题。
>解决办法;

  • 最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的
    bitmap 中,一个一定不存在的数据会被这个 bitmap 拦截掉,从而避免了对底
    层存储系统的查询压力。

  • 另外也有一个更为简单粗暴的方法,如果一个查询返回的数据为空(不管是数据
    不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会
    很短,最长不超过五分钟。通过这个直接设置的默认值存放到缓存,这样第二次
    到缓冲中获取就有值了,而不会继续访问数据库,这种办法最简单粗暴。
    5TB 的硬盘上放满了数据,请写一个算法将这些数据进行排重。如果这些数据是
    一些 32bit 大小的数据该如何解决?如果是 64bit 的呢?
    对于空间的利用到达了一种极致,那就是 Bitmap 和布隆过滤器(Bloom Filter)。

Bitmap: 典型的就是哈希表

缺点是,Bitmap 对于每个元素只能记录 1bit 信息,如果还想完成额外的功能,
恐怕只能靠牺牲更多的空间、时间来完成了。

布隆过滤器(推荐)

就是引入了 k(k>1)k(k>1)个相互独立的哈希函数,保证在给定的空间、误判率
下,完成元素判重的过程。

它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别
率和删除困难。

Bloom-Filter 算法的核心思想就是利用多个不同的 Hash 函数来解决“冲突”。
Hash 存在一个冲突(碰撞)的问题,用同一个 Hash 得到的两个 URL 的值有可
能相同。为了减少冲突,我们可以多引入几个 Hash,如果通过其中的一个 Hash
值我们得出某元素不在集合中,那么该元素肯定不在集合中。只有在所有的 Hash
函数告诉我们该元素在集合中时,才能确定该元素存在于集合中。这便是
Bloom-Filter 的基本思想。
Bloom-Filter 一般用于在大数据量的集合中判定某元素是否存在。

三、缓存预热

>缓存预热这个应该是一个比较常见的概念,相信很多小伙伴都应该可以很容易的
理解,缓存预热就是系统上线后,将相关的缓存数据直接加载到缓存系统。这样
就可以避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题!用户
直接查询事先被预热的缓存数据!

解决思路:

  • 1、直接写个缓存刷新页面,上线时手工操作下;
  • 2、数据量不大,可以在项目启动的时候自动进行加载;
  • 3、定时刷新缓存;

四、缓存更新
>除了缓存服务器自带的缓存失效策略之外(Redis默认的有6中策略可供选择),
我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种:

  • (1)定时去清理过期的缓存;
  • (2)当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话
    就去底层系统得到新数据并更新缓存。

两者各有优劣,第一种的缺点是维护大量缓存的 key 是比较麻烦的,第二种的缺
点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪种方
案,大家可以根据自己的应用场景来权衡。

五、缓存降级
>当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核
心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根
据一些关键数据进行自动降级,也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级
的(如加入购物车、结算)。
以参考日志级别设置预案:

  • (1)一般:比如有些服务偶尔因为网络抖动或者服务正在上线而超时,可以自
    动降级;
  • (2)警告:有些服务在一段时间内成功率有波动(如在 95~100%之间),可以
    自动降级或人工降级,并发送告警;
  • (3)错误:比如可用率低于 90%,或者数据库连接池被打爆了,或者访问量突
    然猛增到系统能承受的最大阀值,此时可以根据情况自动降级或者人工降级;
  • (4)严重错误:比如因为特殊原因数据错误了,此时需要紧急人工降级。
    服务降级的目的,是为了防止 Redis 服务故障,导致数据库跟着一起发生雪崩问
    题。因此,对于不重要的缓存数据,可以采取服务降级策略,例如一个比较常见
    的做法就是,Redis 出现问题,不去数据库查询,而是直接返回默认值给用户

17.热点数据和冷数据是什么

>热点数据,缓存才有价值
对于冷数据而言,大部分数据可能还没有再次访问到就已经被挤出内存,不仅占
用内存,而且价值不大。频繁修改的数据,看情况考虑使用缓存

对于上面两个例子,寿星列表、导航信息都存在一个特点,就是信息修改频率不
高,读取通常非常高的场景。
对于热点数据,比如我们的某 IM 产品,生日祝福模块,当天的寿星列表,缓存
以后可能读取数十万次。再举个例子,某导航产品,我们将导航信息,缓存以后
可能读取数百万次。

数据更新前至少读取两次缓存才有意义。这个是最基本的策略,如果缓存
还没有起作用就失效了,那就没有太大价值了。
那存不存在,修改频率很高,但是又不得不考虑缓存的场景呢?有!比如,这个
读取接口对数据库的压力很大,但是又是热点数据,这个时候就需要考虑通过缓
存手段,减少数据库的压力,

比如我们的某助手产品的,点赞数,收藏数,分享
数等是非常典型的热点数据,但是又不断变化,此时就需要将数据同步保存到
Redis 缓存,减少数据库压力。

18.Memcache 与 Redis 的区别都有哪些

  • 存储方式 Memecache 把数据全部存在内存之中,断电后会挂掉,数据不
    能超过内存大小。 Redis 有部份存在硬盘上,redis 可以持久化其数据
  • 数据支持类型 memcached 所有的值均是简单的字符串,redis 作为其替代
    者,支持更为丰富的数据类型 ,提供 list,set,zset,hash 等数据结构的存储
  • 使用底层模型不同 它们之间底层实现方式 以及与客户端之间通信的应用协
    议不一样。 Redis 直接自己构建了 VM 机制 ,因为一般的系统调用系统函数
    的话,会浪费一定的时间去移动和请求。
  • value 值大小不同:Redis 最大可以达到 1gb;memcache 只有 1mb。 5)redis 的速度比 memcached 快很多
  • Redis 支持数据的备份,即 master-slave 模式的数据备份

19.单线程的 redis 为什么这么快

  • 纯内存操作
  • 单线程操作,避免了频繁的上下文切换
  • 采用了非阻塞 I/O 多路复用机制

20.Redis 为什么是单线程的

>官方 FAQ 表示,因为 Redis 是基于内存的操作,CPU 不是 Redis 的瓶颈,Redis
的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现,而且
CPU 不会成为瓶颈,那就顺理成章地采用单线程的方案了(毕竟采用多线程会
有很多麻烦!)Redis 利用队列技术将并发访问变为串行访问

  • 绝大部分请求是纯粹的内存操作(非常快速)
  • 采用单线程,避免了不必要
    的上下文切换和竞争条件

非阻塞 IO 优点:

  • 速度快,因为数据存在内存中,类似于 HashMap,HashMap 的优势就是查
    找和操作的时间复杂度都是 O(1)
  • 支持丰富数据类型,支持 string,list,set,sorted set,hash
  • 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,
    要么全部不执行
  • 丰富的特性:可用于缓存,消息,按 key 设置过期时间,过期后将会自动删
    除如何解决 redis 的并发竞争 key 问题
    同时有多个子系统去 set 一个 key。这个时候要注意什么呢? 不推荐使用 redis
    的事务机制。因为我们的生产环境,基本都是 redis 集群环境,做了数据分片操
    作。你一个事务中有涉及到多个 key 操作的时候,这多个 key 不一定都存储在
    同一个 redis-server 上。因此,redis 的事务机制,十分鸡肋。(1)如果对这个 key 操作,不要求顺序: 准备一个分布式锁,大家去抢锁,抢到
    锁就做 set 操作即可 ;(2) 如果对这个 key 操作,要求顺序: 分布式锁+时间戳。 假设这会系统 B 先
    抢到锁,将 key1 设置为{valueB 3:05}。接下来系统 A 抢到锁,发现自己的 valueA
    的时间戳早于缓存中的时间戳,那就不做 set 操作了。以此类推。(3) 利用队列,将 set 方法变成串行访问也可以 redis 遇到高并发,如果保证读
    写 key 的一致性
    对redis的操作都是具有原子性的,是线程安全的操作,你不用考虑并发问题,redis
    内部已经帮你处理好并发的问题了。

21.Redis 集群方案应该怎么做?都有哪些方案?

1.twemproxy,大概概念是,它类似于一个代理方式, 使用时在本需要连接
redis 的地方改为连接 twemproxy, 它会以一个代理的身份接收请求并使用
一致性 hash 算法,将请求转接到具体 redis,将结果再返回 twemproxy。
缺点: twemproxy 自身单端口实例的压力,使用一致性 hash 后,对 redis
节点数量改变时候的计算值的改变,数据无法自动移动到新的节点。

2.codis,目前用的最多的集群方案,基本和 twemproxy 一致的效果,但它支
持在 节点数量改变情况下,旧节点数据可恢复到新 hash 节点

3.redis cluster3.0 自带的集群,特点在于他的分布式算法不是一致性 hash,而
是 hash 槽的概念,以及自身支持节点设置从节点。具体看官方文档介绍。

22.有没有尝试进行多机 redis 的部署?如何保证数据一致的?

>主从复制,读写分离
一类是主数据库(master)一类是从数据库(slave),主数据库可以进行读写操
作,当发生写操作的时候自动将数据同步到从数据库,而从数据库一般是只读的,
并接收主数据库同步过来的数据,一个主数据库可以有多个从数据库,而一个从
数据库只能有一个主数据库。

33.对于大量的请求怎么样处理

>redis 是一个单线程程序,也就说同一时刻它只能处理一个客户端请求;
redis 是通过 IO 多路复用(select,epoll, kqueue,依据不同的平台,采取不
同的实现)来处理多个客户端请求的

34.Redis 常见性能问题和解决方案?

(1) Master 最好不要做任何持久化工作,如 RDB 内存快照和 AOF 日志文件

(2) 如果数据比较重要,某个 Slave 开启 AOF 备份数据,策略设置为每秒同步
一次

(3) 为了主从复制的速度和连接的稳定性, Master 和 Slave 最好在同一个局
域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构,用单向链表结构更为稳定,即: Master <-
Slave1 <- Slave2 <-
Slave3

35.为什么 Redis 的操作是原子性的,怎么保证原子性的?

>对于 Redis 而言,命令的原子性指的是:一个操作的不可以再分,操作要么执行,
要么不执行。
Redis 的操作之所以是原子性的,是因为 Redis 是单线程的。
Redis 本身提供的所有 API 都是原子操作,Redis 中的事务其实是要保证批量操
作的原子性。
多个命令在并发中也是原子性的吗?
不一定, 将 get 和 set 改成单命令操作,incr 。使用 Redis 的事务,或者使用
Redis+Lua==的方式实现

36.Redis 事务

>Redis 事务功能是通过 MULTI、EXEC、DISCARD 和 WATCH 四个原语实现的
Redis 会将一个事务中的所有命令序列化,然后按顺序执行。

1.redis 不支持回滚“Redis 在事务失败时不进行回滚,而是继续执行余下的命
令”, 所以 Redis 的内部可以保持简单且快速。

2.如果在一个事务中的命令出现错误,那么所有的命令都不会执行;

3.如果在一个事务中出现运行错误,那么正确的命令会被执行。

  • MULTI 命令用于开启一个事务,它总是返回 OK。 MULTI 执行之后,客户
    端可以继续向服务器发送任意多条命令,这些命令不会立即被执行,而是被放到
    一个队列中,当 EXEC 命令被调用时,所有队列中的命令才会被执行。
  • EXEC:执行所有事务块内的命令。返回事务块内所有命令的返回值,按命令
    执行的先后顺序排列。 当操作被打断时,返回空值 nil。
  • 通过调用 DISCARD,客户端可以清空事务队列,并放弃执行事务, 并且客
    户端会从事务状态中退出。
  • WATCH 命令可以为 Redis 事务提供 check-and-set (CAS)行为。 可以
    监控一个或多个键,一旦其中有一个键被修改(或删除),之后的事务就不会执
    行,监控一直持续到 EXEC 命令。

37.Redis 实现分布式锁

>Redis 为单进程单线程模式,采用队列模式将并发访问变成串行访问,且多客户
端对 Redis 的连接并不存在竞争关系 Redis 中可以使用 SETNX 命令实现分布式
锁。
将 key 的值设为 value ,当且仅当 key 不存在。 若给定的 key 已经存在,
则 SETNX 不做任何动作

>解锁:使用 del key 命令就能释放锁

解决死锁:

  • 通过 Redis 中 expire()给锁设定最大持有时间,如果超过,则 Redis 来帮我
    们释放锁。
  • 使用 setnx key “当前系统时间+锁持有的时间”和 getset key “当前系
    统时间+锁持有的时间”组合的命令就可以实现。
打开App,阅读手记
2人推荐
发表评论
随时随地看视频慕课网APP