分布式技術發展歷程來看，分布式其實就是用廉價普通的機器解決單個計算機處理復雜、大規模數據和任務時存在的性能和資源瓶頸問題。

如何來衡量一個分布式系統的優劣程度呢？

一般分布式系統的表現好壞表現在以前幾個方面：

• 性能
• 資源
• 可用性
• 可擴展性

性能

其實對于什么是性能，最常聽說的就是請求的響應速度。其實這只是一方面，不同的系統，對于系統的要求不一樣，有的關注吞吐量，有的關注相應時間，有的關注完成時間，沒錯這三個指標就是最常見的性能指標。

吞吐量

吞吐量指的是系統在一定時間內可以處理的任務數。

這個指標很直觀的反應處一個系統的性能，就好像在顧客非常多的情況下，看一個收銀員可以一個小時能服務多少個顧客。

在互聯網中吞吐量常常表現為三個具體的指標：

1. QPS
2. TPS
3. BPS

QPS，即查詢數每秒，用于衡量一個系統每秒處理的查詢數。這個指標通常用于讀操作，越高說明對讀操作的支持越好。所以，我們在設計一個分布式系統的時候，如果應用主要是讀操作，那么需要重點考慮如何提高QPS，來支持高頻的讀操作。

TPS，即事務數每秒，用于衡量一個系統每秒處理的事務數。這個指標通常對應于寫操作，越高說明對寫操作的支持越好。我們在設計一個分布式系統的時候，如果應用主要是寫操作，那么需要重點考慮如何提高TPS，來支持高頻寫操作。

BPS，即比特數每秒，用于衡量一個系統每秒處理的數據量。對于一些網絡系統、數據管理系統，我們不能簡單地按照請求數或事務數來衡量其性能。因為請求與請求、事務與事務之間也存在著很大的差異，比方說，有的事務大需要寫入更多的數據。那么在這種情況下，BPS更能客觀地反應系統的吞吐量。

響應時間

響應時間指的是，系統響應一個請求需要花費的時間。響應時間直接影響到用戶體驗，對于時延敏感的業務非常重要。比如用戶搜索導航，特別是用戶邊開車邊搜索的時候，如果響應時間很長，就會直接導致用戶走錯路。

完成時間

指的是，系統真正完成一個請求或處理需要花費的時間。任務并行（也叫作任務分布式）模式出現的其中一個目的，就是縮短整個任務的完成時間。特別是需要計算海量數據或處理大規模任務時，用戶對完成時間的感受非常明顯。

資源占用

資源占用指的是，一個系統提供正常能力需要占用的硬件資源，比如CPU、內存、硬盤等。

一個系統在沒有任何負載時的資源占用，叫做空載資源占用，體現了這個系統自身的資源占用情況。比如，你在手機上安裝一個App，安裝的時候通常會提示你有多少KB，這就是該App的空載硬盤資源占用。對于同樣的功能，空載資源占用越少，說明系統設計越優秀，越容易被用戶接受。

一個系統滿額負載時的資源占用，叫做滿載資源占用，體現了這個系統全力運行時占用資源的情況，也體現了系統的處理能力。同樣的硬件配置上，運行的業務越多，資源占用越少，說明這個系統設計得越好。

可用性

可用性，通常指的是系統在面對各種異常時可以正確提供服務的能力。可用性是分布式系統的一項重要指標，衡量了系統的魯棒性，是系統容錯能力的體現。系統的可用性可以用系統停止服務的時間與總的時間之比衡量。

假設一個網站總的運行時間是24小時，在24小時內，如果網站故障導致不可用的時間是4個小時，那么系統的可用性就是4/24=0.167，也就是0.167的比例不可用，或者說0.833的比例可用。

除此之外，系統的可用性還可以用某功能的失敗次數與總的請求次數之比來衡量，比如對網站請求1000次，其中有10次請求失敗，那么可用性就是99%。

你可能經常在一個系統的宣傳語中見到或聽到3個9（或3N，3 Nines）、5個9（或9N，9 Nines）。這些宣傳語中所說的3個9、5個9，實際上就是系統廠商對可用性的一種標榜，表明該系統可以在99.9%或99.999%的時間里能對外無故障地提供服務。

講到了可用性，你可能還會想到一個非常近似的術語：可靠性（Reliability）。那可靠性和可用性有什么區別呢？ 可靠性通常用來表示一個系統完全不出故障的概率，更多地用在硬件領域。而可用性則更多的是指在允許部分組件失效的情況下，一個系統對外仍能正常提供服務的概率。 杰夫 · 迪恩（Jeff Dean）曾在Google I/O大會上透露：谷歌一個基于1000臺通用計算機的集群，一年之內就有1000+硬盤會出現故障。由于現在比較常見的分布式系統基本上都是基于通用計算機的，這就意味著在這些系統中無法實現真正的可靠，所以我們也會在一些場合見到可靠性和可用性交換使用的情況。

可擴展性

可擴展性，指的是分布式系統通過擴展集群機器規模提高系統性能(吞吐、響應時間、 完成時間)、存儲容量、計算能力的特性，是分布式系統的特有性質。

分布式系統的設計初衷，就是利用集群多機的能力處理單機無法解決的問題。然而，完成某一具體任務所需要的機器數目，即集群規模，取決于單個機器的性能和任務的要求。

當任務的需求隨著具體業務不斷提高時，除了升級系統的性能做垂直/縱向擴展外，另一個做法就是通過增加機器的方式去水平/橫向擴展系統規模。

這里垂直/縱向擴展指的是，增加單機的硬件能力，比如CPU增強、內存增大等；水平/橫向擴展指的就是，增加計算機數量。好的分布式系統總在追求“線性擴展性”，也就是說系統的某一指標可以隨著集群中的機器數量呈線性增長。

衡量系統可擴展性的常見指標是加速比（Speedup），也就是一個系統進行擴展后相對擴展前的性能提升。

一個分布式系統是否可以保證每個指標都達到理性水平？

答案是否定的，無論是高可用，高性能，還是高擴展性，都會受到資源占用的限制，說白了就是受到成本的限制。

然而，雖然出于硬件成本、開發效率等因素的約束，我們無法在性能、可用性、可靠性和資源占用做到面面俱到。所以在不同的業務場景中，設計者們需要有所取舍。

接下來，我帶你一起看一下典型的電商、IoT、電信、HPC（高性能計算）、大數據、云計算、區塊鏈等業務或系統對不同指標的訴求。

• 電商系統。對于一個電商系統而言，系統設計者最看重的是吞吐量，為了處理更多的用戶訪問或訂單業務，甚至不惜犧牲一些硬件成本。
• IoT。對于一個IoT系統而言，設計者最看重的是資源占用指標，因為在一些功能極簡的IoT設備上RAM、ROM的可用資源通常都是KB級的。
• 電信業務。對于電信業務而言，最重要的無疑是響應時間、完成時間，以及可用性。因為，你在打電話時不希望你的聲音半天才被對方聽到，也不希望半天才聽到對方的回應，更不希望你的電話無法撥出。
• HPC。HPC系統最顯著的特點是任務執行時間極長，一個天體物理任務的分析和計算通常耗時數周甚至數月。因此，通過水平擴展來提高系統的加速比，是HPC系統設計者需要關注的。
• 大數據。大數據任務的處理時間可能相對HPC系統來講比較短，但常見的完成時間也達到了小時級，所以擴展性也是大數據系統首先要考慮的。
• 云計算。對于一個云計算系統而言，常見任務是虛擬主機或容器的創建、資源調整、銷毀等操作，如何減少這些操作的完成時間，從而提升用戶體驗是設計者們要重點關注的。另外，云計算系統本質上賣的是資源，那么降低系統本身的資源開銷，也是系統設計的重中之重。
• 區塊鏈。區塊鏈的吞吐量比較低，比特幣的TPS只有7次每秒，單平均一次交易的確認就需要10分鐘左右，因此吞吐量和完成時間通常是區塊鏈系統設計者的首要目標。