在系統(tǒng)設(shè)計中，每個決策都會帶來取舍。讓我們深入探討 10 個常見的系統(tǒng)設(shè)計權(quán)衡，并討論它們的影響。

圖片

01 垂直擴展 vs 水平擴展

垂直擴展指的是向現(xiàn)有服務(wù)器添加更多資源（CPU、RAM 等）以提高其容量。由于只需改進一臺機器，通常更容易實施，但有物理和實際的限制。垂直擴展可能變得昂貴，升級時通常需要停機。

水平擴展則是向服務(wù)器池中添加更多服務(wù)器，將負載分布在多臺機器上。它提供了更好的容錯性，并在理論上具有無限的可擴展性。然而，它增加了管理分布式系統(tǒng)、負載均衡和節(jié)點間數(shù)據(jù)一致性的復(fù)雜性。

取舍: 垂直擴展更簡單，但有局限性；水平擴展提供了更高的可擴展性，但復(fù)雜性更高。

02 SQL vs NoSQL

SQL 數(shù)據(jù)庫將數(shù)據(jù)組織成表格的形式，具有行和列，并支持強大的查詢語言（如 SQL）。在需要 ACID（原子性、一致性、隔離性、持久性）屬性和數(shù)據(jù)關(guān)系的場景中表現(xiàn)出色。

NoSQL 數(shù)據(jù)庫提供靈活的架構(gòu)設(shè)計，適用于非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)。在大規(guī)模、分布式環(huán)境中通常表現(xiàn)更好，但可能會犧牲一些事務(wù)保證。

取舍: SQL 提供一致性和強關(guān)系支持，而 NoSQL 提供靈活性和可擴展性，通常以處理關(guān)系和事務(wù)的復(fù)雜性為代價。

03 批處理 vs 流處理

批處理指的是收集數(shù)據(jù)后一次性處理。它適用于如每日賬單處理等場景，在這些場景中不需要實時結(jié)果。然而，它會引入延遲，因為數(shù)據(jù)不會立即處理。

流處理則是實時處理數(shù)據(jù)，適用于需要即時響應(yīng)的應(yīng)用，如欺詐檢測或?qū)崟r監(jiān)控。

取舍: 批處理對大量數(shù)據(jù)更有效，但會帶來延遲；流處理提供實時洞察，但資源消耗更高。

04 Normalization vs Denormalization

Normalization（正則化）將數(shù)據(jù)組織到不同的表中，以減少冗余并保持數(shù)據(jù)完整性。這對減少關(guān)系數(shù)據(jù)庫中的異常至關(guān)重要，但在進行復(fù)雜聯(lián)接時可能會導(dǎo)致性能開銷。

Denormalization（反正則化）則是將數(shù)據(jù)組合成更少的表，以優(yōu)化查詢性能，往往會增加數(shù)據(jù)冗余并帶來潛在的更新異常。

取舍: 正則化優(yōu)化數(shù)據(jù)完整性和存儲，但可能減慢讀取性能；反正則化提高讀取性能，但可能導(dǎo)致數(shù)據(jù)重復(fù)和不一致。

05 一致性 vs 可用性 (CAP定理)

一致性確保所有用戶每次都能看到最新的數(shù)據(jù)。然而，在分布式系統(tǒng)中實現(xiàn)強一致性可能會在網(wǎng)絡(luò)故障時限制可用性。

可用性確保系統(tǒng)在某些部分出現(xiàn)問題時仍然可以運行。然而，這通常意味著用戶可能無法獲取最新的數(shù)據(jù)。

取舍: 確保節(jié)點間高度一致性可能會降低可用性，而最大化可用性可能導(dǎo)致服務(wù)的過時或不一致數(shù)據(jù)。

06 強一致性 vs 最終一致性

強一致性保證一旦寫操作完成，所有后續(xù)的讀取都能反映最新的寫入。這對于金融應(yīng)用或庫存系統(tǒng)等需要絕對正確性的場景至關(guān)重要。

最終一致性允許更新在節(jié)點間逐步傳播，這意味著在所有節(jié)點達成一致前，讀取可能會返回過時數(shù)據(jù)。這在性能和可用性比準(zhǔn)確性更關(guān)鍵的大型分布式系統(tǒng)中是可以接受的。

取舍: 強一致性保證即時準(zhǔn)確性，但通常伴隨著更高的延遲和復(fù)雜性；最終一致性提高了性能和可用性，但代價是臨時的數(shù)據(jù)不一致。

07 REST vs GraphQL

REST API 通常有多個端點用于不同的數(shù)據(jù)類型和操作。它易于實現(xiàn)且被廣泛支持，但當(dāng)客戶端需要從多個端點獲取數(shù)據(jù)時，效率較低。

GraphQL 允許客戶端通過一次查詢精確獲取所需數(shù)據(jù)，提高了效率并減少了數(shù)據(jù)過量獲取。然而，設(shè)計和維護它需要更多的工作，因為模式和解析函數(shù)可能會變得復(fù)雜。

取舍: REST 更簡單、更容易實現(xiàn)，但在數(shù)據(jù)獲取方面效率較低。GraphQL 提供了更精確的數(shù)據(jù)檢索，但實現(xiàn)和維護的復(fù)雜性更高。

08 有狀態(tài) vs 無狀態(tài)系統(tǒng)

有狀態(tài)系統(tǒng)會保留過去的交互信息，使得交互更具個性化和上下文感知。例如，有狀態(tài)的Web服務(wù)器可以記住用戶會話。然而，管理狀態(tài)會增加復(fù)雜性并限制可擴展性。

無狀態(tài)系統(tǒng)將每次交互獨立對待，不保留任何過去的交互記錄。這簡化了擴展和容錯處理，因為任何服務(wù)器都可以處理任何請求。

取舍: 有狀態(tài)系統(tǒng)提供更豐富的功能，但增加了復(fù)雜性并降低了可擴展性；無狀態(tài)系統(tǒng)簡化了擴展和容錯處理，但失去了交互的上下文。

09 讀穿緩存 vs 寫穿緩存

讀穿緩存在緩存未命中的情況下從數(shù)據(jù)庫加載數(shù)據(jù)。這對讀取頻繁而更新較少的數(shù)據(jù)很有利。

寫穿緩存在寫入數(shù)據(jù)時同時更新緩存和底層存儲。它確保緩存和存儲之間的數(shù)據(jù)一致性，但可能會在寫入時引入延遲。

取舍: 讀穿緩存的讀取速度較快，但可能提供過時數(shù)據(jù)，而寫穿緩存確保數(shù)據(jù)一致性，但代價是寫入時的延遲增加。

10 同步 vs 異步處理

同步處理是一個接一個地執(zhí)行任務(wù)，這意味著每個任務(wù)必須等待上一個任務(wù)完成后才能開始。它實現(xiàn)簡單，并能確保順序上的正確性，但可能導(dǎo)致性能瓶頸。

異步處理允許任務(wù)獨立運行，新的任務(wù)可以在當(dāng)前任務(wù)未完成時啟動。這提高了系統(tǒng)效率和響應(yīng)能力，但增加了并行任務(wù)管理和故障處理的復(fù)雜性。

取舍: 同步處理更簡單并確保順序，但可能減慢系統(tǒng)。異步處理提高了響應(yīng)速度和吞吐量，但代價是更高的復(fù)雜性。