Java分佈式系統的基本特性,看完你還對分佈式不瞭解嗎?

一般,分佈式系統需要支持以下特性:

  • 資源共享

  • 開放性

  • 併發性

  • 可伸縮性

  • 容錯性

  • 透明性

下面分別討論。

容易理解的

資源共享

資源:包括硬件(e.g. printer, scanner, camera)、軟件(服務)、數據(file, database, web page)。

如資源管理器控制資源的訪問:

  • 提供命名機制

  • 控制併發訪問

開放性

新共享資源添加並被各種客戶程序使用的(難易)程度。

如支持異構資源的添加和使用:

  • 提供統一的通信機制

  • 發佈訪問共享資源的接口

併發性

分佈系統中的各個組成部分可以在併發的過程中被執行。

如:

  • 多個用戶同時訪問(和更新)資源

  • 多個服務進程同時運行,相互協作

資源定義同上。

可伸縮性

主要強調“伸”;偶爾也強調“縮”。

在資源和用戶數較大增長的情況下,系統性能仍能維持甚至提高。

通常表現為:

  • 利用網絡環境可以為更多的用戶服務、而且響應更快

  • 通常通過增加更多/更快的處理器,能實現更可靠、更完善的服務

如:

  • DNS的解析:一方面,不僅可以為每個根域名設置單獨的服務器,還可以為訪問量大的二級、更多級域名也單獨設置服務器;另一方面,當訪問量變小時,還可以將多個訪問量小的根域名的解析合併到一臺服務器上。

Java分佈式系統的基本特性,看完你還對分佈式不瞭解嗎?

不容易理解的

容錯性

錯誤發生時,系統能夠繼續工作的能力。

基於這樣一個假設:硬件、軟件、網絡的錯誤不可避免。

要容錯,就要先知道有哪些錯誤(故障),再針對故障類型一一解決。

故障類型

分佈式系統中的典型故障如下:

Java分佈式系統的基本特性,看完你還對分佈式不瞭解嗎?

其中,隨意性故障是最嚴重的故障,也被稱為<code>拜占庭故障/<code>。當發生故障時,服務器可能產生它從來沒有產生過的輸出,但是又不能檢測出錯誤。更壞的情況是,發生故障的服務器惡意的與其他服務器共同工作來產生惡意的錯誤結果。

容錯方案

如果系統是容錯的,那麼它能做的最好的事情就是對其他進程隱藏故障的發生。由於故障無法避免,我們只能依靠冗餘來掩蓋故障,包括:

  • 信息冗餘:添加額外的位可以監測出錯誤位甚至糾正。如在數據中增加checksum等。

  • 時間冗餘:執行一個動作,如果需要就再次執行。如事務、超時重傳等。

  • 物理冗餘:添加額外的設備或進程使系統作為一個整體來容忍部分組件的故障。如HDFS的多備份、HA等等。

部分書籍將物理冗餘與軟件冗餘分開,本質上無法完全分開,因為軟件冗餘可能在部署在單機或多機上。這裡將二者統一為物理冗餘。

則針對各故障,可取的主要解決方案為:

  • 崩潰性故障——時間冗餘、物理冗餘

  • 遺漏性故障——物理冗餘

  • 定時故障——時間冗餘、物理冗餘

  • 響應故障——信息冗餘、時間冗餘、物理冗餘

  • 隨意性故障——信息冗餘、時間冗餘、物理冗餘

Java分佈式系統的基本特性,看完你還對分佈式不瞭解嗎?

透明性

網絡環境對於用戶和應用程序而言,應該是一個整體,而不是一個互相協作的簡單的構件集合。包括多項性質:

  • 位置透明性:用戶不必關心對象位於何處。

  • 如DNS、Consul等分佈式命名系統。

  • 重定位透明性:對象的位置可以變化而不影響對它的調用。

  • 仍然如DNS、Consul等。

  • 遷移透明性:系統內部可以遷移對象的位置。

  • 仍然如DNS、Consul等。

  • 訪問透明性:可用一致的方式訪問不同類型的機器上的對象。

  • 如Yarn、Mesos等分佈式資源調度系統。

  • 持久透明性:對象所處的狀態既可以是活動的,也可以是靜止的。

  • 如HBase的WAL,計算機中的cache、段表、頁表等。

  • 失敗透明性:屏蔽被訪問對象的失敗及恢復過程 (容錯)。

  • 如MapReduce、Spark等分佈式計算框架。

  • 事務處理透明性:與事務處理相關的調度、監控和恢復。

  • 如2PC等分佈式事務協議。

  • 複製透明性:用戶不知道有多少個對象副本存在。

  • 如HDFS、Tair等分佈式存儲系統。

位置透明性、遷移透明性、重定位透明性是對命名系統的基本要求。

如果想學習Java工程化、高性能及分佈式、深入淺出。性能調優、Spring,MyBatis,Netty源碼分析的朋友可以加我的Java進階群,675047716,群裡有BAT大神跟大家交流分享行業資訊,以及Java大型互聯網技術的視頻免費分享給大家。


分享到:


相關文章: