抱歉提出這麼高水平的問題。我了解伺服器負載平衡的基礎知識，但管理 30,000 台伺服器的概念對我來說有點陌生。這真的只是平衡 2 或 3 台伺服器擴展 10,000 倍的相同概念嗎？
這與 memcached、sql/mysql、搜尋引擎等有何關係？
它是一個具有“控制器”伺服器和基於此傳遞資料的從屬伺服器的層級系統嗎？冗餘如何處理？
感謝您提供有關此事的文章的任何資訊或指導。
編輯謝謝你們的回應。我的帖子已關閉，但我修改了標題，希望它能重新打開，因為我發現這些超高級數據解決方案涉及的問題解決過程非常有趣，而且我目前正在構建一個需要一些基本負載的 api平衡，因此產生這個問題。
答案1
谷歌在其伺服器上使用的大部分軟體堆疊都是內部開發的。為了減輕不可避免的硬體故障的影響，軟體被設計為具有容錯能力。
來源：谷歌平台
讀完這篇文章後，我猜測這與透過使用在 Linux 上內部開發的內部軟體堆疊來平衡少量伺服器擴展到 1000 多台伺服器之間的負載是相同的概念。例如政府財政司司長（Google檔案系統），大表- 基於GFS建構的結構化儲存系統
這連結描述了它們如何平衡網路負載。
他們使用負載平衡交換機來分配負載。對網站的所有請求都到達一台機器，然後該機器將請求傳遞到其中一台可用伺服器。交換器可以從伺服器中找出負載最少的伺服器，因此所有伺服器都在執行相同的工作。
Google 的網路拓撲如下：
當用戶端電腦嘗試連線到 Google 時，多個 DNS 伺服器會透過循環策略將 www.google.com 解析為多個 IP 位址。此外，這充當負載平衡的第一級，並將客戶端引導至不同的 Google 叢集。 Google 叢集擁有數千台伺服器，一旦用戶端連接到伺服器，就會進行額外的負載平衡，將查詢傳送到負載最少的 Web 伺服器。
答案2
這裡最重要的是，如果軟體的設計不是為了擴展，那怎麼可能呢？例如，Facebook 目前最大的限制之一是他們對 MySQL 的依賴——他們已經能夠透過投入越來越多的機器來繞過這個問題，但是他們自己的工程師稱之為「比死亡更糟糕的命運」。
通常，您需要能夠對請求進行負載平衡——並且設計了許多項目，無論是開源專案還是其他項目。但這會帶來開銷，包括寫入日誌、延遲寫入和「最終一致」架構。換句話說，擴展並不便宜。
因此，像提供靜態內容的 Web 伺服器這樣的東西可以很容易地並行化。 Memcached 和其他快取系統很容易實現負載平衡。但如何改變單點故障呢？您的單一大型關聯式資料庫如何擴展？文件儲存怎麼樣？從本質上講，這是一個完整的研究分支……不是單一問題就能回答的問題。
答案3
我認為相同的概念應該是相同的，關鍵點是如何在可用資源之間分配負載和資料以及如何定位資料。
一種方法是伺服器的地理分佈。每個用戶將被定向到最近的伺服器。
類似註冊表的服務可用於尋找所要求的資料。
考慮 DNS 服務的實作。它擁有一個非常龐大的分散式資料庫。根節點將使用者引導到其他較低層級的節點，依此類推，直到到達可以回答您的查詢的負責節點。