IT面試筆試題目及回答

本文格式為Word版，下載可任意編輯——IT面試筆試題目及回答IT面試筆試題目及回復(fù)

求職面試時(shí)，面試官一般都會(huì)問你一些問題，也可能是通過問卷的形式提問，怎么回復(fù)才是最好的呢?這里給大家共享一些IT面試筆試題目及回復(fù)，夢(mèng)想對(duì)大家有所扶助。

關(guān)于Tomcat的7道面試題

一、tomcat有哪些Connector?

Tomcat的Web服務(wù)器連接器支持兩種協(xié)議：AJP和HTTP，它們均定義了以二進(jìn)制格式在Web服務(wù)器和Tomcat之間舉行數(shù)據(jù)傳輸，并供給相應(yīng)的操縱命令。

AJP(ApacheJServProtocol)協(xié)議：目前正在使用的AJP協(xié)議的版本是通過JK和JK2連接器供給支持的AJP13，它基于二進(jìn)制的格式在Web服務(wù)器和Tomcat之間傳輸數(shù)據(jù)，而此前的版本AJP10和AJP11那么使用文本格式傳輸數(shù)據(jù)。

HTTP協(xié)議：誠如其名稱所表示，其是使用HTTP或HTTPS協(xié)議在Web服務(wù)器和Tomcat之間建立通信，此時(shí)，Tomcat就是一個(gè)完全功能的HTTP服務(wù)器，它需要監(jiān)聽在某端口上以接收來自于商前服務(wù)器的苦求。

二、tomcat的Valve的作用是什么?

Valve類似于過濾器，它可以工作于Engine和Host/Context之間、Host和Context之間以及Context和Web應(yīng)用程序的某資源之間。一個(gè)容器內(nèi)可以建立多個(gè)Valve，而且Valve定義的次序也抉擇了它們生效的次序。

三、Webserver和ApplicationServer的識(shí)別是什么?

最大識(shí)別，WebServer一般僅僅指Web(如servlet，jsp)的應(yīng)用服務(wù)器，ApplicationServer不僅可以是Web，還可以是Ejb等其它的應(yīng)用服務(wù)器。

webserver可以是applicationserver的一片面，也可以是單獨(dú)存在。

四、Tomcat的缺省端口是多少，怎么修改?

1)找到Tomcat目次下的conf文件夾;

2)進(jìn)入conf文件夾里面找到server.xml文件;

3)開啟server.xml文件;

4)在server.xml文件里面找到以下信息;

port=“8080”改成你想要的端口

五、Tomcat有幾種部署方式?

1)直接把Web工程放在webapps下，Tomcat會(huì)自動(dòng)將其部署

2)在server.xml文件上配置節(jié)點(diǎn)，設(shè)置相關(guān)的屬性即可

3)通過Catalina來舉行配置：進(jìn)入到conf\Catalina\localhost文件下，創(chuàng)造一個(gè)xml文件，該文件的名字就是站點(diǎn)的名字。編寫XML的方式來舉行設(shè)置。

六、tomcat容器是如何創(chuàng)造servlet類實(shí)例?用到了什么原理?

當(dāng)容器啟動(dòng)時(shí)，會(huì)讀取在webapps目次下全體的web應(yīng)用中的web.xml文件，然后對(duì)xml文件舉行解析，并讀取servlet注冊(cè)信息。然后，將每個(gè)應(yīng)用中注冊(cè)的servlet類都舉行加載，并通過反射的方式實(shí)例化。(有時(shí)候也是在第一次苦求時(shí)實(shí)例化)在servlet注冊(cè)時(shí)加上假設(shè)為正數(shù)，那么在一開頭就實(shí)例化，假設(shè)不寫或?yàn)樨?fù)數(shù)，那么第一次苦求實(shí)例化。

七、Tomcat頂層架構(gòu)小結(jié)

(1)Tomcat中只有一個(gè)Server，一個(gè)Server可以有多個(gè)Service，一個(gè)Service可以有多個(gè)Connector和一個(gè)Container;

(2)Server掌管著整個(gè)Tomcat的生死大權(quán);

(4)Service是對(duì)外供給服務(wù)的;

(5)Connector用于采納苦求并將苦求封裝成Request和Response來概括處理;

(6)Container用于封裝和管理Servlet，以及概括處理request苦求;

RabbitMQ面試題及答案

1、RabbitMQ怎么制止消息損失?

①消息耐久化;

②ACK確認(rèn)機(jī)制;

③設(shè)置集群鏡像模式;

④消息補(bǔ)償機(jī)制。

2、要保證消息耐久化告成的條件有哪些?

①聲明隊(duì)列務(wù)必設(shè)置耐久化durable設(shè)置為true。

②消息推送投遞模式務(wù)必設(shè)置耐久化，deliveryMode設(shè)置為2(耐久)。

③消息已經(jīng)到達(dá)耐久化交換器。

④消息已經(jīng)到達(dá)耐久化隊(duì)列。

以上四個(gè)條件都得志才能保證消息耐久化告成。

3、RabbitMQ耐久化有什么缺點(diǎn)?

耐久化的缺地就是降低了服務(wù)器的吞吐量，由于使用的是磁盤而非內(nèi)存存儲(chǔ)，從而降低了吞吐量?？杀M量使用ssd硬盤來緩解吞吐量的問題。

4、RabbitMQ有幾種播送類型?

三種播送模式：

①fanout：全體bind到此exchange的queue都可以接收消息(純播送，綁定到RabbitMQ的采納者都能收到消息);

②direct：通過routingKey和exchange抉擇的那個(gè)唯一的queue可以接收消息;

③topic：全體符合routingKey(此時(shí)可以是一個(gè)表達(dá)式)的routingKey所bind的queue可以接收消息;

5、RabbitMQ中vhost的作用是什么?

vhost可以理解為虛擬broker，即mini-RabbitMQserver。其內(nèi)部均含有獨(dú)立的queue、exchange和binding等，但最最重要的是，其擁有獨(dú)立的權(quán)限系統(tǒng)，可以做到vhost范圍的用戶操縱。當(dāng)然，從RabbitMQ的全局角度，vhost可以作為不同權(quán)限隔離的手段(一個(gè)典型的例子就是不同的應(yīng)用可以跑在不同的vhost中)。

Zookeeper面試題

1、集群中為什么要有主節(jié)點(diǎn)?

在分布式環(huán)境中，有些業(yè)務(wù)規(guī)律只需要集群中的某一臺(tái)機(jī)器舉行執(zhí)行，其他的機(jī)器可以共享這個(gè)結(jié)果，這樣可以大大裁減重復(fù)計(jì)算，提高性能，于是就需要舉行l(wèi)eade選舉。

2、集群中有3臺(tái)服務(wù)器，其中一個(gè)節(jié)點(diǎn)宕機(jī)，這個(gè)時(shí)候Zookeeper還可以使用嗎?

可以持續(xù)使用，單數(shù)服務(wù)器只要沒超過一半的服務(wù)器宕機(jī)就可以持續(xù)使用。

集群規(guī)矩為2N+1臺(tái)，N0，即最少需要3臺(tái)。

3、說一下兩階段提交和三階段提交的過程?分別有什么問題?

(一)兩階段提交協(xié)議2PC

1.第一階段(投票階段)：

(1)協(xié)調(diào)者節(jié)點(diǎn)向全體參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作(vote)，并開頭等待各參與者節(jié)點(diǎn)的響應(yīng);

(2)參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的全體事務(wù)操作，并將Undo信息和Redo信息寫入日志。

(3)各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問。假設(shè)參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行告成，那么它返回一個(gè)“同意”消息;假設(shè)參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗，那么它返回一個(gè)“中止”消息。

2.其次階段(提交執(zhí)行階段)：

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從全體參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為“同意”時(shí)：

(1)協(xié)調(diào)者節(jié)點(diǎn)向全體參與者節(jié)點(diǎn)發(fā)出“正式提交(commit)”的苦求;

(2)參與者節(jié)點(diǎn)正式完成操作，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源;

(3)參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送“完成”消息;

(4)協(xié)調(diào)者節(jié)點(diǎn)受到全體參與者節(jié)點(diǎn)反應(yīng)的“完成”消息后，完成事務(wù)。

(二)兩階段提交存在的問題：

1.執(zhí)行過程中，全體參與節(jié)點(diǎn)都是事務(wù)阻塞型的。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問公共資源不得不處于阻塞狀態(tài);

2.參與者發(fā)生故障：協(xié)調(diào)者需要給每個(gè)參與者額外指定超時(shí)機(jī)制，超時(shí)后整個(gè)事務(wù)失敗;

3.協(xié)調(diào)者發(fā)生故障：參與者會(huì)一向阻塞下去。需要額外的備機(jī)舉行容錯(cuò);

4.二階段無法解決的問題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒人知道事務(wù)是否被已經(jīng)提交。

(三)三階段提交協(xié)議3PC

與兩階段提交不同的是，三階段提交有兩個(gè)改動(dòng)點(diǎn)：

1.引入超時(shí)機(jī)制。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制;

2.在第一階段和其次階段中插入一個(gè)打定階段。保證了在結(jié)果提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

也就是說，除了引入超時(shí)機(jī)制之外，3PC把2PC的打定階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個(gè)階段。

1.CanCommit階段

3PC的CanCommit階段其實(shí)和2PC的打定階段很像。協(xié)調(diào)者向參與者發(fā)送commit苦求，參與者假設(shè)可以提交就返回Yes響應(yīng)，否那么返回No響應(yīng)。

(1)事務(wù)詢問：協(xié)調(diào)者向參與者發(fā)送CanCommit苦求。詢問是否可以執(zhí)行事務(wù)提交操作。然后開頭等待參與者的響應(yīng)。

(2)響應(yīng)反應(yīng)：參與者接到CanCommit苦求之后，正常處境下，假設(shè)其自身認(rèn)為可以順?biāo)靾?zhí)行事務(wù)，那么返回Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)。否那么反應(yīng)No。

2.PreCommit階段

協(xié)調(diào)者根據(jù)參與者的回響處境來抉擇是否可以持續(xù)事務(wù)的PreCommit操作。根據(jù)響應(yīng)處境，有以下兩種可能：

假使協(xié)調(diào)者從全體的參與者獲得的反應(yīng)都是Yes響應(yīng)，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行。

(1)發(fā)送預(yù)提交苦求：協(xié)調(diào)者向參與者發(fā)送PreCommit苦求，并進(jìn)入Prepared階段。

(2)事務(wù)預(yù)提交：參與者接收到PreCommit苦求后，會(huì)執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。

(3)響應(yīng)反應(yīng)：假設(shè)參與者告成的執(zhí)行了事務(wù)操作，那么返回ACK響應(yīng)，同時(shí)開頭等待最終指令。

假使有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)之后，協(xié)調(diào)者都沒有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。

(1)發(fā)送中斷苦求：協(xié)調(diào)者向全體參與者發(fā)送abort苦求。

(2)中斷事務(wù)：參與者收到來自協(xié)調(diào)者的abort苦求之后(或超時(shí)之后，仍未收到協(xié)調(diào)者的苦求)，執(zhí)行事務(wù)的中斷。

3.doCommit階段

該階段舉行真正的事務(wù)提交，也可以分為以下兩種處境。

3.1執(zhí)行提交

(1)發(fā)送提交苦求：協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向全體參與者發(fā)送doCommit苦求。

(2)事務(wù)提交：參與者接收到doCommit苦求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放全體事務(wù)資源。

(3)響應(yīng)反應(yīng)：事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送ACK響應(yīng)。

(4)完成事務(wù)：協(xié)調(diào)者接收到全體參與者的ACK響應(yīng)之后，完成事務(wù)。

3.2中斷事務(wù)

協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)(可能是采納者發(fā)送的不是ACK響應(yīng)，也可能響應(yīng)超時(shí))，那么就會(huì)執(zhí)行中斷事務(wù)。

(1)發(fā)送中斷苦求：協(xié)調(diào)者向全體參與者發(fā)送abort苦求。

(2)事務(wù)回滾：參與者接收到abort苦求之后，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放全體的事務(wù)資源。

(3)反應(yīng)結(jié)果：參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息。

(4)中斷事務(wù)：協(xié)調(diào)者接收到參與者反應(yīng)的ACK消息之后，執(zhí)行事務(wù)的中斷。

(四)三階段提交的問題：

網(wǎng)絡(luò)分區(qū)可能會(huì)帶來問題。需要四階段解決：四階段直接調(diào)用遠(yuǎn)程服務(wù)的數(shù)據(jù)狀態(tài)，確定當(dāng)前數(shù)據(jù)一致性的處境。

4、Zookeeper宕機(jī)如何處理?

Zookeeper本身也是集群，推舉配置不少于3個(gè)服務(wù)器。Zookeeper自身也要保證當(dāng)一個(gè)節(jié)點(diǎn)宕機(jī)時(shí)，其他節(jié)點(diǎn)會(huì)持續(xù)供給服務(wù)。假設(shè)是一個(gè)Follower宕機(jī)，還有2臺(tái)服務(wù)器供給訪問，由于Zookeeper上的數(shù)據(jù)是有多個(gè)副本的，數(shù)據(jù)并不會(huì)損失;假設(shè)是一個(gè)Leader宕機(jī)，Zookeeper會(huì)選舉出新的Leader。

Zookeeper集群的機(jī)制是只要超過半數(shù)的節(jié)點(diǎn)正常，集群就能正常供給服務(wù)。只有在Zookeeper節(jié)點(diǎn)掛得太多，只剩一半或不到一半節(jié)點(diǎn)能工作，集群才失效。所以：

3個(gè)節(jié)點(diǎn)的cluster可以掛掉1個(gè)節(jié)點(diǎn)(leader可以得到2票1.5)

2個(gè)節(jié)點(diǎn)的cluster就不能掛掉任何1個(gè)節(jié)點(diǎn)了(leader可以得到1票=1)

5、說下四種類型的數(shù)據(jù)節(jié)點(diǎn)Znode?

1.PERSISTENT：耐久節(jié)點(diǎn)，除非手動(dòng)刪除，否那么節(jié)點(diǎn)一向存在于Zookeeper上。

2.EPHEMERAL：臨節(jié)令點(diǎn)，臨節(jié)令點(diǎn)的生命周期與客戶端會(huì)話綁定，一旦客戶端會(huì)話失效(客戶端與Zookeeper連接斷開不確定會(huì)話失效)，那么這個(gè)客戶端創(chuàng)造的全體臨節(jié)令點(diǎn)都會(huì)被移除。

3.PERSISTENT_SEQUENTIAL：耐久依次節(jié)點(diǎn)，根本特性同耐久節(jié)點(diǎn)，只是增加了依次屬性，節(jié)點(diǎn)名后邊會(huì)追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。

4.EPHEMERAL_SEQUENTIAL：臨時(shí)依次節(jié)點(diǎn)，根本特性同臨節(jié)令點(diǎn)，增加了依次屬性，節(jié)點(diǎn)名后邊會(huì)追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。

6、Zookeeper和Dubbo的關(guān)系?

Dubbo的將注冊(cè)中心舉行抽象，是得它可以外接不同的存儲(chǔ)媒介給注冊(cè)中心供給服務(wù)，有ZooKeeper，Memcached，Redis等。

引入了ZooKeeper作為存儲(chǔ)媒介，也就把Zo