系統設計中也面臨許多權衡取舍：

• 性能與可擴展性
• 延遲與吞吐量
• 可用性與一致性

性能與可擴展性

可擴展，意味著服務能以加資源的方式成比例地提升性能，性能提升體現在能夠承擔更多的工作量，但加資源也會引入多樣性：一些節點可能比其它節點的處理能力更強大，另一些老舊節點可能弱一些，而系統又必須適應這種異質性（heterogeneity），那么依賴均勻性的算法就會對新節點利用不足，繼而產生性能影響

延遲與吞吐量

延遲（Latency）是指從執行操作到產生結果所需要的時間，其度量單位是時間。
吞吐量（Throughput）是指單位時間內所能處理的操作數，或能產生的結果數。
通過單位時間所生產的東西來計量，例如內存帶寬（memory bandwidth）用來衡量內存系統的吞吐量，而對于Web系統，有這些度量單位：

QPS（Queries Per Second）：用來衡量信息檢索系統（如搜索引擎、數據庫等）在1秒內的搜索流量RPS（Requests Per Second）：請求-響應系統（如Web服務器）每秒所能處理的最大請求數量TPS（Transactions Per Second）：廣義上指在1秒內所能執行的原子操作數量，狹義上指DBMS在1秒所能執行的transaction數量

通常也用QPS衡量Web服務的吞吐量，但更準確的單位是RPS。
由于無法兼具低延遲和高吞吐量，所以權衡之下的原則是：在確保延遲尚可接受的前提下，轉而追求最大的吞吐量

可用性與一致性

關于可用性與一致性，有個著名的CAP定理，可以查看往期筆記：CAP理論
在分布式計算機系統中，一致性、可用性和分區容錯性三者只能擇其二（而且分區容錯性必選）：

• 一致性（Consistency）：每次讀取都能得到最新寫入的結果，抑或出錯
• 可用性（Availability）：每個請求都能收到正常響應，但不保證返回的是最新信息
• 分區容錯性（Partition Tolerance）：即便有一部分由于網絡故障down掉了，系統仍能繼續運行

因為網絡不完全可靠，所以必須保證分區容錯性（P必選）。當部分節點出現網絡故障時，有2個選擇：

• 取消操作：能確保一致性，但會降低可用性（用戶可能收到超時錯誤），即CP（Consistency and Partition Tolerance），適用于需要原子讀寫的場景
• 繼續操作：保證可用性，但存在一致性風險（返回的信息可能是舊的），即AP（Availability and Partition Tolerance），適用于可接受最終一致性（Eventual consistency）的場景

在P必須滿足的前提下（網絡故障是系統之外的不可控因素，沒得選），只能在C和A之間進行取舍，要么保證一致性（犧牲可用性），要么保證可用性（犧牲一致性）。在中心化系統（例如RDBMS）中，不存在網絡可靠性的問題，此時C和A能夠兩全

一致性模式

同一數據存在多份拷貝，那么就需要考慮如何保證其一致性。而嚴格的一致性意味著要么讀到最新數據，要么出錯。但并非所有場景下都需要達到這樣的一致性要求，所以出現了弱一致性與最終一致性等妥協產物。
弱一致性：
寫完之后，不一定能讀到。弱一致性模式（Weak consistency）適用于網絡電話、視頻聊天、實時多人游戲等實時場景，而網絡電話斷線重連后，不會再收到斷線期間的通話內容
最終一致性：
寫完之后，異步復制數據，保證最終能讀到。最終一致性模式（Eventual consistency）適用于DNS、email等高可用系統
強一致性：
寫完之后，同步復制數據，立即就能讀到
強一致性模式（Strong consistency）適用于文件系統、RDBMS等需要事務機制的場景

可用性模式

可用性保障方面，主要有兩種方式：故障轉移與復制
故障轉移：
一個節點down掉之后，迅速用另一個點代替它，以縮減宕機時間。具體的，有兩種故障轉移模式：

• 主動-被動（主從故障轉移）：只由主動服務器處理流量，在工作的主動服務器與待命的被動服務器之間發送心跳包，如果心跳斷了，由被動服務器接管主動服務器的IP地址并恢復服務，宕機時間的長短取決于被動機器是熱啟動還是冷啟動

  1、冷啟動：當啟動應用時，后臺沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。2、熱啟動：當啟動應用時，后臺已有該應用的進程（例：按back鍵、home鍵，應用雖然會退出，但是該應用的進程是依然會保留在后臺，可進入任務列表查看），所以在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動。
  

• 主動-主動（主主故障轉移）：兩臺服務器都處理流量，共同承擔負載

主動-被動模式下，（切換時）存在數據丟失的風險，而且無論哪種方式，故障轉移都會增加硬件資源和復雜度
復制
分為主從復制與主主復制，多用于數據庫，可以參考往期文章：
https://hanhandi.blog.csdn.net/article/details/115447488
https://hanhandi.blog.csdn.net/article/details/115459092

可用性衡量

對于由多部分組成的服務，其整體可用性取決于這些組成部分是串行的還是并行的：
可用性都達不到100%的兩個服務組合起來，如果是串行的，其整體可用性會下降（99.9% * 99.9% = 99.8%），而并行的話，整體可用性會提高（1 - 0.1% * 0.1% = 99.9999%）
可用性通常用幾個9來衡量，表示服務可用時間占運行時間的百分比：

圖1 99.9%

圖2 99.99%

參考

http://www.ayqy.net/blog/trade-offs-in-system-design/