面试千千问 -- Redis方面涉及的一些问题

目录

               前言

               面试开始

               总结

 

前言

          ~~> 请点击这里查看redis详情介绍，本文部分是我自己被问到的关于redis方面的面试题，还有一部分是我在网上收集到的别人遇到的一些问题。

面试开始

1）我看您的简历上有写到redis，你们为什么使用redis？

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

2）能谈谈您对redis的了解吗 ？

redis是基于内存的，采用的是单进程单线程模型的kv数据库，是由c语言编写。官方提供的数据是可以倒到100000+的QPS（每秒查询的次数）

• 完全基于内存，大部分请求是纯粹的内存操作，非常快速，数据是存在内存当中；
• 数据结构非常简单，对数据操作也简单，redis中的数据结构是专门进行设计的；
• 使用多路I/O复用模型，非堵塞IO。

 3）单线程，现在的服务器都是多核的，会不会造成资源浪费？

恩，它是单线程的，不过我们一般可以单机开多实例吖。

4）单机会遇到瓶颈，你们是如何解决这个瓶颈的？

我们用的是集群的部署方式也就是redis-cluster，并且是同步主从分离，类似mysql主从同步，redis-cluster支持n个redis、master node，每个master node都可以挂载多个slave node。 这样redis就可以横向扩容，如果你们需要支撑更大的数据库的缓存，那就横向扩展多个master节点，每个master节点就能存放更多的数据了。

5）redis怎么实现高可用？

哨兵集群sentinel，哨兵必须三个实例去保证自己的健壮性，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。

      5.1为什么必须要三个实例呢？分析两个哨兵会怎么样？

    

master宕机了，S1和S2两个哨兵只要有一个认为你宕机了就切换，并且会选举一个哨兵去执行故障，但是这个时候也要大多的哨兵都是运行的，那么这时候问题来了：

M1宕机，S1没挂那是ok的，如果整个都挂了。哨兵只剩下S2裸机，没有哨兵去允许故障转移，虽然另一台还有R1，但是故障转移就是不会执行。

经典哨兵集群如下图：

M1所在的机器挂了，哨兵还有两个，两个哨兵看它不是挂了嘛，那它们就选举一个出来执行故障转移就ok了。

• 集群监控：负责监控redis master 和 slave进程是否工作
• 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知管理员
• 故障转移：如果是master node挂掉了，会自动转移到slave node上
• 配置中心：如果故障转移发生了，通知client客户端新的master地址

6）数据传输的时候断网了或者服务挂掉了怎么办呢？

在传输的过程中有网络问题啥的，会重新连接的，并且重新连接之后会把缺少的数据补上。

7）你们怎么进行数据同步的？

我们使用rsync+inotify进行数据同步的。

8） redis和memcahed有什么区别，为什么会选择redis做为你们的缓存？

• redis支持复杂的数据结构
• redis原生支持集群模式
• 持久化与memcached比较好

Memcached：支持图片，视频等的缓存，支持一主多从的架构，但是服务器挂掉之后数据会丢失，并不可恢复

1. 内存预分配。Redis通常占据多台服务区，所以我们需要对其进行内存的预分配，给每一个redis节点分配缓存空间以及缓存位置，在我们需要查看缓存时可以直接查看数据所在节点对应的内存分区去查找，大大提高了数据查找的效率。另外我们还可以通过预分配达到redis内存优化的效果，提高redis存储的效率。
2. 持久化机制。Redis 的持久化机制我们一般会采用redis中aof和rdb相结合，aof默认每秒同步一次数据，所以会使数据变得非常持久，保证了数据的安全性和持久性；rdb会将我们的数据保存为一个文件，方便我们备份，但是效率比aof稍慢，如果可以承受数分钟以内的数据丢失， 使用 RDB 持久化。
3. Redis架构选择。Redis拥有主从，哨兵和cluster模式，我们在选择时要根据具体的项目需求进行选择，一、选择主从模式搭配哨兵模式，保证数据的安全性同时也可以及时发现问题进行跳转，保证结构的正常运行；二、选择cluster模式，cluster模式中所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。节点的fail是通过集群中超过半数的节点检测失效时才生效。客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可；这两种模式各有优点，集合项目选择更好的方案。

9）redis的持久化您说说？

持久化是redis高可用比较重要的一个环节，因为redis数据在内存，有以下两种持久化：

• RDB：RDB持久化机制，是对redis中的数据执行周期性的持久化；
• AOF：AOF机制对每条写入命令作为日志，以oppend-only的模式写入一个日志中，因为这个模式只是追加的方式，所以没有任何的磁盘开销，因此很快，有点像mysql中的binlog。

两中方式都可以把Redis内存中的数据持久化到磁盘上，然后再进行备份到别的地方去，RDB适合做冷备，AOF适合做热备。

模拟场景：

10）缓存雪崩？

模拟场景：一个电商平台定时刷新缓存，定时刷新就可能会遇到一个问题

比如我12点准时刷新，那么这时候刚好有一个限时秒杀的活动，瞬间就有每秒6000个请求来访问redis，而redis真实抗并发每秒5000而且12点这时候刚好正在刷新缓存，无法抗这么高的并发，就会造成数据直接去访问数据库，同时这么多并发进去到数据库，大家可想而知，会直接导致数据库挂掉，如果没有应急的的方案，直接重启数据库的话，马上就会被新的流量打死。

11）缓存穿透?

这样来理解吧，比如说有3000个请求来访问redis，在redis的缓存中没有找到答案，redis就会去mysql中查看是否有答案，发现mysql中也没有。于是这3000个请求，一直在请求，数据库压力过大，严重会击垮数据库。

12）缓存击穿？

这个类似缓存雪崩。还是3000个用户一直请求redis中key（1）这个值，一直指定请求，这个key不停地抗着并发，知道扛不住，直击服务器。

总结

        暂时只有这些，后期遇到的话我还会在补充，创作不易，看完之后一键三连吧。

本文地址：https://blog.csdn.net/yeyslspi59/article/details/108874603