运维面试必问的中间件高频面试题（2024年最新版）(1)

2、支持失败节点自动删除

3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

缺点：增加了新的 proxy，需要维护其高可用。

failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预

10. 缓存雪崩？

在前面学习我们都知道Redis不可能把所有的数据都缓存起来(内存昂贵且有限)，所以Redis需要对数据设置过期时间，并采用的是惰性删除+定期删除两种策略对过期键删除。Redis对过期键的策略+持久化

如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中

什么是缓存雪崩？

Redis挂掉了，请求全部走数据库。

对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。

缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！

解决方法：

解决方法：在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。

对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：

事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。

事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)

事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

11. 缓存穿透

什么是缓存穿透

缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义

请求的数据在缓存大量不命中，导致请求走数据库。

缓存穿透如果发生了，也可能把我们的数据库搞垮，导致整个服务瘫痪！

如何解决缓存穿透

由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！

当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。

这种情况我们一般会将空对象设置一个较短的过期时间。

12. 缓存击穿

某一个热点key，在不停地扛着高并发，当这个热点key在失效的一瞬间，持续的高并发访问就击破缓存直接访问数据库，导致数据库宕机。

设置热点数据"永不过期" 加上互斥锁：上面的现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它 其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后将数据放到redis缓存起来。

后面的线程进来发现已经有缓存了，就直接走缓存

总结：

雪崩是大面积的key缓存失效；穿透是redis里不存在这个缓存key；击穿是redis某一个热点key突然失效，最终的受害者都是数据库。

13. redis为什么这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

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

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路 I/O 复用模型，非阻塞 IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

14. memcache有哪些应用场景

作为数据库的前端缓存应用： 完整缓存，静态缓存。

比如 商品分类，商品信息

15. memcache 服务特点及工作原理

a. 完全基于内存缓存的

b、节点之间相互独立

c、C/S模式架构，C语言编写，总共2000行代码。

d、异步Ｉ/O 模型，使用libevent作为事件通知机制。

e、被缓存的数据以key/value键值对形式存在的。

f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会丢失。

g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用LRU算法删除过期的缓存数据。

h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不会监控过期，而是在访问的时候查看key的时间戳,判断是否过期。

j、memcache会对设定的内存进行分块，再把块分组，然后再提供服务

16. memcached是如何做身份验证的？

没有身份认证机制，如果你想限制访问，可以使用防火墙

17. mongoDB是什么？

MongoDB是一个文档数据库，提供好的性能，领先的非关系型数据库。采用BSON存储文档数据。

BSON（）是一种类json的一种二进制形式的存储格式，简称Binary JSON.

相对于json多了date类型和二进制数组。

18. mongodb的优势

面向文档的存储：以 JSON 格式的文档保存数据。

任何属性都可以建立索引。

复制以及高可扩展性。

自动分片。

丰富的查询功能。

快速的即时更新。

19. mongodb使用场景

大数据

内容管理系统

移动端Apps

数据管理

20. kafka 中的ISR，AR代表什么，ISR伸缩又代表什么

ISR:In-Sync Replicas 副本同步队列

AR:Assigned Replicas 所有副本

ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

21.kafka中的broker 是干什么的

broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

22. kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，

但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等

23. kafka follower如何与leader同步数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。

而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

24. kafka 为什么那么快

• Cache Filesystem Cache PageCache缓存

• 顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。

• Zero-copy 零拷技术减少拷贝次数

• Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。

• Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

25. Kafka中的消息是否会丢失和重复消费？

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1、消息发送

Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：

0—表示不进行消息接收是否成功的确认；

1—表示当Leader接收成功时确认；

-1—表示Leader和Follower都接收成功时确认；

综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；

（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

2、消息消费

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；

High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

解决办法：

针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；

针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。

26. 为什么Kafka不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型

Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

(1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。

(2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

27. 什么是消费者组?

消费者组是 Kafka 独有的概念，如果面试官问这 个，就说明他对此是有一定了解的。我先给出标准答案：

1、定义：即消费者组是 Kafka 提供的可扩展且具有容错性的消费者机制。

2、原理：在 Kafka 中，消费者组是一个由多个消费者实例 构成的组。多个实例共同订阅若干个主题，实现共同消费。同一个组下的每个实例都配置有 相同的组 ID，被分配不同的订阅分区。当某个实例挂掉的时候，其他实例会自动地承担起 它负责消费的分区。

此时，又有一个小技巧给到你:消费者组的题目，能够帮你在某种程度上掌控下面的面试方

向。

如果你擅长位移值原理，就不妨再提一下消费者组的位移提交机制;

如果你擅长 Kafka Broker，可以提一下消费者组与 Broker 之间的交互;

如果你擅长与消费者组完全不相关的 Producer，那么就可以这么说:“消费者组要消 费的数据完全来自于 Producer 端生产的消息，我对 Producer 还是比较熟悉的。”

28. Kafka 中的术语

• 代理（borker）: 一个kafka进程（kafka进程又被称为实例），被称为一个代理broker节点。

• 生产者（producer）

Producer将消息记录发送到Kafka集群指定的主题（Topic）中进行存储，同时生产者（Producer）也能通过自定义算法决定将消息记录发送到哪个分区（Partition）。

例如，通过获取消息记录主键（Key）的哈希值，然后使用该值对分区数取模运算，得到分区索引。

• 消费者Consumer

消费者（Consumer）从Kafka集群指定的主题（Topic）中读取消息记录。在读取主题数据时，需要设置消费组名（GroupId）。如果不设置，则Kafka消费者会默认生成一个消费组名称。

• 消费者组： Consumer Group

消费者程序在读取Kafka系统主题（Topic）中的数据时，通常会使用多个线程来执行。一个消费者组可以包含一个或多个消费者程序，使用多分区和多线程模式可以极大提高读取数据的效率。

一般而言，一个消费者对应一个线程

• 主题Topic

Kafka系统通过主题来区分不同业务类型的消息记录。例如，用户登录数据存储在主题A中，用户充值记录存储在主题B中，则如果应用程序只订阅了主题A，而没有订阅主题B，那该应用程序只能读取主题A中的数据

• 分区（Partition）

每一个主题（Topic）中可以有一个或者多个分区（Partition）。在Kafka系统的设计思想中，分区是基于物理层面上的，不同的分区对应着不同的数据文件。Kafka通过分区（Partition）来支持物理层面上的并发读写，以提高Kafka集群的吞吐量。

一个分区只对应一个代理节点（Broker），一个代理节点可以管理多个分区。

• 副本（replication）

在Kafka系统中，每个主题（Topic）在创建时会要求指定它的副本数，默认是1。通过副本（Replication）机制来保证Kafka分布式集群数据的高可用性

在创建主题时，主题的副本系数值应如下设置：（1）若集群数量大于等于3，则主题的副本系数值可以设置为3；（2）若集群数量小于3，则主题的副本系数值可以设置为小于等于集群数量值。例如，集群数为2，则副本系数可以设置为1或者2；集群数为1，则副本系数只能设置为1。

• 记录（Record）

被实际写入到Kafka集群并且可以被消费者应用程序读取的数据，被称为记录（Record）。每条记录包含一个键（Key）、值（Value）和时间戳（Timestamp）。

• replica：

partition 的副本，保障 partition 的高可用。

• leader：

replica 中的一个角色， producer 和 consumer 只跟 leader 交互。

• follower：

replica 中的一个角色，从 leader 中复制数据。

• controller：

kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。

• zookeeper：

kafka 通过 zookeeper 来存储集群的 meta 信息。

生产者（Producer）负责写入消息数据。将审计日志、服务日志、数据库、移动App日志，以及其他类型的日志主动推送到Kafka集群进行存储。·

消费者（Consumer）负责读取消息数据。例如，通过Hadoop的应用接口、Spark的应用接口、Storm的应用接口、ElasticSearch的应用接口，以及其他自定义服务的应用接口，主动拉取Kafka集群中的消息数据。

29. kafka适用于哪些场景

1. 日志收集

2. 消息系统

3. 用户轨迹（记录浏览器用户或者app用户产生的各种记录，点击和搜索浏览等）

4. 记录运营监控数据

5. 实现流处理

30. Kafka写入流程：

1.producer 先从 zookeeper 的 “/brokers/…/state” 节点找到该 partition 的 leader

2. producer 将消息发送给该 leader

3. leader 将消息写入本地 log

4. followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK

5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK

最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

资料预览

给大家整理的视频资料：

给大家整理的电子书资料：

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK

最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

资料预览

给大家整理的视频资料：

[外链图片转存中…(img-33avwCYh-1714212839628)]

给大家整理的电子书资料：

[外链图片转存中…(img-Ey0KVPy2-1714212839629)]

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！