分佈式系統的基本特性

通常，分佈式系統須要支持如下特性：

• 資源共享
• 開放性
• 併發性
• 可伸縮性
• 容錯性
• 透明性

下面分別討論。

容易理解的

資源共享

一旦受權，能夠訪問環境中的任何資源。

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

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

• 提供命名機制
• 控制併發訪問

開放性

新共享資源添加並被各類客戶程序使用的（難易）程度。

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

• 提供統一的通訊機制
• 發佈訪問共享資源的接口

併發性

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

如：

• 多個用戶同時訪問（和更新）資源
• 多個服務進程同時運行，相互協做

資源定義同上。

可伸縮性

主要強調「伸」；偶爾也強調「縮」。

在資源和用戶數較大增加的狀況下，系統性能仍能維持甚至提升。

一般表現爲：

• 利用網絡環境能夠爲更多的用戶服務、並且響應更快
• 一般經過增長更多/更快的處理器，能實現更可靠、更完善的服務

如：

• DNS的解析：一方面，不只能夠爲每一個根域名設置單獨的服務器，還能夠爲訪問量大的二級、更多級域名也單獨設置服務器；另外一方面，當訪問量變小時，還能夠將多個訪問量小的根域名的解析合併到一臺服務器上。

不容易理解的

容錯性

錯誤發生時，系統可以繼續工做的能力。

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

要容錯，就要先知道有哪些錯誤（故障），再針對故障類型一一解決。

故障類型

分佈式系統中的典型故障以下：

故障類型	說明
崩潰性故障	服務器停機，可是在停機以前工做正常
遺漏性故障	服務期不能響應到來的消息。包括不能接受、不能發送
定時故障	服務器的響應在指定時間間隔以外
響應故障	服務期的響應不正確。包括響應的值錯誤、偏離了正確的控制流
隨意性故障	服務器可能在隨意的時間產生隨意的響應

其中，隨意性故障是最嚴重的故障，也被稱爲拜占庭故障。當發生故障時，服務器可能產生它歷來沒有產生過的輸出，可是又不能檢測出錯誤。更壞的狀況是，發生故障的服務器惡意的與其餘服務器共同工做來產生惡意的錯誤結果。

容錯方案

若是系統是容錯的，那麼它能作的最好的事情就是對其餘進程隱藏故障的發生。因爲故障沒法避免，咱們只能依靠冗餘來掩蓋故障，包括：

• 信息冗餘：添加額外的位能夠監測出錯誤位甚至糾正。如在數據中增長checksum等。
• 時間冗餘：執行一個動做，若是須要就再次執行。如事務、超時重傳等。
• 物理冗餘：添加額外的設備或進程使系統做爲一個總體來容忍部分組件的故障。如HDFS的多備份、HA等等。

部分書籍將物理冗餘與軟件冗餘分開，本質上沒法徹底分開，由於軟件冗餘可能在部署在單機或多機上。這裏將兩者統一爲物理冗餘。

則針對各故障，可取的主要解決方案爲：

• 崩潰性故障——時間冗餘、物理冗餘
• 遺漏性故障——物理冗餘
• 定時故障——時間冗餘、物理冗餘
• 響應故障——信息冗餘、時間冗餘、物理冗餘
• 隨意性故障——信息冗餘、時間冗餘、物理冗餘

透明性

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

• 位置透明性：用戶沒必要關心對象位於何處。
  • 如DNS、Consul等分佈式命名系統。
• 重定位透明性：對象的位置能夠變化而不影響對它的調用。
  • 仍然如DNS、Consul等。
• 遷移透明性：系統內部能夠遷移對象的位置。
  • 仍然如DNS、Consul等。
• 訪問透明性：可用一致的方式訪問不一樣類型的機器上的對象。
  • 如Yarn、Mesos等分佈式資源調度系統。
• 持久透明性：對象所處的狀態既能夠是活動的，也能夠是靜止的。
  • 如HBase的WAL，計算機中的cache、段表、頁表等。
• 失敗透明性：屏蔽被訪問對象的失敗及恢復過程 （容錯）。
  • 如MapReduce、Spark等分佈式計算框架。
• 事務處理透明性：與事務處理相關的調度、監控和恢復。
  • 如2PC等分佈式事務協議。
• 複製透明性：用戶不知道有多少個對象副本存在。
  • 如HDFS、Tair等分佈式存儲系統。

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

---

本文連接：分佈式系統的基本特性
做者：猴子007
出處：monkeysayhi.github.io
本文基於 知識共享署名-相同方式共享 4.0 國際許可協議發佈，歡迎轉載，演繹或用於商業目的，可是必須保留本文的署名及連接。