前言

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

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

1.1 expire和cache-control字段含義

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

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

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

2.1 https 原理

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

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

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

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

數(shù)字證書構(gòu)成

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

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

3.1 tcp 連接

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

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

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

3.2 time_wait狀態(tài)

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

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

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

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

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

4.什么是虛擬內(nèi)存? 什么是物理內(nèi)存？

4.1 什么是虛擬內(nèi)存？

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

4.2 什么是物理內(nèi)存

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

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

4.3 虛擬內(nèi)存如何映射到物理內(nèi)存？

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

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

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

6.Eureka原理，是否是強(qiáng)一致性，eureka集群。宕機(jī)了服務(wù)還能調(diào)用么？Eureka和ZooKeeper對比

6.1 eureka架構(gòu)

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

架構(gòu)圖如下：

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

6.2 基于集群的Eureka架構(gòu)圖

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

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

6.3 宕機(jī)了服務(wù)還能調(diào)用么？

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

6.4 Eureka和ZooKeeper對比

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

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

Hystrix 工作流程圖如下:

1. 構(gòu)建命令

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

2. 執(zhí)行命令

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

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

3. 檢查緩存

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. 聊聊zookeeper選舉機(jī)制

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

9.1 服務(wù)器啟動的Leader選舉

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

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

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

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

• 2.2 接受來自各個服務(wù)器的投票

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

• 2.3. 處理投票

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

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

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

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

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

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

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

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

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

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

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

6. 投票結(jié)束，服務(wù)器3當(dāng)選為Leader

9.2 ?服務(wù)器運行期間的Leader選舉

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

1. 變更狀態(tài)

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

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

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

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

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

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

10. 算法：給定一個字符串s ，請你找出其中不含有重復(fù)字符的最長連續(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;
}


參考與感謝

[1]Spring Cloud 源碼學(xué)習(xí)之 Hystrix 工作原理: https://chenyongjun.vip/articles/88

[2]Zookeeper——一致性協(xié)議:Zab協(xié)議: https://www.jianshu.com/p/2bceacd60b8a