为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！
这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。
本份面试集锦涵盖了
- 174 道运维工程师面试题
- 128道k8s面试题
- 108道shell脚本面试题
- 200道Linux面试题
- 51道docker面试题
- 35道Jenkis面试题
- 78道MongoDB面试题
- 17道ansible面试题
- 60道dubbo面试题
- 53道kafka面试
- 18道mysql面试题
- 40道nginx面试题
- 77道redis面试题
- 28道zookeeper
总计 1000+ 道面试题， 内容 又全含金量又高
- 174道运维工程师面试题
1、什么是运维?
2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?
3、现在给你三百台服务器，你怎么对他们进行管理?
4、简述raid0 raid1raid5二种工作模式的工作原理及特点
5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?
7、Tomcat和Resin有什么区别，工作中你怎么选择?
8、什么是中间件?什么是jdk?
9、讲述一下Tomcat8005、8009、8080三个端口的含义？
10、什么叫CDN?
11、什么叫网站灰度发布?
12、简述DNS进行域名解析的过程?
13、RabbitMQ是什么东西?
14、讲一下Keepalived的工作原理?
15、讲述一下LVS三种模式的工作过程?
16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?
17、如何重置mysql root密码?
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
3.流量控制
在平常的业务场景中，你的流量很低，但是一旦遇到秒杀活动、双十一活动这些大流量的场景
尤其是在某一时刻（例如 00:00）流量如洪水猛兽一样疯狂怼进来，你的服务器、MySQL、Redis各自的性能都是不一样的
你肯定不能将全部的流量请求照单全收，很容易会将性能低的服务器直接打挂
所以需要引入一个中间件来做缓冲，消息队列是一个很好的选择
先将请求放到消息队列当中，后端服务就尽自己最大的能力去消息队列中消费请求，对于超时的请求，可以直接返回错误。这样可以防止在高峰期大量的请求直接导致后端服务器崩溃
总结：
- 消息队列通常指的是消息队列中间件，它负责存放消息，便于应用之间的消息通信（可以理解为情报中转站）
- 消息队列三大应用场景：异步、削峰、解耦
消息队列
看看维基百科是怎么描述的
In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.
消息是指两个应用间传递的数据，数据的类型有很多种，可能只是文本、也有可能是对象
消息队列指的是在消息传输的过程中用来保存消息的容器（组件）
消息队列中，有下面两个角色：
- 生产者（producer）：负责生产数据并传输到消息队列，至于谁去取消息，生产者并不关心
- 消费者（consumer）：负责从消息队列中取出数据，至于数据是谁生产的，消费者并不关心
市面上主流的消息队列中间件
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级；比RaabitMQ、Kafka低一个数量级 | 同ActiveMQ | 十万级；支持高吞吐 | 十万级、高吞吐；一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic数量对吞吐量的影响 | \ | \ | topic可以达到几百/几千级别，吞吐量会有较小幅度的下降 | topic从几十到几百的时候，吞吐量会大幅度下降；同等机器下尽量保证topic 数量不要过多 |
| 时效性 | 毫秒级 | 微秒级、延迟最低 RabbitMQ特性 | 毫秒级 | 毫秒级以内 |
| 可用性 | 高，基于主从架构 | 高，基于主从架构 | 非常高 分布式架构 | 非常高、分布式、一个数据多个副本 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 可以通过参数优化做到零丢失 | 基本不丢 |
| 功能支持 | 功能完备 | 性能好，延时低 | 功能完善 | 功能简单 |
| 社区活跃度 | 低 | 中 | 高 | 高 |
1.两种模型
- 队列模型
生产者往某个队列里发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者
但是消费者之间是竞争关系，即每条消息只能被一个消费者消费
- 发布/订阅模型
在队列模型中，每条消息只能被一个消费者所消费，为了解决这一问题，让一条消息能被多个消费者消费，发布/订阅模型诞生了
在发布/订阅模型当中，会将消息发送到一个 topic（主题）中，所有订阅了这个 topic 的消费者都能消费到这条消息
就好比队列模型就是你在微信上跟别人私聊，你发送的消息只能被你私聊的那个人收到；发布/订阅模型就相当于你创建了一个群聊，把大家都拉进群里，只要是在群里的（订阅了 topic）都能收到你发的消息
那有的人就会想，我对好多人私聊，并且发的都是相同的信息，不是也能够实现一条消息被多个消费者消费的功能吗
很聪明！在队列模型里，可以使用多队列来全量存储相同的消息，然后不同的消费者去不同的队列里消费
通过数据的冗余实现一条消息被多个消费者消费的功能
RabbitMQ 中通过 exchange 模块将消息发送到多个队列，解决一条消息能被多个消费者消费的问题
总结：
- 队列模型中，一条消息只能被一个消费者消费；发布/订阅模型中，一条消息可以被多个消费者消费
- 队列模型中，可以通过数据冗余（一条消息存储到多个队列当中）来实现一条消息可以被多个消费者消费（RabbitMQ就是采用这种模式）
- RabbitMQ 采用队列模型、RocketMQ 和 Kafka 采用发布/订阅模型
2.基本原理
生产者：Producer
消费者：Consumer
消息队列服务端：Broker
消息由 Producer 发往 Broker，Broker 将消息存储至本地，然后 Consumer 从 Broker拉取消息，或者由 Broker 推送消息给 Consumer，最后实现消费
在发布/订阅模型中，为了提高并发，还会引入队列或者分区的概念——将消息发往一个 topic 中的某个队列或者某个分区（队列和分区本质一样，叫法不一样）
例如某个 topic 下有 n 个队列，那么这个主题的并发度就提高 n，同时可以支持 n 个消费者并行消费该 topic 中的消息
通常采用轮询 或者 key hash 取余等策略来将同一个 topic 的消息分配到不同的队列当中
既然是一对多的关系，那么消费者一般都有组的概念（Consumer group），即一条消息会发送到订阅了这个 topic 的消费组
例如现在有 Group1 和 Group 2 两个消费组，都订阅了 topic1 ，如果有一条消息发送到 topic1，那么这两个消费组都能接收到这条消息；消息其实是存储到了 topic1 中的某个队列当中，消费组的某个消费者对应消费一个队列的消息
实际上，一条消息在 Broker 中只会有一份，每个 Consumer group 会有自己的 offset （偏移量）来标识消费到的位置
在 offset 前的消息表示已经消费过了，每个 Consumer group 都会维订阅的 topic 下的每个队列的 offset
3.常见问题
如何保证消息不丢失
我们知道，从生产者生产消息到消费者消费消息，会经历三个阶段——生产消息、存储消息、消费消息。为了让消息不丢失，我们需要从这三个阶段进行考虑
- 生产消息
producer 发送消息到 broker ，需要处理 broker 的响应，无论是同步还是异步发送消息，都需要处理好 broker 的响应
如果 broker 返回写入失败等错误消息，需重新发送，当多次发送失败后需要进行故障处理
- 存储消息
在这个阶段，broker 需要在消息刷盘之后再给 producer 响应
假设消息写到缓存中就给 producer 响应，这个时候 broker 突然断电或者故障，就会导致消息丢失，而 producer 接收到 broker 的响应就会认为该消息已经发送成功了
如果 broker 是分布式架构的话，有副本机制（即消息不仅要写入当前 broker，还要写入副本机）那就应该设置成至少写入两台 broker 后再给 producer 响应
这样基本上就能保证存储的可靠性了
- 消费消息
Consumer 应该在执行完过程之后再给 broker 返回响应，而不是在拿到消息并放到内存后就立马给 broker 返回响应，这才是真正的消费了
万一这个时候 Consumer 出现故障或者断电，这条消息其实是没有走完整个业务流程的，而 broker 以为 Consumer 已经拿到数据并处理了
如何处理重复消息
先来看看为什么会有消息重复
假设 producer 发送消息不管 broker 的响应，只管生产，这样的情况下是不会出现消息重复的
但这样会导致另一个问题——消息不可靠
所以我们规定消息至少得发到 broker 上，并等待 broker 的响应，那么就有可能出现这个问题——消息已经发送到 broker 上并且 broker 返回响应给 producer ，但是由于网络问题这个响应并没有被 producer 收到，然后 producer 由重发了一次，这时候消息就会重复了
又假设 consumer 已经拿到消息了，并且走完业务流程此时需要更新 offset ，好巧不巧的是这个 consumer 挂掉了，另一个 consumer 来顶上，但这个 consumer 是没有消费的，于是会拿到刚刚那条消息重新走一遍业务，于是消息又重复了
由此可见——为了保证消息的可靠性，消息重复是无法避免的
那么如何处理重复消息呢？
幂等处理重复消息，幂等指的是任意多次执行所产生的影响均与一次执行的影响相同
通俗来讲，就是说通过幂等的方法来处理重复消息，无论你用同样的参数调用这个接口调用多少次的结果都是一个
比如说：
- 通过数据库的约束（唯一键）
- 记录关键的 key，对于一些关键的 key，给它一个唯一 ID
如何保证消息的有序性
- 全局有序
如果要保证消息的全局有序，首先只能有 producer 往 topic 发送消息，并且一个 topic 内部只能有一个队列（分区）
consumer 也必须是单线程消费这个队列
- 部分有序
为了实现部分有序，我们将 topic 内部划分出多个队列，然后通过特定策略将消息发往固定队列当中
为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！
这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。
本份面试集锦涵盖了
- 174 道运维工程师面试题
- 128道k8s面试题
- 108道shell脚本面试题
- 200道Linux面试题
- 51道docker面试题
- 35道Jenkis面试题
- 78道MongoDB面试题
- 17道ansible面试题
- 60道dubbo面试题
- 53道kafka面试
- 18道mysql面试题
- 40道nginx面试题
- 77道redis面试题
- 28道zookeeper
总计 1000+ 道面试题， 内容 又全含金量又高
- 174道运维工程师面试题
1、什么是运维?
2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?
3、现在给你三百台服务器，你怎么对他们进行管理?
4、简述raid0 raid1raid5二种工作模式的工作原理及特点
5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?
7、Tomcat和Resin有什么区别，工作中你怎么选择?
8、什么是中间件?什么是jdk?
9、讲述一下Tomcat8005、8009、8080三个端口的含义？
10、什么叫CDN?
11、什么叫网站灰度发布?
12、简述DNS进行域名解析的过程?
13、RabbitMQ是什么东西?
14、讲一下Keepalived的工作原理?
15、讲述一下LVS三种模式的工作过程?
16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?
17、如何重置mysql root密码?
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
13、RabbitMQ是什么东西?
14、讲一下Keepalived的工作原理?
15、讲述一下LVS三种模式的工作过程?
16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?
17、如何重置mysql root密码?
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
741
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
