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

圖片

01 垂直擴(kuò)展 vs 水平擴(kuò)展

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

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

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

02 SQL vs NoSQL

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

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

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

03 批處理 vs 流處理

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

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

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

04 Normalization vs Denormalization

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

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

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

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

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

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

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

06 強(qiáng)一致性 vs 最終一致性

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

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

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

07 REST vs GraphQL

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

GraphQL 允許客戶端通過(guò)一次查詢精確獲取所需數(shù)據(jù)，提高了效率并減少了數(shù)據(jù)過(guò)量獲取。然而，設(shè)計(jì)和維護(hù)它需要更多的工作，因?yàn)槟Ｊ胶徒馕龊瘮?shù)可能會(huì)變得復(fù)雜。

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

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

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

無(wú)狀態(tài)系統(tǒng)將每次交互獨(dú)立對(duì)待，不保留任何過(guò)去的交互記錄。這簡(jiǎn)化了擴(kuò)展和容錯(cuò)處理，因?yàn)槿魏畏?wù)器都可以處理任何請(qǐng)求。

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

09 讀穿緩存 vs 寫(xiě)穿緩存

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

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

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

10 同步 vs 異步處理

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

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

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