分散式系統設計:服務模式之分散與聚集

來自專欄 進擊的雲計算

到目前為止，我們已經研究了按照每秒處理的請求數（無狀態複製模式）以及數據大小（分片數據模式）的可伸縮性來複制可伸縮性的系統。在本文中，我們將介紹分散與聚集模式，該模式使用複製來實現時間可伸縮性。具體而言，分散/聚集模式允許你在服務請求中實現並行性，使你能夠以更快的速度服務它們，如果你必須按順序對它們進行服務。

就像複製和分片系統一樣，分散/聚集模式是一個樹形模式，它具有分布請求的根節點和處理這些請求的葉節點。但是，與複製和分片系統相比，分散/聚集請求同時被分散到系統中的所有副本。每個副本執行少量處理，然後將一部分結果返回到根。根伺服器然後將各種部分結果組合在一起以形成對請求的單個完整響應，然後將該請求發送回客戶端。分散/聚集模式如圖1所示。

當你需要處理特定請求所需的大量獨立的處理任務時，Scatter/Gather非常有用。分散/聚集可以被看作是分解服務請求所需的計算，而不是分解數據（雖然數據分片也可能是其中的一部分）。

分散/聚集根分布

最簡單的分散/聚集形式是每個葉子完全同質的分散/聚集形式，但是為了改善請求的性能，工作被分配到多個不同的葉子上。這種模式相當於解決了「不平行」的問題。這個問題可以分解成許多不同的部分，每個部分可以與其他部分一起放回去形成一個完整的答案。

為了更具體地理解這一點，假設你需要服務用戶請求R，並且單個核心需要一分鐘才能產生對此請求的答案A.如果我們編寫多線程應用程序，我們可以通過使用多個內核在單台機器上並行處理此請求。考慮到30核心的處理器（是的，通常它是一個32核心處理器，但是30可以使數學更清晰），我們可以將處理單個請求所需的時間減少到2秒（60秒的計算分裂為30個線程進行計算等於2秒）。但即使是兩秒鐘，服務用戶的網路請求也相當緩慢。另外，真正實現完全並行加速的單個進程將變得棘手，因為內存，網路或磁碟帶寬等事情開始成為瓶頸。我們可以使用分散/聚集模式來並行處理跨多個不同機器上的多個進程的請求，而不是在單個機器上的核心間並行化應用程序。通過這種方式，我們可以提高整體延遲請求的速度，因為我們不再受單個機器上可以獲得的內核數量的限制，並且確保我們流程中的瓶頸仍然是CPU，因為內存，網路和磁碟帶寬都分布在多個不同的機器上。此外，因為分散/聚集樹中的每台計算機都能夠處理每個請求，所以樹的根可以根據響應性在不同時間動態分配負載到不同節點。如果由於某種原因，某個特定葉節點的響應速度比其他機器慢（例如，它有一個干擾資源的嘈雜鄰居進程），那麼根可以動態地重新分配負載以確保快速響應。

分散/聚集與葉子分片

在應用複製的數據分散/聚集模式時，你可以減少處理用戶請求所需的處理時間，但不允許你擴展超出單個機器的內存或磁碟中可容納的數據量。就像前面描述的複製服務模式一樣，構建複製的分散/聚集系統很簡單。但是在一定的數據量下，為了構建一個可以容納比單個機器上存儲的數據更多的數據的系統，必須引入分片。

以前，當引入分片來擴展複製系統時，分片是在每個請求級別完成的。請求的某些部分用於確定請求的發送位置。然後該副本處理了請求的所有處理，並將響應交還給用戶。相反，使用分散/聚集分片，請求被發送到系統中的所有葉節點（或碎片）。每個葉子節點使用它在碎片中載入的數據來處理請求。然後將該部分響應返回到請求數據的根節點，並且根節點將所有響應合併在一起以形成用戶的全面響應。

作為這種體系結構的一個具體例子，考慮在一個非常大的文檔集中實施搜索（例如，世界上的所有專利）;在這種情況下，數據太大而無法放入單個機器的內存中，因此相反，數據在多個副本上分割。例如，0-100,000專利可能在第一台機器上，100,001-200,000在下一台機器上，等等。 （請注意，這實際上並不是一個好的分片方案，因為隨著新專利的註冊，它會不斷強制我們添加新的分片。實際上，我們可能會使用專利號碼模仿總分片數量。）當用戶提交要求在索引中的所有專利中查找特定詞（例如「火箭」），該請求被發送到每個分片，該分片在其專利分片中搜索與查詢中的詞相匹配的專利。響應分片請求，找到的任何匹配都會返回到根節點。然後，根節點將所有這些響應集中在一起，形成單個響應，其中包含與特定單詞匹配的所有專利。圖2說明了此搜索索引的操作。

選擇合適的樹葉數

看起來，在分散/聚集模式中，複製到大量葉子總是一個好主意。您可以並行化計算，從而縮短處理任何特定請求所需的時間。然而，增加並行化需要付出代價，因此在分散/聚集模式中選擇適當數量的葉節點對於設計高性能分散式系統至關重要。

為了理解如何發生，值得考慮兩件事。首先是處理任何特定的請求會有一定的開銷。這是解析請求，通過網路發送HTTP所花費的時間，等等。通常，由於系統請求處理而產生的開銷是恆定的，並且比用戶代碼處理請求花費的時間少得多。因此，在評估分散/聚集模式的性能時，通常可以忽略這種開銷。但是，了解此開銷的成本隨分散/聚集模式中葉節點的數量而變化很重要。因此，儘管成本較低，但隨著並行化的繼續，這種開銷最終會支配您業務邏輯的計算成本。這意味著並行化的收益是漸近的。

除了添加更多葉節點可能不會加速處理這一事實之外，分散/收集系統也會遭受「零散」問題的困擾。為了理解這是如何工作的，記住在分散/收集系統中，根節點等待來自所有葉節點的請求返回給最終用戶之前返回。由於需要來自每個葉節點的數據，所以處理用戶請求所花費的總時間由發送響應的最慢葉節點定義。為了理解這個影響，假設我們有一個服務的第99百分位延遲為2秒。這意味著平均每100個請求中的一個請求具有2秒的延遲，或者換句話說，有1％的機會請求需要2秒。乍一看這可能是完全可以接受的：單個用戶中有100個請求緩慢。但是，請考慮這是如何在分散/收集系統中起作用的。由於用戶請求的時間由最慢的響應定義，所以我們不需要考慮單個請求，而是將所有請求分散到各個葉節點。

讓我們看看當我們分散到五個葉節點時會發生什麼。在這種情況下，這5個分散請求中有一個有5％的機會有2秒的延遲（0.99×0.99×0.99×0.99×0.99 == 0.95）。這意味著對於我們的完整分散/收集系統，個人請求的第99個百分點延遲成為第95百分位延遲。而且它只會在那裡變得更糟：如果我們分散到100個樹葉，那麼我們或多或少地保證我們對所有請求的總體延遲將是2秒。

這些散射/收集系統的複雜性一起使我們得出一些結論：

• 由於每個節點上的開銷，增加的並行並不總是加快速度。
• 增加的並行性並不總是加快速度，因為這個問題很複雜。
• 第99百分位的表現比其他系統更重要，因為每個用戶請求實際上成為對服務的大量請求。
• 同樣的失敗者問題適用於可用性。如果向100個葉節點發出請求，並且發生任何葉節點失敗的概率為100分之1，則可再次保證每個用戶請求都失敗。

同樣的失敗者問題適用於可用性。如果向100個葉節點發出請求，並且發生任何葉節點失敗的概率為100分之1，則可再次保證每個用戶請求都失敗。

面向可靠性和規模化縮放分散/聚集

當然，就像使用分片系統一樣，擁有分片/收集系統的單個副本可能不是理想的設計選擇。單個副本意味著如果失敗，所有分散/聚集請求將在該分片不可用期間失敗，因為所有請求都需要由分散/聚集模式中的所有葉節點處理。同樣，升級將佔用碎片的一定比例，因此不會在面向用戶的負載下升級。最後，系統的計算規模將受到任何單個節點能夠實現的負載的限制。最終，這限制了你的規模，正如我們在前面的章節中所看到的那樣，你不能簡單地增加碎片的數量，以便提高分散/收集模式的計算能力。

考慮到可靠性和規模的這些挑戰，正確的方法是複製每個單獨的分片，以便在每個葉節點上代替單個實例，實現每個葉分片的複製服務。圖3顯示了這個複製的分片/分散式分散/聚集模式。

以這種方式構建，來自根目錄的每個葉子請求實際上在分片的所有健康副本中進行負載平衡。這意味著如果出現任何故障，它們不會導致系統出現用戶可見的故障。同樣，您可以安全地在負載下執行升級，因為每個複製碎片可以一次升級一個副本。事實上，您可以同時執行跨多個分片的升級，具體取決於您想要執行升級的速度。