redis面试问题

redis为什么快

1. 基于内存
   Redis是完全基于内存，没有磁盘IO上的开销，绝大部分请求是纯粹的内存操作，数据存在内存中，读写速度快。

   我们大家都知道内存的寻址和带宽都是远远快于磁盘的

2. 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的

3. 单线程实现（ Redis 6.0以前）
   Redis使用单个线程处理请求，避免了多个线程之间线程切换和锁资源争用的开销

4. 使用多路I/O复用模型，非阻塞IO（了解）
   Redis 采用 IO 多路复用技术。Redis 使用单线程来轮询描述符，将数据库的操作都转换成了事件，不在网络I/O上浪费过多的时间。

redis是单线程的还是多线程的

因为Redis的瓶颈不是cpu的运行速度，而往往是网络带宽和机器的内存大小。再说了，单线程切换开销小，容易实现，既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了

Redis是单线程，主要是指Redis的网络IO和键值对读写是由一个线程来完成的（6.0之后网络IO是多线程的，需要手动开启），这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

Redis 从 4.0 版本开始就有了多线程的概念，虽然处理命令请求的核心模块确实是保证了单线程执行，然而在其他许多地方已经有了多线程，比如：在后台删除对象，通过 Redis 模块实现阻塞命令，生成 dump 文件，以及 6.0 版本中网络 I/O 实现了多线程等，而且在未来 Redis 应该会有越来越多的模块实现多线程。
所谓的单线程，只是说 Redis 的处理客户端的请求（即执行命令）时，是单线程去执行的，并不是说整个 Redis 都是单线程。

redis是单线程的还是多线程的 第二种解释

在一开始的时候，Redis采用的是单线程模型，因为Redis是一个基于内存的数据库，将所有的数据放入内存，所以使用单线程的操作效率是最高的，多线程会上下文切换消耗大量时间，对于内存系统来说，单线程才能产生更高的效率。但是单线程不意味着整个Redis就一个线程，Redis其他模块还有各自的线程。

使用I/O多路复用机制同时监听多个客户端，在单线程模式下，即使网络处理很多，因为存在I/O多路复用，依然可以在高速的内存处理下得到忽略。

Redis为什么引入多线程

Redis基于内存操作，CPU并不是性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽。在6.0的版本中引入了多线程。

这个I/O threads 指的是网络I/O处理方面使用了多线程，如网络数据的读写和协议解析等，这是因为读写网络的read/write在Redis执行期间占用了大部分CPU时间，如果把这部分模块使用多线程方式实现会对性能带来极大地提升。但是Redis执行命令的核心模块还是单线程的。

需要注意的是在 Redis6.0 中，多线程机制默认是关闭的，需要在 redis.conf 中完成以下两个设置才能启用多线程。
（1）设置 io-thread-do-reads 配置项为 yes，表示启用多线程。

io-threads-do-reads yes

（2）设置线程个数。⼀般来说，线程个数要小于 Redis 实例所在机器的 CPU 核数， 例如，对于⼀个 8 核的机器来说，Redis 官⽅建议配置 6 个 IO 线程。

io-threads 6

单线程的缺点

单线程处理最大的缺点就是，如果前一个请求发生耗时比较久的操作，那么整个Redis都会被阻塞，其他请求也无法进来，直到这个耗时久的操作处理完成并返回，其他请求才能被处理到。

我们平时遇到Redis响应变慢或长时间阻塞的问题，大部分都是因为Redis处理请求是单线程这个原因导致的。

所以，我们在使用Redis时，一定要避免非常耗时的操作，例如使用时间复杂度过高的方式获取数据、一次性获取过多的数据、大量key集中过期导致Redis淘汰key压力变大等等，这些场景都会阻塞住整个处理线程，直到它们处理完成，势必会影响业务的访问。

如果万一CPU成为你的Redis瓶颈了，或者，你就是不想让服务器其他核闲置，那怎么办？

那也很简单，你多起几个Redis进程就好了。Redis是keyvalue数据库，又不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。redis-cluster可以帮你做的更好。

redis内存满了怎么办？

1、redis集群，加服务器。
2，使用内存淘汰策略。
redis设置配置文件的maxmemory参数，可以控制其最大可用内存大小（字节）。
那么当所需内存，超过maxmemory怎么办？
这个时候就该配置文件中的maxmemory-policy出场了。
其默认值是noeviction。
LRU算法，least RecentlyUsed，最近最少使用算法。也就是说默认删除最近最少使用的键。
但是一定要注意一点！redis中并不会准确的删除所有键中最近最少使用的键，而是随机抽取3个键，删除这三个键中最近最少使用的键。
那么3这个数字也是可以设置的，对应位置是配置文件中的maxmeory-samples.

写完数据库后是否需要马上更新缓存还是直接删除缓存？

一般的策略是当更新数据时，先删除缓存数据，然后更新数据库，而不是更新缓存，等要查询的时候才把最新的数据更新到缓存

项目中什么时候需要用缓存？

访问量大并且不常修改的时候。

是不是只要访问量大就必须用缓存？

例如验证码，因为验证码一个人只需要用一次，再之后就没有意义了，所以不需要用缓存。

项目中为什么要使用redis

因为传统的关系型数据库如Mysql已经不能适用所有的场景了，比如秒杀的库存扣减，APP首页的访问流量高峰等等，都很容易把数据库打崩，所以引入了缓存中间件，目前市面上比较常用的缓存中间件有Redis 和 Memcached 不过中和考虑了他们的优缺点，最后选择了Redis。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

KEYS 的速度非常快，例如，Redis在一个有1百万个key的数据库里面执行一次查询需要的时间是40毫秒 。但在一个大的数据库中使用它仍然可能造成性能问题.

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？
答：使用keys指令可以扫出指定模式的key列表。

对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

keys命令的原理就是扫描整个redis里面所有的db的key数据，然后根据我们的通配的字符串进行模糊查找出来。更为致命的是，这个命令会阻塞redis多路复用的io主线程，如果这个线程阻塞，在此执行之间其他的发送向redis服务端的命令，都会阻塞，从而引发一系列级联反应，导致瞬间响应卡顿，从而引发超时等问题，所以应该在生产环境禁止用使用keys和类似的命令smembers，这种时间复杂度为O（N），且会阻塞主线程的命令，是非常危险的。

取而代之的，如果需要查找然后删除key的需求，那么在生产环境我们应该使用scan命令，代替keys命令，同样是O（N）复杂度的scan命令，支持通配查找，scan命令或者其他的scan如SSCAN
，HSCAN，ZSCAN命令，可以不用阻塞主线程，并支持游标按批次迭代返回数据，所以是比较理想的选择。keys相比scan命令优点是，keys是一次返回，而scan是需要迭代多次返回。

但scan命令的也有缺点，返回的数据有可能重复，需要我们在业务层按需要去重，scan命令的游标从0开始，也从0结束，每次返回的数据，都会返回下一次游标应该传的值，我们根据这个值，再去进行下一次的访问，如果返回的数据为空，并不代表没有数据了，只有游标返回的值是0的情况下代表结束

如果使用redis，当key很多的时候，如何进行筛选

当key很多，可以把key存放到集合中，例如list集合，set集合。商品的放一个集合，其他的放一个集合。

系统使用了缓存，使用redis作为缓存服务器，在数据缓存的时候，有热点数据和冷门数据，如何保证缓存服务器存放的是热点数据，冷门数据并不会太多的占用缓存服务器的资源

首先热点、冷门数据并不是规定好的，所以不能以字段来做判断。

解决办法：
使用过期时间，
热点数据经常使用，如果到了过期时间自动清理了，再次有人访问，就加回来。

Redis在你们项目中是怎么用的？

1. 门户系统中的首页内容信息的展示。（商品类目、广告、热门商品等信息）门户系统的首页是用户访问量最大的，而且这些数据一般不会经常修改，因此为了提高用户的体验，我们选择将这些内容放在缓存中；
2. 单点登录系统中也用到了redis。因为我们是分布式系统，存在session之间的共享问题，因此在做单点登录的时候，我们利用redis来模拟了session的共享，来存储用户的信息，实现不同系统的session共享；
3. 我们项目中同时也将购物车的信息设计存储在redis中，购物车在数据库中没有对应的表，用户登录之后将商品添加到购物车后存储到redis中，key是用户id，value是购物车对象；
4. 因为针对评论这块，我们需要一个商品对应多个用户评论，并且按照时间顺序显示评论，为了提高查询效率，因此我们选择了redis的list类型将商品评论放在缓存中；
5. 在统计模块中，我们有个功能是做商品销售的排行榜，因此选择redis的zset结构来实现；

什么时候用redis或者spring缓存

暂时超出能力的知识

什么是I/O多路复用

I/O 指的是网络 I/O， 多路指的是多个 TCP 连接（如 Socket），复用指的是复用一个或多个线程。
I/O 多路复用的核心原理就是不再由应用程序自己来监听连接，而是由服务器内核替应用程序监听。
在 Redis 中，其多路复用有多种实现，如：select，epoll，evport，kqueue 等。

我们用去餐厅吃饭为的例子来解释一下 I/O 多路复用机制（点餐人相当于客户端，餐厅的厨房相当于服务器，厨师就是线程）。

• 阻塞 IO：张三去餐厅吃饭，点了一道菜，这时候他啥事也不干了，就是一直等，等到厨师炒好菜，他就把菜端走开始吃饭了。也就是在菜被炒好之前，张三被阻塞了，这就是 BIO（阻塞 IO），效率会非常低下。

• 非阻塞 IO：张三去餐厅吃饭，点了一道菜，这时候张三他不会一直等，找了个位置坐下，刷刷抖音，打打电话，做点其他事，然后每隔一段时间就去厨房问一下自己的菜好了没有。这种就属于非阻塞 IO，这种方式虽然可以提高性能，但是如果有大量 IO 都来定期轮询，也会给服务器造成非常大的负担。

• 事件驱动机制：张三去餐厅吃饭，点了一道菜，这时候他找了个位置坐下来等：

  • 厨房那边菜做好了就会把菜端出来了，但是并不知道这道菜是谁的，于是就挨个询问顾客，这就是多路复用中的 select 模型，不过 select 模型最多只能监听 1024 个 socket（poll 模型解决了这个限制问题）。

  • 厨房做好了菜直接把菜放在窗口上，大喊一声，某某菜做好了，是谁的快过来拿，这时候听到通知的人就会自己去拿，这就是多路复用中的 epoll 模型。

需要注意的是在 IO 多路复用机制下，客户端可以阻塞也可以选择不阻塞（大部分场景下是阻塞 IO），这个要具体情况具体分析，但是在多路复用机制下，服务端就可以通过多线程（上面示例中可以多几个厨师同时炒菜）来提升并发效率。

Redis 中 I/O 多路复用的应用

Redis 服务器是一个事件驱动程序，服务器需要处理两类事件：文件事件和时间事件。

• 文件事件：Redis 服务器和客户端（或其他服务器）进行通信会产生相应的文件事件，然后服务器通过监听并处理这些事件来完成一系列的通信操作。

• 时间事件：Redis 内部的一些在给定时间之内需要进行的操作。

Redis 的文件事件处理器以单线程的方式运行，其内部使用了 I/O 多路复用程序来同时监听多个套接字（Socket）连接，提升了性能的同时又保持了内部单线程设计的简单性。下图就是文件事件处理器的示意图：

I/O 多路复用程序虽然会同时监听多个 Socket 连接，但是其会将监听的 Socket 都放到一个队列里面，然后通过这个队列有序的，同步的将每个 Socket 对应的事件传送给文件事件分派器，再由文件事件分派器分派给对应的事件处理器进行处理，只有当一个 Socket 所对应的事件被处理完毕之后，I/O多路复用程序才会继续向文件事件分派器传送下一个 Socket 所对应的事件，这也可以验证上面的结论，处理客户端的命令请求是单线程的方式逐个处理，但是事件处理器内并不是只有一个线程。

部分内容转载自：
https://zhuanlan.zhihu.com/p/81195864
https://juejin.cn/post/6993902033178722312
https://juejin.cn/post/6915599025882431501
https://blog.csdn.net/lxw1844912514/article/details/118526528

她口中的词汇越来越少，只剩下“这个、那个”。有一次家里的洗衣机洗完衣服，“滴滴”响了，刘丹想提醒陈玉去晾衣服，跟她说，“那个”响了。陈玉鼓励妈妈，说出洗衣机这个词，但她怎么都说不出来。她偶尔也会忘记家人的名字。陈文不在身边的时候，刘丹会问女儿：“那个人去哪里了？”状态好的时候，她又能说出来老伴儿的名字。

https://new.qq.com/omn/20220329/20220329A0AQ0000.html?pgv_ref=aio2015&ptlang=2052