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

1.1 expire和cache-control字段含義

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

1.2 常見HTTP狀態碼

2.https原理，數字簽名，數字證書。

2.1 https 原理

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

用戶在瀏覽器里輸入一個https網址，然后連接到server的443端口。

服務器必須要有一套數字證書，可以自己制作，也可以向組織申請，區別就是自己頒發的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。

服務器將自己的數字證書（含有公鑰）發送給客戶端。

客戶端收到服務器端的數字證書之后，會對其進行檢查，如果不通過，則彈出警告框。如果證書沒問題，則生成一個密鑰（對稱加密），用證書的公鑰對它加密。

客戶端會發起HTTPS中的第二個HTTP請求，將加密之后的客戶端密鑰發送給服務器。

服務器接收到客戶端發來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對返回數據進行對稱加密，這樣數據就變成了密文。

服務器將加密后的密文返回給客戶端。

客戶端收到服務器發返回的密文，用自己的密鑰（客戶端密鑰）對其進行對稱解密，得到服務器返回的數據。

2.2 數字簽名，數字證書

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

數字證書構成

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

3.tcp連接client和server有哪些狀態，time_wait狀態

3.1 tcp 連接

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

開始客戶端和服務器都處于CLOSED狀態，然后服務端開始監聽某個端口，進入LISTEN狀態

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

3.2 time_wait狀態

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

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

TIME-WAIT 狀態為什么需要等待 2MSL

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

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

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

4.1 什么是虛擬內存？

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

4.2 什么是物理內存

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

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

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

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

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

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

.3K的內存。

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

6.1 eureka架構

注冊中心是分布式開發的核心組件之一，而eureka是spring cloud推薦的注冊中心實現。

架構圖如下：

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

6.2 基于集群的Eureka架構圖

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

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

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

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

6.4 Eureka和ZooKeeper對比

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

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

Hystrix 工作流程圖如下:

構建命令

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

執行命令

有四種方式執行command。分別是：

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

檢查緩存

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

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

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

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

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

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

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

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

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

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

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

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

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

Zab協議要求每個 Leader 都要經歷三個階段：發現，同步，廣播。

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

9. 聊聊zookeeper選舉機制

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

9.1 服務器啟動的Leader選舉

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

服務器1（myid=1）啟動，當前只有一臺服務器，無法完成Leader選舉

服務器2（myid=2）啟動，此時兩臺服務器能夠相互通訊，開始進入Leader選舉階段

• 2.1. 每個服務器發出一個投票

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

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

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

• 2.3. 處理投票

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

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

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

• 2.4. 統計投票

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

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

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

服務器4啟動，發起一次選舉。

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

服務器5啟動，發起一次選舉。

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

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

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

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

變更狀態

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

每個服務器發起投票

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

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

處理投票

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

統計投票

改變服務器狀態

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

可以使用滑動窗口實現，代碼如下：

public int lengthOfLongestSubstring2(String s) {int n = s.length();if (n <= 1) return n;int maxLen = 1;//左、右指針int left = 0, right = 0;Set<Character> window = new HashSet<>();while (right < n) {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; }

推薦：大家可以關注我，點擊下方小插件掃碼即可免費獲取以下資料，里面有源碼分析、性能優化、微服務架構、工程化、分布式等知識點。走的就是高端路線 下圖是資料的一部分知識點 有用沒用一看就知道的：

?

總結

以上是生活随笔為你收集整理的今日头条一面：十道经典面试题解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。