艱難的校招之路（Java綜合面經系列三）

艱難的秋招之路（Java綜合面經（分布式與微服務和作業系統））

• 寫在前面
• 一、分布式與微服務
• • • 1.談談你對微服務的了解
    • 2.負載均衡政策有哪幾種方式
    • 3.SOA和微服務的差別
    • 4.如何實作分布式鎖
    • 5.限流的算法有哪些？
    • 6.CAP理論和base定理
    • 7.了解RPC嗎？有哪些常見的 RPC 架構？如果讓你自己設計 RPC 架構你會如何設計？
    • 8.為什麼要網關？你知道有哪些常見的網關系統？
    • 9.為什麼要分布式 id ？分布式 id 生成政策有哪些？
    • 10.服務熔斷和服務降級的差別
    • 11.分布式系統需要考慮哪些問題
    • 12.你的系統你會從哪些方面考慮去優化
    • 13.你的服務挂了怎麼處理
    • 14.服務注冊中心的工作流程
• 作業系統
• • • 1.線程和程序的差別 (協程)
    • 2.程序的排程算法
    • 3.虛拟記憶體解決了什麼問題？（分頁，分段，段頁的差別）
    • 4.作業系統的作用和功能
    • 5.死鎖的定義以及如何避免死鎖(銀行家算法)
    • 6.程序的通信方式（實作原理，具體應用場景）
    • 7.線程的七态模型
    • 8. 程序間同步與互斥的差別，線程同步的方式
    • 9.動态連結庫與靜态連結庫的差別
    • 10.linux的各種IO模型？（重點掌握epoll，底層結構紅黑樹 + 連結清單，能夠說出為什麼在管理數百萬連接配接的過程效率還好，以及ET模式和LT模式）
    • 11.核心态和使用者态的差別以及轉換？（什麼情況會轉化：中斷，各種中斷進行分類）
    • 12.linux底層的零拷貝技術（經曆4次 ->3次 ->2次拷貝的優化曆程）
    • 13.作業系統大核心和微核心之間的差別以及各自的好處？
    • 14.僵屍程序和孤兒程序産生的原因以及解決方式？
    • 15.作業系統的各自排程方式

寫在前面

這是我校招面經系列第3部曲，關于Java進階部分的分布式與微服務。之前介紹過的計網和Java基礎以及資料庫和架構都可以結合的看下。如有錯誤或者有新的問題，歡迎留言或私信。

一、分布式與微服務

1.談談你對微服務的了解

微服務在近幾年大火，它具備了靈活部署、可擴充、技術異構等優點，但同時也帶來了開發、運維的複雜性。是否要采用微服務架構需要根據系統的特點，結合企業的組織架構、團隊能力等多個方面進行綜合的判斷，而不是為了微服務而微服務。自己瞎吹吧。

2.負載均衡政策有哪幾種方式

1. 輪詢（預設）

   每個請求按時間順序逐一配置設定到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。

2. 指定權重

   指定輪詢幾率，weight和通路比率成正比，用于後端伺服器性能不均的情況。

3. IP綁定 ip_hash

   每個請求按通路ip的hash結果配置設定，這樣每個訪客固定通路一個後端伺服器，可以解決session的問題。

4. fair（第三方）

   按後端伺服器的響應時間來配置設定請求，響應時間短的優先配置設定。

5. url_hash（第三方）

   按通路url的hash結果來配置設定請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。

3.SOA和微服務的差別

• 微服務剔除SOA中複雜的ESB企業服務總線，所有的業務智能邏輯在服務内部處理，使用Http（Rest API）進行輕量化通訊
• SOA強調按水準架構劃分為：前、後端、資料庫、測試等，微服務強調按垂直架構劃分，按業務能力劃分，每個服務完成一種特定的功能，服務即産品
• SOA将元件以library的方式和應用部署在同一個程序中運作，微服務則是各個服務獨立運作。
• 傳統應用傾向于使用統一的技術平台來解決所有問題，微服務可以針對不同業務特征選擇不同技術平台，去中心統一化，發揮各種技術平台的特長。
• SOA架構強調的是異構系統之間的通信和解耦合；（一種粗粒度、松耦合的服務架構）
• 微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。

4.如何實作分布式鎖

• 資料庫實作分布式鎖
• Redis實作分布式鎖
• Zookeeper實作分布式鎖

5.限流的算法有哪些？

1. 固定視窗計數器算法

   

2. 滑動視窗計數器

   

3. 漏桶

   

4. 令牌桶

   

6.CAP理論和base定理

一個分布式系統在（C）（強）一緻性、（A）可用性、（p）分區容錯性,這三個隻能同時滿足兩個。

BASE理論是Basically Available(基本可用)，Soft State（軟狀态）和Eventually Consistent（最終一緻性）三個短語的縮寫。

既是無法做到強一緻性（Strong consistency），但每個應用都可以根據自身的業務特點，采用适當的方式來使系統達到最終一緻性（Eventual consistency）。

7.了解RPC嗎？有哪些常見的 RPC 架構？如果讓你自己設計 RPC 架構你會如何設計？

常見RPC架構：Dubbo,gRPC,thrift,Hessian.

一個典型的使用 RPC 的場景如下，一般情況下 RPC 架構不僅要提供服務發現功能，還要提供負載均衡、容錯等功能，這個的 RPC 架構才算真正合格。

1. 注冊中心首先是要有的，推薦使用 Zookeeper。注冊中心主要用來儲存相關的資訊比如遠端方法的位址。
2. 既然要要互相調用方法就要發請求，推薦nio 的 netty架構。
3. 發請求發送什麼資料呢？我們就要考慮序列化協定了。
4. 另外，動态代理也是需要的。因為 RPC 的主要目的就是讓我們調用遠端方法像調用本地方法一樣簡單，使用動态代理屏蔽遠端接口調用的細節比如網絡傳輸。
5. 負載均衡也是需要的。為啥？舉個例子我們的系統中的某個服務的通路量特别大，我們将這個服務部署在了多台伺服器上，當用戶端發起請求的時候，多台伺服器都可以處理這個請求。那麼，如何正确選擇處理該請求的伺服器就很關鍵。假如，你就要一台伺服器來處理該服務的請求，那該服務部署在多台伺服器的意義就不複存在了。負載均衡就是為了避免單個伺服器響應同一請求，容易造成伺服器當機、崩潰等問題，我們從負載均衡的這四個字就能明顯感受到它的意義。。

8.為什麼要網關？你知道有哪些常見的網關系統？

微服務下一個系統被拆分為多個服務，但是像 安全認證，流量控制，日志，監控等功能是每個服務都需要的，沒有網關的話，我們就需要在每個服務中單獨實作，這使得我們做了很多重複的事情并且沒有一個全局的視圖來統一管理這些功能。

綜上：一般情況下，網關一般都會提供請求轉發、安全認證（身份/權限認證）、流量控制、負載均衡、容災、日志、監控這些功能。

上面介紹了這麼多功能實際上網關主要做了一件事情：請求過濾 。權限校驗、流量控制這些都可以通過過濾器實作，請求轉也是通過過濾器實作的。

常見的網關系統：1. Kong 2. Netflix zuul 3.gateway

9.為什麼要分布式 id ？分布式 id 生成政策有哪些？

ID是資料的唯一辨別，傳統的做法是利用UUID和資料庫的自增ID，在網際網路企業中，大部分公司使用的都是Mysql，并且因為需要事務支援，是以通常會使用Innodb存儲引擎，UUID太長以及無序，是以并不适合在Innodb中來作為主鍵，自增ID比較合适，但是随着公司的業務發展，資料量将越來越大，需要對資料進行分表，而分表後，每個表中的資料都會按自己的節奏進行自增，很有可能出現ID沖突。這時就需要一個單獨的機制來負責生成唯一ID，生成出來的ID也可以叫做分布式ID，或全局ID。

10.服務熔斷和服務降級的差別

相似性：

1. 目的很一緻，都是從可用性可靠性着想，為防止系統的整體緩慢甚至崩潰，采用的技術手段；
2. 最終表現類似，對于兩者來說，最終讓使用者體驗到的是某些功能暫時不可達或不可用；
3. 粒度一般都是服務級别，當然，業界也有不少更細粒度的做法，比如做到資料持久層（允許查詢，不允許增删改）；
4. 自治性要求很高，熔斷模式一般都是服務基于政策的自動觸發，降級雖說可人工幹預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；

不同點：

1. 觸發原因不太一樣，服務熔斷一般是某個服務（下遊服務）故障引起，而服務降級一般是從整體負荷考慮；
2. 管理目标的層次不太一樣，熔斷其實是一個架構級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）

11.分布式系統需要考慮哪些問題

12.你的系統你會從哪些方面考慮去優化

1. 擴容。增加Nginx,Tomcat等應用伺服器的個數，或者實體伺服器個數，加大伺服器帶寬
2. 調優。Mysql調優，增加Redis，消息隊列等緩存技術，代碼調優，比如重構，工廠等。

我就知道這些，歡迎補充。

13.你的服務挂了怎麼處理

14.服務注冊中心的工作流程

作業系統

1.線程和程序的差別 (協程)

2.程序的排程算法

1. 先來先去服務
2. 時間片輪轉法
3. 多級回報隊列算法
4. 最短程序優先
5. 最短剩餘時間優先
6. 最高響應比優先
7. 多級回報隊列排程算法

3.虛拟記憶體解決了什麼問題？（分頁，分段，段頁的差別）

4.作業系統的作用和功能

5.死鎖的定義以及如何避免死鎖(銀行家算法)

死鎖産生的4個必要條件：

互斥條件：一個資源每次隻能被一個程序使用，即在一段時間内某 資源僅為一個程序所占有。此時若有其他程序請求該資源，則請求程序隻能等待。

請求與保持條件：程序已經保持了至少一個資源，但又提出了新的資源請求，而該資源 已被其他程序占有，此時請求程序被阻塞，但對自己已獲得的資源保持不放。

不可剝奪條件:程序所獲得的資源在未使用完畢之前，不能被其他程序強行奪走，即隻能 由獲得該資源的程序自己來釋放（隻能是主動釋放)。

循環等待條件: 若幹程序間形成首尾相接循環等待資源的關系。

6.程序的通信方式（實作原理，具體應用場景）

1. 檔案和記錄鎖定。
2. 管道。
3. FIFO。
4. 消息隊列。
5. 信号燈。
6. 共享記憶體。

7.線程的七态模型

8. 程序間同步與互斥的差別，線程同步的方式

9.動态連結庫與靜态連結庫的差別

10.linux的各種IO模型？（重點掌握epoll，底層結構紅黑樹 + 連結清單，能夠說出為什麼在管理數百萬連接配接的過程效率還好，以及ET模式和LT模式）

11.核心态和使用者态的差別以及轉換？（什麼情況會轉化：中斷，各種中斷進行分類）

12.linux底層的零拷貝技術（經曆4次 ->3次 ->2次拷貝的優化曆程）

13.作業系統大核心和微核心之間的差別以及各自的好處？

14.僵屍程序和孤兒程序産生的原因以及解決方式？

15.作業系統的各自排程方式