宇宙條一面：十道經典面試題解析

前言

大家好，我是撿田螺的小男孩。（星標置頂田螺哥，學起來?。?/p>

有位朋友面試了宇宙條，后端方向。整理了這幾道面試真題以及答案，如有錯誤，歡迎大家留言區(qū)討論哈。金九銀十沖刺，面試的小伙伴加油呀。

1.http請求頭里，expire和cache-control字段含義，說說HTTP狀態(tài)碼

1.1 expire和cache-control字段含義

• Cache-Control是HTTP/1.1的頭字段，用來區(qū)分對緩存機制的支持情況，請求頭和響應頭都支持這個屬性。通過它提供的不同的值來定義緩存策略。主要有public、private、no-cache等值。
• expires是http1.0的頭字段，過期時間，如果設置了時間，則瀏覽器會在設置的時間內直接讀取緩存，不再請求。

1.2 常見HTTP狀態(tài)碼

2.https原理，數(shù)字簽名，數(shù)字證書。

2.1 https 原理

• HTTPS = HTTP + SSL/TLS，即用SSL/TLS對數(shù)據(jù)進行加密和解密，Http進行傳輸。
• SSL，即Secure Sockets Layer（安全套接層協(xié)議），是網絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。
• TLS，即Transport Layer Security(安全傳輸層協(xié)議)，它是SSL 3.0的后續(xù)版本。

1. 用戶在瀏覽器里輸入一個https網址，然后連接到server的443端口。
2. 服務器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。
3. 服務器將自己的數(shù)字證書（含有公鑰）發(fā)送給客戶端。
4. 客戶端收到服務器端的數(shù)字證書之后，會對其進行檢查，如果不通過，則彈出警告框。如果證書沒問題，則生成一個密鑰（對稱加密），用證書的公鑰對它加密。
5. 客戶端會發(fā)起HTTPS中的第二個HTTP請求，將加密之后的客戶端密鑰發(fā)送給服務器。
6. 服務器接收到客戶端發(fā)來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密，這樣數(shù)據(jù)就變成了密文。
7. 服務器將加密后的密文返回給客戶端。
8. 客戶端收到服務器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對其進行對稱解密，得到服務器返回的數(shù)據(jù)。

2.2 數(shù)字簽名，數(shù)字證書

了解過Https原理的小伙伴，都知道數(shù)字證書這玩意。為了避免公鑰被篡改，引入了數(shù)字證書，如下：

數(shù)字證書構成

• 公鑰和個人信息，經過Hash算法加密，形成消息摘要；將消息摘要拿到擁有公信力的認證中心（CA），用它的私鑰對消息摘要加密，形成數(shù)字簽名.
• 公鑰和個人信息、數(shù)字簽名共同構成數(shù)字證書。

3.tcp連接client和server有哪些狀態(tài)，time_wait狀態(tài)

3.1 tcp 連接

tcp連接時，客戶端client 有SYN_SEND、ESTABLISHED狀態(tài)，服務端server有SYN_RCVD、ESTABLISHED狀態(tài)。

開始客戶端和服務器都處于CLOSED狀態(tài)，然后服務端開始監(jiān)聽某個端口，進入LISTEN狀態(tài)

• 第一次握手(SYN=1, seq=x)，發(fā)送完畢后，客戶端進入 SYN_SEND 狀態(tài)
• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 發(fā)送完畢后，服務器端進入 SYN_RCVD 狀態(tài)。
• 第三次握手(ACK=1，ACKnum=y+1)，發(fā)送完畢后，客戶端進入 ESTABLISHED 狀態(tài)，當服務器端接收到這個包時,也進入 ESTABLISHED 狀態(tài)，TCP 握手，即可以開始數(shù)據(jù)傳輸。

3.2 time_wait狀態(tài)

可以先回憶下TCP的四次揮手哈，

• 第一次揮手(FIN=1，seq=u)，發(fā)送完畢后，客戶端進入FIN_WAIT_1狀態(tài)
• 第二次揮手(ACK=1，ack=u+1,seq =v)，發(fā)送完畢后，服務器端進入CLOSE_WAIT狀態(tài)，客戶端接收到這個確認包之后，進入FIN_WAIT_2狀態(tài)
• 第三次揮手(FIN=1，ACK1,seq=w,ack=u+1)，發(fā)送完畢后，服務器端進入LAST_ACK狀態(tài)，等待來自客戶端的最后一個ACK。
• 第四次揮手(ACK=1，seq=u+1,ack=w+1)，客戶端接收到來自服務器端的關閉請求，發(fā)送一個確認包，并進入TIME_WAIT狀態(tài)，等待了某個固定時間（兩個最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒有收到服務器端的 ACK ，認為服務器端已經正常關閉連接，于是自己也關閉連接，進入 CLOSED 狀態(tài)。服務器端接收到這個確認包之后，關閉連接，進入 CLOSED 狀態(tài)。

TIME-WAIT 狀態(tài)為什么需要等待 2MSL

2MSL，2 Maximum Segment Lifetime，即兩個最大段生命周期

• 1個 MSL 保證四次揮手中主動關閉方最后的ACK 報文能最終到達對端
• 1個 MSL 保證對端沒有收到 ACK 那么進行重傳的FIN報文能夠到達

4.什么是虛擬內存? 什么是物理內存？

4.1 什么是虛擬內存？

虛擬內存，是虛擬出來的內存，它的核心思想就是確保每個程序擁有自己的地址空間，地址空間被分成多個塊，每一塊都有連續(xù)的地址空間。同時物理空間也分成多個塊，塊大小和虛擬地址空間的塊大小一致，操作系統(tǒng)會自動將虛擬地址空間映射到物理地址空間，程序只需關注虛擬內存，請求的也是虛擬內存，真正使用卻是物理內存。

4.2 什么是物理內存

物理內存，指通過物理內存條而獲得的內存空間，而虛擬內存則是指將硬盤的一塊區(qū)域劃分來作為內存。

我們常說的物理內存大小，其實是指內存條的大小。一般買電腦時，我們都會看下內存條是多大容量的，話說如果內存條大小是100G，那這100G就都能夠被使用嗎？不一定的，更多的還是要看CPU地址總線的位數(shù)，如果地址總線只有20位，那么它的尋址空間就是1MB，即使可以安裝100G的內存條也沒有意義，也只能視物理內存大小為1MB。

4.3 虛擬內存如何映射到物理內存？

如下圖，CPU里有一個內存管理單元（Memory Management Unit），簡稱為MMU，虛擬內存不是直接送到內存總線，而是先給到MMU，由MMU來把虛擬地址映射到物理地址，程序只需要管理虛擬內存就好，映射的邏輯自然有其它模塊自動處理。

5.一臺機器最多可以建立多少個tcp連接，client端，server端，超過了怎么辦

• TCP連接的客戶端機：每一個ip可建立的TCP連接理論受限于ip_local_port_range參數(shù)，也受限于65535。但可以通過配置多ip的方式來加大自己的建立連接的能力。
• TCP連接的服務器機：每一個監(jiān)聽的端口雖然理論值很大，但這個數(shù)字沒有實際意義。最大并發(fā)數(shù)取決你的內存大小，每一條靜止狀態(tài)的TCP連接大約需要吃3 .3K的內存。

6.Eureka原理，是否是強一致性，eureka集群。宕機了服務還能調用么？Eureka和ZooKeeper對比

6.1 eureka架構

注冊中心是分布式開發(fā)的核心組件之一，而eureka是spring cloud推薦的注冊中心實現(xiàn)。

架構圖如下：

• Eureka Server：提供服務注冊和發(fā)現(xiàn)，多個Eureka Server之間會同步數(shù)據(jù)，做到狀態(tài)一致
• Service Provider：服務提供方，將自身服務注冊到Eureka，從而使服務消費方能夠找到
• Service Consumer：服務消費方，從Eureka獲取注冊服務列表，從而能夠消費服務

6.2 基于集群的Eureka架構圖

Eureka server可以集群部署，多個節(jié)點之間會通過Replicate（異步方式）進行數(shù)據(jù)同步，保證數(shù)據(jù)最終一致性。Eureka Server作為一個開箱即用的服務注冊中心，提供的功能包括：服務注冊、接收服務心跳、服務剔除、服務下線等。

服務啟動后向Eureka注冊，Eureka Server會將注冊信息向其他Eureka Server進行同步，當服務消費者要調用服務提供者，則向服務注冊中心獲取服務提供者地址，然后會將服務提供者地址緩存在本地，下次再調用時，則直接從本地緩存中取，完成一次調用。

6.3 宕機了服務還能調用么？

Eureka 掛了，微服務是可以調通的，不過有個前提：provider的地址沒變！如果 provider換了一個 IP 地址或者端口，這個時候，consumer 就無法及時感知到這種變化，就會調不通。

6.4 Eureka和ZooKeeper對比

• Zookeeper保證CP(一致性和分區(qū)容錯性)，但是不保證可用性，ZK的leader選舉期間，是不可用的。
• Eureka保證AP（可用性和分區(qū)容錯性），它優(yōu)先保證可用性，幾個節(jié)點掛掉不會影響正常節(jié)點的工作。

7.Hystrix了解嘛？說說Hystrix的工作原理

Hystrix 工作流程圖如下:

1. 構建命令

Hystrix 提供了兩個Command， HystrixCommand 和 HystrixObservableCommand，可以使用這兩個對象來包裹待執(zhí)行的任務。

2. 執(zhí)行命令

有四種方式執(zhí)行command。分別是：

• R execute()：同步執(zhí)行，從依賴服務得到單一結果對象
• Future queue()：異步執(zhí)行，返回一個 Future 以便獲取執(zhí)行結果，也是單一結果對象
• Observable observe()：hot observable，創(chuàng)建Observable后會訂閱Observable，可以返回多個結果
• Observable toObservable()：cold observable，返回一個Observable，只有訂閱時才會執(zhí)行，可以返回多個結果

3. 檢查緩存

如果啟用了 Hystrix Cache，任務執(zhí)行前將先判斷是否有相同命令執(zhí)行的緩存。如果有則直接返回緩存的結果；如果沒有緩存的結果，但啟動了緩存，將緩存本次執(zhí)行結果以供后續(xù)使用。

4. 檢查斷路器是否打開 斷路器(circuit-breaker)和保險絲類似，保險絲在發(fā)生危險時將會燒斷以保護電路，而斷路器可以在達到我們設定的閥值時觸發(fā)短路(比如請求失敗率達到50%)，拒絕執(zhí)行任何請求。

如果斷路器被打開，Hystrix 將不會執(zhí)行命令，直接進入Fallback處理邏輯。

5. 檢查線程池/信號量情況 Hystrix 隔離方式有線程池隔離和信號量隔離。當使用Hystrix線程池時，Hystrix 默認為每個依賴服務分配10個線程，當10個線程都繁忙時，將拒絕執(zhí)行命令。信號量同理。

6. 執(zhí)行具體的任務 通過HystrixObservableCommand.construct() 或者 HystrixCommand.run() 來運行用戶真正的任務。

7. 計算鏈路健康情況 每次開始執(zhí)行command、結束執(zhí)行command以及發(fā)生異常等情況時，都會記錄執(zhí)行情況，例如：成功、失敗、拒絕以及超時等情況，會定期處理這些數(shù)據(jù)，再根據(jù)設定的條件來判斷是否開啟斷路器。

8. 命令失敗時執(zhí)行 Fallback 邏輯 在命令失敗時執(zhí)行用戶指定的 Fallback 邏輯。上圖中的斷路、線程池拒絕、信號量拒絕、執(zhí)行執(zhí)行、執(zhí)行超時都會進入 Fallback 處理。

9. 返回執(zhí)行結果 原始結果將以Observable形式返回，在返回給用戶之前，會根據(jù)調用方式的不同做一些處理。

8.zookeeper一致性保證，zab協(xié)議原理，zookeeper屬于哪種一致性，強一致性么，還是最終一致性

Zab協(xié)議，英文全稱是Zookeeper Atomic Broadcast（Zookeeper原子廣播）。Zookeeper是通過Zab協(xié)議來保證分布式事務的最終一致性。

Zab協(xié)議是為分布式協(xié)調服務Zookeeper專門設計的一種支持崩潰恢復的原子廣播協(xié)議 ，是Zookeeper保證數(shù)據(jù)一致性的核心算法。Zab借鑒了Paxos算法，是一種通用的分布式一致性算法。

基于Zab協(xié)議，Zookeeper實現(xiàn)了一種主備模型（即Leader和Follower模型）的系統(tǒng)架構來保證集群中各個副本之間數(shù)據(jù)的一致性。就是指只有一臺Leader節(jié)點負責處理外部的寫事務請求，然后它（Leader）將數(shù)據(jù)同步到其他Follower節(jié)點。

Zookeeper 客戶端會隨機的鏈接到 zookeeper 集群中的一個節(jié)點，如果是讀請求，就直接從當前節(jié)點中讀取數(shù)據(jù)；如果是寫請求，那么節(jié)點就會向Leader提交事務，Leader 接收到事務提交，會廣播該事務，只要超過半數(shù)節(jié)點寫入成功，該事務就會被提交。

Zab協(xié)議要求每個 Leader 都要經歷三個階段：發(fā)現(xiàn)，同步，廣播。

• 發(fā)現(xiàn)：要求zookeeper集群必須選舉出一個 Leader 進程，同時 Leader 會維護一個 Follower 可用客戶端列表。將來客戶端可以和這些 Follower節(jié)點進行通信。
• 同步：Leader 要負責將本身的數(shù)據(jù)與 Follower 完成同步，做到多副本存儲。這樣也是提現(xiàn)了CAP中的高可用和分區(qū)容錯。Follower將隊列中未處理完的請求消費完成后，寫入本地事務日志中。
• 廣播：Leader 可以接受客戶端新的事務Proposal請求，將新的Proposal請求廣播給所有的 Follower。

9. 聊聊zookeeper選舉機制

服務器啟動或者服務器運行期間（Leader掛了），都會進入Leader選舉，我們來看一下~假設現(xiàn)在ZooKeeper集群有五臺服務器，它們myid分別是服務器1、2、3、4、5，如圖：

9.1 服務器啟動的Leader選舉

zookeeper集群初始化階段，服務器（myid=1-5）依次啟動，開始zookeeper選舉Leader~

1. 服務器1（myid=1）啟動，當前只有一臺服務器，無法完成Leader選舉
2. 服務器2（myid=2）啟動，此時兩臺服務器能夠相互通訊，開始進入Leader選舉階段

• 2.1. 每個服務器發(fā)出一個投票

服務器1和服務器2都將自己作為Leader服務器進行投票，投票的基本元素包括：服務器的myid和ZXID，我們以（myid，ZXID）形式表示。初始階段，服務器1和服務器2都會投給自己，即服務器1的投票為（1,0），服務器2的投票為（2,0），然后各自將這個投票發(fā)給集群中的其他所有機器。

• 2.2 接受來自各個服務器的投票

每個服務器都會接受來自其他服務器的投票。同時，服務器會校驗投票的有效性，是否本輪投票、是否來自LOOKING狀態(tài)的服務器。

• 2.3. 處理投票

收到其他服務器的投票，會將被人的投票跟自己的投票PK，PK規(guī)則如下：

• 優(yōu)先檢查ZXID。ZXID比較大的服務器優(yōu)先作為leader。
• 如果ZXID相同的話，就比較myid，myid比較大的服務器作為leader。

服務器1的投票是（1,0），它收到投票是（2,0），兩者zxid都是0，因為收到的myid=2，大于自己的myid=1，所以它更新自己的投票為（2,0），然后重新將投票發(fā)出去。對于服務器2呢，即不再需要更新自己的投票，把上一次的投票信息發(fā)出即可。

• 2.4. 統(tǒng)計投票

每次投票后，服務器會統(tǒng)計所有投票，判斷是否有過半的機器接受到相同的投票信息。服務器2收到兩票，少于3（n/2+1,n為總服務器），所以繼續(xù)保持LOOKING狀態(tài)

3. 服務器3（myid=3）啟動，繼續(xù)進入Leader選舉階段

• 3.1 跟前面流程一致，服務器1和2先投自己一票，因為服務器3的myid最大，所以大家把票改投給它。此時，服務器為3票（大于等于n/2+1）,所以服務器3當選為Leader。服務器1，2更改狀態(tài)為FOLLOWING，服務器3更改狀態(tài)為LEADING；

4. 服務器4啟動，發(fā)起一次選舉。

• 4.1 此時服務器1，2，3已經不是LOOKING狀態(tài)，不會更改選票信息。選票信息結果：服務器3為3票，服務器4為1票。服務器4并更改狀態(tài)為FOLLOWING；

5. 服務器5啟動，發(fā)起一次選舉。

• 同理，服務器也是把票投給服務器3，服務器5并更改狀態(tài)為FOLLOWING；

6. 投票結束，服務器3當選為Leader

9.2 ?服務器運行期間的Leader選舉

zookeeper集群的五臺服務器（myid=1-5）正在運行中，突然某個瞬間，Leader服務器3掛了，這時候便開始Leader選舉~

1. 變更狀態(tài)

Leader 服務器掛了之后，余下的非Observer服務器都會把自己的服務器狀態(tài)更改為LOOKING，然后開始進入Leader選舉流程。

2. 每個服務器發(fā)起投票

每個服務器都把票投給自己，因為是運行期間，所以每臺服務器的ZXID可能不相同。假設服務1,2,4,5的zxid分別為333,666,999,888，則分別產生投票（1,333），（2，666），（4,999）和（5,888），然后各自將這個投票發(fā)給集群中的其他所有機器。

3. 接受來自各個服務器的投票
4. 處理投票

投票規(guī)則是跟Zookeeper集群啟動期間一致的，優(yōu)先檢查ZXID，大的優(yōu)先作為Leader，所以顯然服務器zxid=999具有優(yōu)先權。

5. 統(tǒng)計投票
6. 改變服務器狀態(tài)

10. 算法：給定一個字符串s ，請你找出其中不含有重復字符的最長連續(xù)子字符串的長度。

可以使用滑動窗口實現(xiàn)，代碼如下：

public?int?lengthOfLongestSubstring2(String?s)?{
????int?n?=?s.length();
????if?(n?<=?1)?return?n;
????int?maxLen?=?1;

????//左、右指針
????int?left?=?0,?right?=?0;
??
????Set?window?=?new?HashSet<>();
????while?(right?????????char?rightChar?=?s.charAt(right);
????????while?(window.contains(rightChar))?{
????????????window.remove(s.charAt(left));
????????????left++;
????????}
????????//最大長度對比
????????maxLen?=?Math.max(maxLen,?right?-?left?+?1);
????????window.add(rightChar);
????????right++;
????}

????return?maxLen;
}

參考與感謝