Linux运维工程师会面试哪些
知识上面的答主说的很精准了，我来说说技巧。我本身是一名HR，负责新盟教育的Linux讲师招聘，所以我需要懂Linux基础知识，方便对面试者提问。
首先，我会就应聘者简历上填写的内容进行，提问，一般会包括拿到的证书，有无经验，熟悉的技能，然后我的同事会提问专业内容。比如你写了擅长MySQL ，Jquery，bootstrap，那么我们就会提问这些内容，当然都不会特别困难，只需要证明你确实知道，不是在吹嘘就行。
其次我们会就岗位需求进行提问，我会问到加班，出差，经验等问题，我的同事会问会不会某些特定要求的内容，比如za***ix、nagios、elk等……
如果不会，请千万不要吹牛，我们会问到说明我们肯定知道这玩意，如果吹牛肯定一眼就看出来，然后三两句话把你送走这样。
如果你一面过了，要准备二面，那么请你至少，在二面之前，把我们提到的岗位要求的内容了解一下，避免我们再次提到的时候还是不知道，这样很影响面试结果。
大数据架构选择消息队列，我选kafka。面试官问为什么？
毫无疑问 Kafka!
最多前面加个Flume。
任何选型的原因，都源自你的需求是什么。 Fast,Scalable,Durable是我的需求，Kafka完美满足。稍微讲些细节，好多想必大家也都知道。
Kafka将数据写到磁盘，实际上都会写到OS的page cache里， 而读的时候又用sendfile非常高效的将数据传输到NIC。
Kafka的扩展性也非常好，只要增加broker即可。Kafka的逻辑也非常清晰，可以将不同业务逻辑的数据写进不同到topic，而topic又可以切分成若干个partition来并行处理，并且Kafka0.9后，zk只需要被broker所使用，consumer并不再需要使用zk来记录offset，大大降低zk的压力，同时也从侧面降低了scale的压力。
Kafka也有比较友好的删除策略。可以直接按照max age或者max size自动删除，也可以按照key进行compact，基本上都能满足需求。另一方面，Kafka的社区非常活跃，并且现在几乎所有流行的(流式)计算框架都支持Kafka，如Spark Streaming，Storm，Flink 等。对了，有个叫camus的工具定期可以将Kafka里的数据搬到HDFS上。
kafka性能为什么好
人人皆知kafka性能好，但真正了解原因的人就少了很多。说起来也是悲伤的故事，我的某次面试就凉在此题。那么从设计的角度看，kafka是如何实现高性能的呢？
Kafka会把消息写入到硬盘，绝对不会丢失数据。为了优化写入速度Kafak采用了两个技术， 顺序写入 和 MMFile
因为硬盘是机械结构，寻址是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O，Kafka就是使用顺序I/O。
每一个Partition其实都是一个文件 ，收到消息后Kafka会把数据插入到文件末尾（虚框部分）。
Kafka的数据并 不是实时的写入硬盘 ，它充分利用了现代操作系统 分页存储 来利用内存提高I/O效率。操作系统会选择适当的时机将数据写入硬盘。
缺点就是 不可靠 ，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。
Kafka提供了一个参数——producer.type来控制是不是主动flush，如果Kafka写入到mmap之后就立即flush然后再返回Producer叫 同步 (sync)；写入mmap之后立即返回Producer不调用flush叫 异步 (async)。
cosumer向broker索要消息时，kafka使用 零拷贝(zero-copy) ，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”，直接复制到socket缓冲区
Kafka面试题
Kafka是分布式发布-订阅消息系统，它最初是由linkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。
为什么要使用 kafka，为什么要使用消息队列
消息发送
解决方案
1.配置ack=all/-1，tries 1,unclean.leader.election.enable = false
producer发送完消息，等待follower同步完成再返回，如果异常则重试，副本数量可能影响吞吐量
不允许选举ISR的副本作为leader
2.配置min.insync.replicas1
副本指定必须写操作成功的最小副本数量，如果不能满足这个最小值，则生产者引发一个异常（NotEnoughReplicash或者NotEnoughReplicashAfterAppend）
消费
先commit再处理消息，如果处理消息的时候异常了，但offset已经提交了，这条消息对于消费者来说丢失了
broker的刷盘
减少刷盘的间隔
kafka如何保证不重复消费又不丢失数据
1.必须要求至少一个 Follower 在 ISR 列表里。
2.第二条，每次写入数据的时候，要求 Leader 写入成功以外，至少一个 ISR 里的 Follower 也写成功。
pull模式
push模式
缺点：速率固定，忽略了consumer的消费能力，可能导致拒绝服务或者网络阻塞等情况
1. Broker注册 Broker是分布式部署并且相互之间相互独立，但是需要有一个注册系统能够将整个集群中的Broker管理起来 /brokers/ids
2. Topic注册 在Kafka中，同一个Topic的消息会被分成多个分区并将其分布在多个Broker上，这些分区信息及与Broker的对应关系也都是由Zookeeper在维护 /borkers/topics
3. 生产者负载均衡 由于同一个Topic消息会被分区并将其分布在多个Broker上，因此，生产者需要将消息合理地发送到这些分布式的Broker上，那么如何实现生产者的负载均衡，Kafka支持传统的四层负载均衡，也支持Zookeeper方式实现负载均衡。
4. 消费者负载均衡 与生产者类似，Kafka中的消费者同样需要进行负载均衡来实现多个消费者合理地从对应的Broker服务器上接收消息，每个消费者分组包含若干消费者，每条消息都只会发送给分组中的一个消费者，不同的消费者分组消费自己特定的Topic下面的消息，互不干扰。
5. 分区与消费者 的关系 在Kafka中，规定了每个消息分区 只能被同组的一个消费者进行消费，因此，需要在 Zookeeper 上记录 消息分区 与 Consumer 之间的关系，每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID 写入到 Zookeeper 对应消息分区的临时节点上，例如：
/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]
其中，[broker_id-partition_id]就是一个 消息分区 的标识，节点内容就是该 消息分区 上 消费者的Consumer ID。
6. 消息消费进度Offset 记录 在消费者对指定消息分区进行消息消费的过程中，需要定时地将分区消息的消费进度Offset记录到Zookeeper上，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为:
/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]
节点内容就是Offset的值。
7. 消费者注册 消费者服务器在初始化启动时加入消费者分组的步骤如下
注册到消费者分组。每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者就会将自己订阅的Topic信息写入该临时节点。
Kafka不基于内存，而是硬盘存储，因此消息堆积能力更强
1.顺序写磁盘（相比磁盘的随机写快很多）。如果你是追加文件末尾按照顺序的方式来写数据的话，那么这种磁盘顺序写的性能基本上可以跟写内存的性能本身也是差不多的。
2.利用Page Cache（页高速缓冲存储器，简称页高缓）空中接力的方式来实现高效读写，操作系统本身有一层缓存，叫做page cache，是在内存里的缓存，我们也可以称之为os cache，意思就是操作系统自己管理的缓存。原理就是Page Cache可以把磁盘中的数据缓存到内存中，把对磁盘的访问改为对内存的访问。
3.零拷贝 零拷贝技术是一种避免CPU将数据从一块存储拷贝到另一块存储的技术。Kafka使用零拷贝技术将数据直接从磁盘复制到网卡设备缓冲区中，而不需要经过应用程序的转发。
通常应用程序将磁盘上的数据传送至网卡需要经过4步：
-调用read()，将数据从磁盘复制到内核模式的缓冲区；
-CPU会将数据从内核模式复制到用户模式下的缓冲区；
-调用write()，将数据从用户模式下复制到内核模式下的Socket缓冲区；
-将数据从内核模式的Socket缓冲区复制到网卡设备。
上面的步骤中，第2、3步将数据从内核模式经过用户模式再绕回内核模式，浪费了两次复制过程。采用零拷贝技术，Kafka可以直接请求内核把磁盘中的数据复制到Socket缓冲区，而不用再经过用户模式
Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有consumer如何达成一致，来分配订阅 Topic 的每个分区。
Rebalance 的触发条件有3个
Rebalance 发生时，Group 下所有 consumer 实例都会协调在一起共同参与，kafka 能够保证尽量达到最公平的分配。但是 Rebalance 过程对 consumer group 会造成比较严重的影响。在 Rebalance 的过程中 consumer group 下的所有消费者实例都会停止工作，等待 Rebalance 过程完成。
GroupCoordinator(协调者)：协调消费者组完成消费者Rebalance的重要组件，每一个broker都会启动一个GroupCoodinator，Kafka 按照消费者组的名称将其分配给对应的GroupCoodinator进行管理；每一个GroupCoodinator只负责管理一部分消费者组，而非集群中全部的消费者组。通常是partition的leader节点的broker
如果C1消费消息超时，出入rebalance，重新分配后该消息被其他消费者消费，此时C1消费完成提交offset，导致错误
解决：Coordinator每次进行rebalance，会标记一个generation给consumer，每次rebalance该generation会+1,consumer提交offset时，会对比generation，不一致则拒绝提交。
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。
在 Kafka 中，每个 主题分区下的每条消息都被赋予了一个唯一的 ID 数值，用于标识它在分区中的位置。这个 ID 数值，就被称为位移，或者叫偏移量。一旦消息被写入到分区日志，它的位移值将不能被修改。
***to.offset.reset：消费规则，默认earliest 。
earliest: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费
latest: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据
none: topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常
Kafka 副本当前分为领导者副本和追随者副本。只有Leader副本才能 对外提供读写服务，响应Clients端的请求。Follower 副本只是采用拉(PULL)的方 式，被动地同步Leader副本中的数据，并且在Leader副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。
kafka在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式（比Zookeeper Queue的方式更高效）通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。
分区的 Leader 副本选举对用户是完全透明的，它是由 Controller 独立完成的。你需要回答的是，在哪些场景下，需要执行分区 Leader 选举。每一种场景对应于一种选举策略。当前，Kafka 有 4 种分区 Leader 选举策略。
集群 partition 备份 Kafka 支持设置针对每个 partition 备份，可以将 partition 备份到不同的 broker 上，其中 leader partition 负责读写，其他 follower 仅负责同步，当 leader 挂掉后会从 follower 中选取新的 leader 。
消息消费顺序 一个 partition 同一时刻在一个 consumer group 中只能有一个 consumer 实例在消费，从而保证了消费顺序。consumer group 中的 consumer 实例的数量不能比一个 topic 中的 partition 的数量多，否则，多出来的 consumer 无法消费到消息。Kafka 的消息在单个 partition 上是可以保证顺序的，但是在整体上无法保证顺序消费
消息消费模式 关于消费模式，Kafka 通过 消费组的概念可以灵活设置。如常见的 队列模式 即 所有的 consumer 在同一个 consumer group 下。发布订阅模式 则设置多个 consumer group 进行消费即可
acks:消息的确认机制，默认值是0。
acks=0：如果设置为0，生产者不会等待kafka的响应。
acks=1：这个配置意味着kafka会把这条消息写到本地日志文件中，但是不会等待集群中其他机器的成功响应。
acks=all：这个配置意味着leader会等待所有的follower同步完成。这个确保消息不会丢失，除非kafka集群中所有机器挂掉。这是最强的可用性保证。
面试官提出你在以前的工作中的有哪些提高，怎么回答？
***，工作能力
一个公司录取人最希望听到和看到的就是我们的工作能力，就是我们能为公司做出什么贡献，让公司看到我们的价值，这才是真正的选对人。哪个公司都不想弄去个吃干饭的，什么都不会，还得给你发工资，公司又不是慈善机构。
问到这个问题我们可以回答刚毕业的时候我们还是一直菜鸟，什么都不懂，通过之前的工作，我们积累了很多的工作经验，工作能力有了很大的提升，可以独立面对和解决一些问题。
第二，责任心
责任心很重要，我们工作的***境界就是把公司当做自己家，为了共同的奋斗目标，做出自己***的努力。面试官听到这些话就会感觉你是一个踏实上进的人，工作的时候肯定能认真负责。那么你在面试的时候很容易给面试官留下深刻印象，最后在那么多求职者中脱颖而出。
第三，交往能力
现在的社会，需要的不仅仅是我们的高智商了。我们听到过一个词叫“高分低能”，或许他们智商很高，很善于学习，但是他们能力不高。我们不需要这样的人才，只会闷头做事，生活不能自理，还不能正常与人交往。
我们工作的时候非常需要交往能力，这有时候可以让我们事半功倍。朋友多了路好走，有时候自己很不擅长的地方或许恰好对他来说轻而易举，我们需要这种互相帮助。所以人际交往能力也很重要，我们需要的是人的综合能力的不断发展和提高。
关于kafka面试和kafka面试题及答案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。