Java面試題沖刺第二十三天–分佈式

Posted on by

面試題1：說說什麼分佈式事務？解釋一下什麼是CAP？

現在互聯網開發多使用微服務架構，一個簡單的操作，在服務端可能就是由多個服務和數據庫實例協同完成的。但在一致性要求較高且高QPS的場景下，多個獨立操作之間的一致性問題和服務高可用問題就顯得格外棘手。

基於對水平擴容能力和成本考慮，針對除非敏感業務（如支付、轉賬等）外的大量其他業務，傳統的強一致的解決方案逐漸被淘汰。

其理論依據就是CAP原理。在分佈式系統中，同時滿足CAP定律中的一致性 Consistency、可用性 Availability和分區容錯性 Partition Tolerance三者是不可能的。在絕大多數的場景，為瞭可用性和分區容錯性，都需要犧牲強一致性來換取系統的高可用性，系統往往隻需要保證最終一致性。

在這裡插入圖片描述

CAP理解：

Consistency：一致性就是在客戶端任何時候看到各節點的數據都是一致的。

Availability：可用性就是在任何時刻都可以提供讀寫。

Partition Tolerance：分區容錯性是在網絡故障、某些節點不能通信的時候系統仍能繼續工作。

具體地講在分佈式系統中，在任何數據庫設計中，一個Web應用最多隻能同時支持上面的兩個屬性。顯然，任何橫向擴展策略都要依賴於數據分區。因此，設計人員必須在一致性與可用性之間做出選擇。

AP（高可用&&分區容錯）:

允許至少一個節點更新狀態會導致數據不一致，即喪失瞭C性質（一致性）。會導致全局的數據不一致。

CP（一致&&分區容錯）:

為瞭保證數據一致性，將分區一側的節點設置為不可用，那麼又喪失瞭A性質（可用性）。分區同步會導致同步時間無限延長（也就是等數據同步完成之後才能正常訪問）

CA（一致&&高可用）:

兩個節點可以互相通信，才能既保證C（一致性）又保證A（可用性），這又會導致喪失P性質（分區容錯性）。這樣的話就分佈式節點受阻，無法部署子節點,放棄瞭分佈式系統的可擴展性。因為分佈式系統與單機系統不同，它涉及到多節點間的通訊和交互，節點間的分區故障是必然發生的，所以在分佈式系統中分區容錯性是必須要考慮的。

分佈式事務服務

分佈式事務服務（Distributed Transaction Service，DTS）是一個分佈式事務框架，用來保障在大規模分佈式環境下事務的最終一致性。

CAP理論告訴我們在分佈式存儲系統中，最多隻能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的，所以我們隻能在一致性和可用性之間進行權衡。

為瞭保障系統的可用性，互聯網系統大多將強一致性需求轉換成最終一致性的需求，並通過系統執行冪等性的保證，保證數據的最終一致性。

追問1：怎麼理解強一致性、弱一致性和最終一致性？

強一致性：當更新操作完成之後，任何多個後續進程或者線程的訪問都會返回最新的更新過的值。這種是對用戶最友好的，就是用戶上一次寫什麼，下一次就保證能讀到什麼。根據 CAP 理論，這種實現需要犧牲可用性。

弱一致性：系統並不保證後續進程或者線程的訪問都會返回最新的更新過的值。系統在數據寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之後可以讀到。

最終一致性：弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。在沒有故障發生的前提下，不一致窗口的時間主要受通信延遲，系統負載和復制副本的個數影響。DNS 是一個典型的最終一致性系統。

  最終一致性是指系統中所有的副本經過一段時間的異步同步之後，最終能夠達到一個一致性的狀態，也就是說在數據的一致性上存在一個短暫的延遲。

  幾乎所有的互聯網系統采用的都是終一致性，隻有在實在無法使用終一致性，才使用強一致性或事務，比如，對於決定系統運行的敏感數據，需要考慮采用強一致性，對於與錢有關的支付系統或金融系統的數據，需要考慮采用事務。

  也就是說能夠使用最終一致性的業務就盡量使用最終一致性，因為強一致性會降低系統的可用性。

面試題2：瞭解BASE理論麼？

在分佈式系統中，我們往往追求的是可用性，它的重要程序比一致性要高，那麼如何實現高可用性呢？前人已經給我們提出來瞭另外一個理論，就是BASE理論，它是用來對CAP定理進行進一步擴充的。BASE理論指的是：

  • Basically Available（基本可用）
  • Soft state（軟狀態）
  • Eventually consistent（最終一致性）

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，是對互聯網大規模分佈式系統的實踐總結，強調可用性。

理論的核心思想就是：基本可用（Basically Available）和最終一致性（Eventually consistent）。雖然無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。

追問1：基於BASE理論，舉幾個實際的例子

我們以12306訂票系統為例

1.流量削峰

  可以在不同的時間，出售不同區域的票，將訪問請求錯開，削弱請求峰值。比如，在春運期間，深圳出發的火車票在 8 點開售，北京出發的火車票在 9 點開售。

2.延遲響應

  在春運期間，自己提交的購票請求，往往會在隊列中排隊等待處理，可能幾分鐘或十幾分鐘後，系統才開始處理，然後響應處理結果。

3.體驗降級

  比如用小圖片來替代原始圖片，通過降低圖片的清晰度和 大小，提升系統的處理能力。

4.過載保護

  比如把接收到的請求放在指定的隊列中排隊處理，如果請求等 待時間超時瞭（假設是 100ms），這個時候直接拒絕超時請求；再比如隊列滿瞭之後，就 清除隊列中一定數量的排隊請求，保護系統不過載，實現系統的基本可用。

 面試題3：實現分佈式事務一致性（Consistency）的方法有哪些?

為瞭解決分佈式系統的一致性問題，在長期的探索研究過程中，湧現出瞭一大批經典的一致性協議和算法，其中最著名的就是二階段提交協議、三階段提交協議和Paxos算法。

追問1：說一下二階段提交（2PC）的原理吧

二階段提交（two-phase commit）增加瞭事務處理器和事務執行者的角色。由事務處理器來進行整個事務的處理。主要流程如下面的圖

在這裡插入圖片描述

兩階段提交協議

prepare(準備階段)

當開始事務調用的時候，事務處理器向事務執行者（有可能是數據庫本身支持）發出命令，事務執行者進行prepare操作。

當所有事務執行者都完成瞭prepare操作，就進行下一步行為。

如果有一個事務執行者在執行prepare的時候失敗瞭，那麼通知事務處理器，事務處理器再通知所有的事務執行者執行回滾操作。

commit(提交階段)

當所有事務執行者都prepare成功以後，事務處理器會再次發送commit請求給事務執行者，所有事務執行者進行commit處理。

當所有commit處理都成功瞭，那麼事務執行結束。

如果有一個事務執行者的commit處理不成功，這個時候就要通知事務處理器，事務處理器通知所有的事務執行者執行回滾(abort)操作。

但是兩階段提交的詬病就是在於性能問題。比如由於執行鏈比較長，鎖定資源的時間也變長瞭。所以在高性能的系統中都會避免使用二階段提交。

總結

本篇文章就到這裡瞭，希望能給你帶來幫助，也希望您能夠多多關註WalkonNet的更多內容!

推薦閱讀：