Redis面试的17个高水平问题

本文深入探讨了Redis在面试中的常见问题,包括为何选择Redis、其缺点、单线程高效运行的原因、数据类型及其应用场景、过期策略和内存淘汰机制、并发竞争Key的解决方案以及Redis在分布式锁和异步队列中的应用。此外,还讨论了Redis的持久化、数据结构、集群原理等,是理解Redis的重要参考资料。
摘要由CSDN通过智能技术生成

一、为什么使用Redis

笔者认为,在项目中使用Redis,主要是从两个角度去考虑:性能和并发。当然,Redis还具备可做分布式锁等功能的其它功能,但如果只是为了分布式锁这些其它功能,完全还有其它中间件(如Zookpeer等)可以代替,并不是非要使用Redis。

因此,这个问题主要从性能和并发两个角度去答:

1、性能
如下图所示,我们在碰到需要执行耗时特别久、且结果不频繁变动的SQL时,就特别适合将运行结果放入缓存。这样,后面的请求就去缓存中读取,使得请求能够迅速响应。

在这里插入图片描述

题外话:忽然想聊一下这个迅速响应的标准——其实根据交互效果的不同,这个响应时间没有固定标准。不过曾经有人这么告诉我:“在理想状态下,我们的页面跳转需要在瞬间解决,对于页内操作则需要在刹那间解决。另外,超过一弹指的耗时操作要有进度提示,并且可以随时中止或取消,这样才能给用户最好的体验。”

那么瞬间、刹那、一弹指具体是多少时间呢?

根据《摩诃僧祗律》记载:一刹那者为一念,二十念为一瞬,二十瞬为一弹指,二十弹指为一罗预,二十罗预为一须臾,一日一夜有三十须臾。

那么,经过周密的计算,一瞬间为0.36秒,一刹那有0.018秒,一弹指长达7.2秒。

2、并发

如下图所示,在大并发的情况下,所有的请求直接访问数据库,数据库会出现连接异常。这个时候,就需要使用Redis做一个缓冲操作,让请求先访问到Redis,而不是直接访问数据库。
在这里插入图片描述

二、使用Redis有什么缺点

大家用Redis这么久,这个问题是必须要了解的,基本上使用Redis都会碰到一些问题,常见的主要是四方面的问题:

  • 缓存和数据库双写一致性问题
  • 缓存雪崩问题
  • 缓存击穿问题
  • 缓存的并发竞争问题

这四个问题,笔者个人觉得在项目中比较常遇见,具体解决方案,后文会给出。

三、单线程的Redis为什么这么快

这个问题其实是对Redis内部机制的一个考察。其实根据笔者的面试经验,很多人其实都不知道Redis是单线程工作模型。所以,这个问题还是应该要复习一下的。主要是以下三点:

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

我们现在仔细地说一说I/O多路复用机制,因为这个说法实在是太通俗了,通俗到一般人都不懂是什么意思。打一个比方:小曲在S城开了一家快递店,负责同城快送服务。小曲因为资金限制,雇佣了一批快递员,然后小曲发现资金不够了,只够买一辆车送快递。

经营方式一:

客户每送来一份快递,小曲就让一个快递员盯着,然后快递员开车去送快递。慢慢的小曲就发现了这种经营方式存在很多问题,几十个快递员基本上时间都花在了抢车上了,大部分快递员都处在闲置状态,谁抢到了车,谁就能去送快递。

随着快递的增多,快递员也越来越多,小曲发现快递店里越来越挤,没办法雇佣新的快递员了,快递员之间的协调很花时间,大部分时间花在抢车上。综合上述缺点,小曲痛定思痛,提出了下面的经营方式↓

经营方式二:

小曲只雇佣一个快递员,客户送来的快递,小曲按送达地点标注好,然后依次放在一个地方。最后,那个快递员依次去取快递,一次拿一个,开着车去送快递,送好了就回来拿下一个快递。

上述两种经营方式对比,是不是明显觉得第二种,效率更高、更好呢?在上述比喻中:

  • 每个快递员→每个线程
  • 每个快递→每个Socket(I/O流)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值