Java岗大厂面试百日冲刺 - 日积月累，每日三题【Day2】 —— Redis篇1

陈哈哈

发布于 2021-10-13 15:51:34

4310

发布于 2021-10-13 15:51:34

文章被收录于专栏：MySQL入坑记

大家好，我是陈哈哈，北漂五年。认识我的朋友们知道，我是非科班出身，半路出家，大学也很差！这种背景来北漂，你都不知道你会经历什么🙃🙃。不敢苟同，相信大家和我一样，都有一个大厂梦，作为一名资深Java选手，深知面试重要性，接下来我准备用100天时间，基于Java岗面试中的高频面试题，以每日3题的形式，带你过一遍热门面试题及恰如其分的解答。当然，我不会太深入，因为我怕记不住！！ 因此，不足的地方希望各位在评论区补充疑惑、见解以及面试中遇到的奇葩问法，希望这100天能够让我们有质的飞越，一起冲进大厂！！，让我们一起学（juan）起来！！！

车票

本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。

面试题1：为什么要用 Redis ？业务在哪块儿用到的？

正经回答：

Redis是眼下最为人熟知的缓解高并发、提升高可用能力的手段之一，再提升服务器性能方面效果显著。

这里不得不提到高并发场景，我们知道，并发场景下核心点在数据库，引入缓存（以及引入任何负载均衡、集群等策略）的目的都是在减轻数据库压力，让更多原本打到DB上的请求，在中间被拦截处理掉。就像你请个假屁大点儿事还要大老板签字一样？

通俗易懂点儿说，高并发对服务器来说，就好比你被人锤一拳，这拳头可是硬的很，光着膀子的话一拳就给我干吐血。。那么我为了承受住这一拳？穿棉袄、穿护垫、穿…是吧，只要够厚，我都以为你在给我挠痒痒~同理，Redis就是一件又厚又弹的棉袄。

话说回来，它有多厚多弹呢？操作缓存就是直接操作内存，速度相当快，直接操作缓存能够承受的请求数是远远大于直接访问数据库的。

Redis优势：

读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
支持数据持久化，支持AOF和RDB两种持久化方式。
支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
支持大量集群节点。

假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在数Redis中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。同样，我们可以把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接打到缓存而不是数据库（即半路拦截掉了）。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

在我们业务中，包括热点词查询、一些实时排行榜数据、访问量点赞量统计、Session共享等等都可以引入Redis来处理。

深入追问：

追问1：Redis里有哪些数据类型？

丰富的数据类型，Redis有8种数据类型，当然常用的主要是 String、Hash、List、Set、 SortSet 这5种类型，他们都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的操作命令，可以满足绝大部分需求，如果有特殊需求还能自己通过 lua 脚本自己创建新的命令（具备原子性）；

追问2：Redis与Memcached有哪些区别？

两者都是非关系型内存键值数据库，现在公司一般都是用 Redis 来实现缓存，为什么不用Memcached呢？

参数	Redis	Memcached
类型	1. 支持内存 2. 非关系型数据库	1. 支持内存 2. 键值对形式 3. 缓存形式
数据存储类型	1. String 2. List 3. Set 4. Hash 5. Sort Set	1. 文本型 2. 二进制类型
附加功能	1. 发布/订阅模式 2. 主从分区 3. 序列化支持 4. 脚本支持【Lua脚本】	多线程服务支持
网络IO模型	单线程的多路 IO 复用模型	多线程，非阻塞IO模式
持久化支持	1. RDB 2. AOF	不支持
集群模式	原生支持 cluster 模式，可以实现主从复制，读写分离	没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据
内存管理机制	在 Redis 中，并不是所有数据都一直存储在内存中，可以将一些很久没用的 value 交换到磁盘	Memcached 的数据则会一直在内存中，Memcached 将内存分割成特定长度的块来存储数据，以完全解决内存碎片的问题。
适用场景	复杂数据结构，有持久化，高可用需求，value存储内容较大，最大512M	纯key-value，数据量非常大，并发量非常大的业务

memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
redis的速度比memcached快很多
redis可以持久化数据到磁盘，这个很关键，宕机断电不再是硬伤。

追问3：那Redis怎样防止异常数据不丢失的？如何持久化？

RDB 持久化（快照）

将某个时间点的所有数据生成快照，存放到硬盘上。当数据量很大时，会很慢。
可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。
如果系统发生故障，将会丢失最后一次创建快照之后的数据。

AOF 持久化（即时更新）

将写命令添加到 AOF 文件（Append Only File）的末尾。
使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。

有以下同步选项（同步频率）： always 每个写命令都同步；everysec 每秒同步一次；no 让操作系统来决定何时同步。 everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；

面试题2：Redis为啥是单线程的？

Redis is single threaded. How can I exploit multiple CPU / cores? It’s not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 1 million requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU. However, to maximize CPU usage you can start multiple instances of Redis in the same box and treat them as different servers. At some point a single box may not be enough anyway, so if you want to use multiple CPUs you can start thinking of some way to shard earlier. You can find more information about using multiple Redis instances in the Partitioning page. However with Redis 4.0 we started to make Redis more threaded. For now this is limited to deleting objects in the background, and to blocking commands implemented via Redis modules. For future releases, the plan is to make Redis more and more threaded.

正经回答：

上面是Redis官网给的解释（官方文档链接），翻译后简单说，因为Redis的瓶颈不是CPU的运行速度，而往往是网络带宽和机器的内存大小。再说了，单线程切换开销小，容易实现。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案，当然了，也是为了避免多线程存在的很多坑。对了，一个节点是一个单线程。

深入追问：

追问1：单线程只使用了单核CPU，太浪费，有什么办法发挥多核CPU的性能嘛？

我们可以通过在单机开多个Redis 实例，我们一直在强调的单线程，只是在处理我们的网络请求的时候只有一个线程来处理。实际上，一个正式的Redis Server运行的时候肯定是不止一个线程的，都是集群形式，多少多少个节点，所以实际环境中大家不用担心这种问题。

面试题3：聊一下对缓存穿透、缓存击穿、缓存雪崩的理解吧

正经回答：

缓存穿透：指缓存和数据库中都没有的数据，导致所有的请求都打到数据库上，然后数据库还查不到（如null），造成数据库短时间线程数被打满而导致其他服务阻塞，最终导致线上服务不可用，这种情况一般来自黑客同学。
缓存击穿：指缓存中没有但数据库中有的数据（一般是热点数据缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去查，引起数据库压力瞬间增大，线上系统卡住。
缓存雪崩：指缓存同一时间大面积的失效，缓存击穿升级版。

深入追问：

追问1：那你说一下针对缓存击穿的解决方法

根据实际业务情况，在Redis中维护一个热点数据表，批量设为永不过期（如top1000），并定时更新top1000数据。
加互斥锁（mutex key）

互斥锁 缓存击穿后，多个线程会同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它。其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存。

    static Lock reenLock = new ReentrantLock();
    public List<String> getData04() throws InterruptedException {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据
        result = getDataFromCache();
        if (result.isEmpty()) {
            if (reenLock.tryLock()) {
                try {
                    System.out.println("拿到锁了,从DB获取数据库后写入缓存");
                    // 从数据库查询数据
                    result = getDataFromDB();
                    // 将查询到的数据写入缓存
                    setDataToCache(result);
                } finally {
                    reenLock.unlock();// 释放锁
                }

            } else {
                result = getDataFromCache();// 先查一下缓存
                if (result.isEmpty()) {
                    System.out.println("我没拿到锁,缓存也没数据,先小憩一下");
                    Thread.sleep(100);// 小憩一会儿
                    return getData04();// 重试
                }
            }
        }
        return result;
    }