Java面試題之分布式的示例分析

這篇文章主要為大家展示了“Java面試題之分布式的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Java面試題之分布式的示例分析”這篇文章吧。

面試題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)操作。

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

以上是“Java面試題之分布式的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！