設(shè)計(jì)一個(gè)支持百萬(wàn)用戶的系統(tǒng)是具有挑戰(zhàn)性的，這是一段需要不斷改進(jìn)和不斷提升的旅程。在本章中，我們將構(gòu)建一個(gè)支持單個(gè)用戶的系統(tǒng)，并逐漸擴(kuò)展以服務(wù)于數(shù)百萬(wàn)用戶。閱讀本章后，您將掌握一些技巧，幫助您解決系統(tǒng)設(shè)計(jì)面試問(wèn)題。

AI不會(huì)取代你,使用AI的人會(huì)。歡迎關(guān)注我的公眾號(hào)：更AI。以程序員的視角來(lái)看AI能帶給我們什么~

單服務(wù)器設(shè)置

千里之行始于足下，構(gòu)建一個(gè)復(fù)雜的系統(tǒng)也是如此。為了從簡(jiǎn)單的東西開始，我們將所有內(nèi)容都運(yùn)行在一個(gè)單獨(dú)的服務(wù)器上。圖1顯示了一個(gè)單服務(wù)器設(shè)置的示意圖，其中所有內(nèi)容都在一個(gè)服務(wù)器上運(yùn)行：Web應(yīng)用程序、數(shù)據(jù)庫(kù)、緩存等。

為了理解這個(gè)設(shè)置，有助于調(diào)查請(qǐng)求流程和流量來(lái)源。讓我們首先看一下請(qǐng)求流程（圖1-2）。

1. 用戶通過(guò)域名訪問(wèn)網(wǎng)站，例如api.mysite.com。通常，域名系統(tǒng)（DNS）是由第三方提供的付費(fèi)服務(wù)，而不是由我們的服務(wù)器托管。
2. Internet協(xié)議（IP）地址返回給瀏覽器或移動(dòng)應(yīng)用。在本例中，返回的IP地址是15.125.23.214。
3. 一旦獲得IP地址，超文本傳輸協(xié)議（HTTP）[1]請(qǐng)求將直接發(fā)送到您的Web服務(wù)器。
4. Web服務(wù)器返回HTML頁(yè)面或JSON響應(yīng)進(jìn)行渲染。

接下來(lái)，讓我們來(lái)看一下流量來(lái)源。流向您的Web服務(wù)器的流量來(lái)自兩個(gè)來(lái)源：Web應(yīng)用程序和移動(dòng)應(yīng)用程序。

• Web應(yīng)用程序：它使用一組服務(wù)器端語(yǔ)言（Java、Python等）來(lái)處理業(yè)務(wù)邏輯、存儲(chǔ)等，以及客戶端語(yǔ)言（HTML和JavaScript）來(lái)進(jìn)行展示。
• 移動(dòng)應(yīng)用程序：HTTP協(xié)議是移動(dòng)應(yīng)用程序與Web服務(wù)器之間的通信協(xié)議。由于其簡(jiǎn)單性，JavaScript對(duì)象表示法（JSON）通常用于傳輸數(shù)據(jù)的API響應(yīng)格式。下面是一個(gè)以JSON格式顯示的API響應(yīng)示例：

GET /users/12 – 檢索id為12的用戶對(duì)象

數(shù)據(jù)庫(kù)

隨著用戶群體的增長(zhǎng)，一個(gè)服務(wù)器已經(jīng)不夠用了，我們需要多臺(tái)服務(wù)器：一臺(tái)用于處理網(wǎng)站和移動(dòng)端的流量，另一臺(tái)用于數(shù)據(jù)庫(kù)（圖1-3）。將網(wǎng)站和移動(dòng)端流量（Web層）與數(shù)據(jù)庫(kù)（數(shù)據(jù)層）服務(wù)器分離，可以使它們能夠獨(dú)立擴(kuò)展。

使用哪種數(shù)據(jù)庫(kù)？

您可以選擇傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)或非關(guān)系型數(shù)據(jù)庫(kù)。讓我們來(lái)看看它們的區(qū)別。

關(guān)系型數(shù)據(jù)庫(kù)也被稱為關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)（RDBMS）或SQL數(shù)據(jù)庫(kù)。最流行的有MySQL、Oracle數(shù)據(jù)庫(kù)、PostgreSQL等。關(guān)系型數(shù)據(jù)庫(kù)使用表和行來(lái)表示和存儲(chǔ)數(shù)據(jù)。您可以使用SQL在不同的數(shù)據(jù)庫(kù)表之間執(zhí)行聯(lián)接操作。

非關(guān)系型數(shù)據(jù)庫(kù)也被稱為NoSQL數(shù)據(jù)庫(kù)。流行的有CouchDB、Neo4j、Cassandra、HBase、Amazon DynamoDB等[2]。這些數(shù)據(jù)庫(kù)分為四類：鍵值存儲(chǔ)、圖存儲(chǔ)、列存儲(chǔ)和文檔存儲(chǔ)。非關(guān)系型數(shù)據(jù)庫(kù)通常不支持聯(lián)接操作。

對(duì)于大多數(shù)開發(fā)者來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)是最佳選擇，因?yàn)樗鼈円呀?jīng)存在了40多年，并且在歷史上表現(xiàn)良好。然而，如果關(guān)系型數(shù)據(jù)庫(kù)不適合您特定的使用情況，探索超越關(guān)系型數(shù)據(jù)庫(kù)是至關(guān)重要的。如果滿足以下情況，非關(guān)系型數(shù)據(jù)庫(kù)可能是正確的選擇：

• 您的應(yīng)用程序需要超低的延遲。
• 您的數(shù)據(jù)是非結(jié)構(gòu)化的，或者您沒(méi)有任何關(guān)系數(shù)據(jù)。
• 您只需要對(duì)數(shù)據(jù)進(jìn)行序列化和反序列化（JSON、XML、YAML等）。
• 您需要存儲(chǔ)大量的數(shù)據(jù)。

垂直擴(kuò)展與水平擴(kuò)展

垂直擴(kuò)展，也稱為“縱向擴(kuò)展”，是指向服務(wù)器添加更多的處理能力（CPU、RAM等）的過(guò)程。水平擴(kuò)展，也稱為“橫向擴(kuò)展”，允許您通過(guò)向資源池中添加更多的服務(wù)器來(lái)進(jìn)行擴(kuò)展。

當(dāng)流量較低時(shí)，垂直擴(kuò)展是一個(gè)很好的選擇，垂直擴(kuò)展的簡(jiǎn)單性是其主要優(yōu)點(diǎn)。不幸的是，它也存在一些嚴(yán)重的局限性。

• 垂直擴(kuò)展有一個(gè)硬性限制。不可能向單個(gè)服務(wù)器添加無(wú)限的CPU和內(nèi)存。
• 垂直擴(kuò)展沒(méi)有故障轉(zhuǎn)移和冗余。如果一個(gè)服務(wù)器宕機(jī)，網(wǎng)站/應(yīng)用將完全無(wú)法訪問(wèn)。

由于垂直擴(kuò)展的限制，對(duì)于大規(guī)模應(yīng)用程序來(lái)說(shuō)，水平擴(kuò)展更加理想。

在之前的設(shè)計(jì)中，用戶直接連接到Web服務(wù)器。如果Web服務(wù)器脫機(jī)，用戶將無(wú)法訪問(wèn)網(wǎng)站。在另一種情況下，如果許多用戶同時(shí)訪問(wèn)Web服務(wù)器并達(dá)到Web服務(wù)器的負(fù)載限制，用戶通常會(huì)遇到響應(yīng)變慢或無(wú)法連接到服務(wù)器的問(wèn)題。負(fù)載均衡器是解決這些問(wèn)題的最佳技術(shù)。

負(fù)載均衡器

負(fù)載均衡器會(huì)將傳入的流量均勻分配給在負(fù)載均衡集合中定義的Web服務(wù)器。圖1-4展示了負(fù)載均衡器的工作原理。

如圖1-4所示，用戶直接連接負(fù)載均衡器的公共IP。通過(guò)這種設(shè)置，Web服務(wù)器不再能直接被客戶端訪問(wèn)。為了更好的安全性，私有IP用于服務(wù)器之間的通信。私有IP是一個(gè)只能在同一網(wǎng)絡(luò)中的服務(wù)器之間訪問(wèn)的IP地址，無(wú)法通過(guò)互聯(lián)網(wǎng)訪問(wèn)。負(fù)載均衡器通過(guò)私有IP與Web服務(wù)器進(jìn)行通信。

在圖1-4中，當(dāng)負(fù)載均衡器和第二個(gè)Web服務(wù)器添加后，我們成功解決了故障切換的問(wèn)題，并提高了Web層的可用性。具體細(xì)節(jié)如下：

• 如果服務(wù)器1下線，所有流量將被路由到服務(wù)器2。這樣可以防止網(wǎng)站宕機(jī)。我們還可以向服務(wù)器池中添加一個(gè)新的健康Web服務(wù)器來(lái)平衡負(fù)載。
• 如果網(wǎng)站流量迅速增長(zhǎng)，兩個(gè)服務(wù)器無(wú)法處理流量，負(fù)載均衡器可以優(yōu)雅地解決這個(gè)問(wèn)題。您只需要向Web服務(wù)器池添加更多服務(wù)器，負(fù)載均衡器將自動(dòng)開始將請(qǐng)求發(fā)送給它們。

現(xiàn)在Web層看起來(lái)很好，那數(shù)據(jù)層呢？當(dāng)前的設(shè)計(jì)只有一個(gè)數(shù)據(jù)庫(kù)，因此不支持故障轉(zhuǎn)移和冗余。數(shù)據(jù)庫(kù)復(fù)制是解決這些問(wèn)題的常見技術(shù)。讓我們來(lái)看一下。

數(shù)據(jù)庫(kù)復(fù)制

引用自維基百科：“數(shù)據(jù)庫(kù)復(fù)制可以在許多數(shù)據(jù)庫(kù)管理系統(tǒng)中使用，通常在原始數(shù)據(jù)庫(kù)（主數(shù)據(jù)庫(kù)）和副本（從數(shù)據(jù)庫(kù)）之間建立主/從關(guān)系?！?[3]

主數(shù)據(jù)庫(kù)通常僅支持寫操作。從數(shù)據(jù)庫(kù)從主數(shù)據(jù)庫(kù)獲取數(shù)據(jù)的副本，僅支持讀操作。所有的插入、刪除或更新等修改數(shù)據(jù)的命令必須發(fā)送到主數(shù)據(jù)庫(kù)。大多數(shù)應(yīng)用程序需要更高比例的讀操作與寫操作，因此系統(tǒng)中從數(shù)據(jù)庫(kù)的數(shù)量通常大于主數(shù)據(jù)庫(kù)的數(shù)量。圖1-5顯示了一個(gè)具有多個(gè)從數(shù)據(jù)庫(kù)的主數(shù)據(jù)庫(kù)。

數(shù)據(jù)庫(kù)復(fù)制的優(yōu)勢(shì)：

• 更好的性能：在主從模型中，所有的寫操作和更新操作都發(fā)生在主節(jié)點(diǎn)上，而讀操作分布在從節(jié)點(diǎn)上。這種模型改善了性能，因?yàn)樗试S更多的查詢并行處理。
• 可靠性：如果你的數(shù)據(jù)庫(kù)服務(wù)器之一被自然災(zāi)害（如臺(tái)風(fēng)或地震）摧毀，數(shù)據(jù)仍然得以保留。你不需要擔(dān)心數(shù)據(jù)丟失，因?yàn)閿?shù)據(jù)被復(fù)制到多個(gè)位置。
• 高可用性：通過(guò)在不同的位置復(fù)制數(shù)據(jù)，即使一個(gè)數(shù)據(jù)庫(kù)離線，你的網(wǎng)站仍然可以運(yùn)行，因?yàn)槟憧梢栽L問(wèn)存儲(chǔ)在另一個(gè)數(shù)據(jù)庫(kù)服務(wù)器中的數(shù)據(jù)。

在前一節(jié)中，我們討論了負(fù)載均衡器如何幫助提高系統(tǒng)的可用性。我們?cè)谶@里提出同樣的問(wèn)題：如果其中一個(gè)數(shù)據(jù)庫(kù)離線了會(huì)怎么樣？圖1-5中討論的架構(gòu)設(shè)計(jì)可以處理這種情況：

• 如果只有一個(gè)可用的從數(shù)據(jù)庫(kù)，并且它離線了，讀操作將暫時(shí)指向主數(shù)據(jù)庫(kù)。一旦問(wèn)題被發(fā)現(xiàn)，一個(gè)新的從數(shù)據(jù)庫(kù)將取代舊的數(shù)據(jù)庫(kù)。如果有多個(gè)可用的從數(shù)據(jù)庫(kù)，讀操作將被重定向到其他健康的從數(shù)據(jù)庫(kù)。一個(gè)新的數(shù)據(jù)庫(kù)服務(wù)器將取代舊的數(shù)據(jù)庫(kù)。
• 如果主數(shù)據(jù)庫(kù)離線了，一個(gè)從數(shù)據(jù)庫(kù)將被提升為新的主數(shù)據(jù)庫(kù)。所有的數(shù)據(jù)庫(kù)操作將在新的主數(shù)據(jù)庫(kù)上暫時(shí)執(zhí)行。一個(gè)新的從數(shù)據(jù)庫(kù)將立即取代舊的數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)復(fù)制。在生產(chǎn)系統(tǒng)中，提升新的主數(shù)據(jù)庫(kù)更為復(fù)雜，因?yàn)閺臄?shù)據(jù)庫(kù)中的數(shù)據(jù)可能不是最新的。需要通過(guò)運(yùn)行數(shù)據(jù)恢復(fù)腳本來(lái)更新缺失的數(shù)據(jù)。雖然一些其他的復(fù)制方法，如多主和環(huán)形復(fù)制，可以提供幫助，但這些設(shè)置更加復(fù)雜，它們的討論超出了本書的范圍。有興趣的讀者可以參考所列的參考資料[4] [5]。

圖1-6顯示了添加了負(fù)載均衡器和數(shù)據(jù)庫(kù)復(fù)制后的系統(tǒng)設(shè)計(jì)。

讓我們來(lái)看一下設(shè)計(jì)：

• 用戶從DNS獲取負(fù)載均衡器的IP地址。
• 用戶使用該IP地址連接到負(fù)載均衡器。
• HTTP請(qǐng)求被路由到服務(wù)器1或服務(wù)器2。
• Web服務(wù)器從從數(shù)據(jù)庫(kù)讀取用戶數(shù)據(jù)。
• Web服務(wù)器將任何修改數(shù)據(jù)的操作路由到主數(shù)據(jù)庫(kù)。包括寫入、更新和刪除操作。
• 現(xiàn)在，你已經(jīng)對(duì)Web和數(shù)據(jù)層有了扎實(shí)的理解，是時(shí)候通過(guò)添加緩存層并將靜態(tài)內(nèi)容（JavaScript/CSS/圖像/視頻文件）轉(zhuǎn)移到內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）來(lái)提高負(fù)載/響應(yīng)時(shí)間了。

緩存

緩存是一個(gè)臨時(shí)存儲(chǔ)區(qū)，用于在內(nèi)存中存儲(chǔ)昂貴的響應(yīng)結(jié)果或經(jīng)常訪問(wèn)的數(shù)據(jù)，以便后續(xù)的請(qǐng)求可以更快地得到服務(wù)。如圖1-6所示，每次加載新的網(wǎng)頁(yè)時(shí)，會(huì)執(zhí)行一個(gè)或多個(gè)數(shù)據(jù)庫(kù)調(diào)用來(lái)獲取數(shù)據(jù)。反復(fù)調(diào)用數(shù)據(jù)庫(kù)會(huì)嚴(yán)重影響應(yīng)用程序性能。緩存可以緩解這個(gè)問(wèn)題。

緩存層

緩存層是一個(gè)比數(shù)據(jù)庫(kù)快得多的臨時(shí)數(shù)據(jù)存儲(chǔ)層。擁有獨(dú)立的緩存層有以下好處：系統(tǒng)性能更好、能夠減少數(shù)據(jù)庫(kù)工作負(fù)載以及能夠獨(dú)立擴(kuò)展緩存層。圖1-7顯示了一個(gè)可能的緩存服務(wù)器設(shè)置：

收到請(qǐng)求后，Web服務(wù)器首先檢查緩存中是否有可用的響應(yīng)。如果有，則將數(shù)據(jù)發(fā)送回客戶端。如果沒(méi)有，則查詢數(shù)據(jù)庫(kù)，將響應(yīng)存儲(chǔ)在緩存中，并將其發(fā)送回客戶端。這種緩存策略稱為讀取穿透緩存。根據(jù)數(shù)據(jù)類型、大小和訪問(wèn)模式，還可以使用其他緩存策略。一項(xiàng)以前的研究解釋了不同的緩存策略如何工作[6]。與緩存服務(wù)器的交互非常簡(jiǎn)單，因?yàn)榇蠖鄶?shù)緩存服務(wù)器為常見的編程語(yǔ)言提供API。以下代碼片段顯示了典型的Memcached API：

使用緩存的注意事項(xiàng)

以下是使用緩存系統(tǒng)時(shí)應(yīng)考慮的幾個(gè)問(wèn)題：

• 決定何時(shí)使用緩存。在數(shù)據(jù)經(jīng)常被讀取但很少被修改時(shí)，考慮使用緩存。由于緩存數(shù)據(jù)存儲(chǔ)在易失性內(nèi)存中，緩存服務(wù)器不適合用于持久化數(shù)據(jù)。例如，如果緩存服務(wù)器重新啟動(dòng)，內(nèi)存中的所有數(shù)據(jù)都會(huì)丟失。因此，重要的數(shù)據(jù)應(yīng)保存在持久化數(shù)據(jù)存儲(chǔ)中。

• 過(guò)期策略。實(shí)施過(guò)期策略是一個(gè)好的做法。一旦緩存數(shù)據(jù)過(guò)期，它將從緩存中刪除。當(dāng)沒(méi)有過(guò)期策略時(shí)，緩存數(shù)據(jù)將永久存儲(chǔ)在內(nèi)存中。建議不要將過(guò)期日期設(shè)置得太短，否則系統(tǒng)會(huì)過(guò)于頻繁地從數(shù)據(jù)庫(kù)重新加載數(shù)據(jù)。同時(shí)，也不建議將過(guò)期日期設(shè)置得太長(zhǎng)，以免數(shù)據(jù)變得陳舊。

• 一致性：這涉及保持?jǐn)?shù)據(jù)存儲(chǔ)和緩存的同步。由于數(shù)據(jù)存儲(chǔ)和緩存上的數(shù)據(jù)修改操作不在單個(gè)事務(wù)中，所以可能發(fā)生不一致。在跨多個(gè)地區(qū)進(jìn)行擴(kuò)展時(shí)，保持?jǐn)?shù)據(jù)存儲(chǔ)和緩存之間的一致性是具有挑戰(zhàn)性的。有關(guān)詳細(xì)信息，請(qǐng)參考Facebook發(fā)表的題為《Scaling Memcache at Facebook》的論文[7]。

• 減輕故障：?jiǎn)蝹€(gè)緩存服務(wù)器代表潛在的單點(diǎn)故障（SPOF），維基百科對(duì)其的定義如下：“單點(diǎn)故障（SPOF）是系統(tǒng)的一部分，如果它發(fā)生故障，將導(dǎo)致整個(gè)系統(tǒng)停止工作”[8]。因此，建議在不同的數(shù)據(jù)中心中使用多個(gè)緩存服務(wù)器，以避免單點(diǎn)故障。另一個(gè)推薦的方法是通過(guò)一定百分比進(jìn)行過(guò)量配置所需的內(nèi)存。這樣可以提供一個(gè)緩沖區(qū)，以應(yīng)對(duì)內(nèi)存使用量增加的情況。

• 淘汰策略：一旦緩存已滿，任何向緩存中添加項(xiàng)的請(qǐng)求都可能導(dǎo)致現(xiàn)有項(xiàng)被移除。這被稱為緩存淘汰。最近最少使用（LRU）是最常見的緩存淘汰策略。其他淘汰策略，如最不經(jīng)常使用（LFU）或先進(jìn)先出（FIFO），可根據(jù)不同的使用情況采用。

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）

CDN是一個(gè)由地理分布的服務(wù)器組成的網(wǎng)絡(luò)，用于傳送靜態(tài)內(nèi)容。CDN服務(wù)器緩存像圖像、視頻、CSS、JavaScript文件等靜態(tài)內(nèi)容。

動(dòng)態(tài)內(nèi)容緩存是一個(gè)相對(duì)較新的概念，超出了本書的范圍。它使得可以緩存基于請(qǐng)求路徑、查詢字符串、cookie和請(qǐng)求頭的HTML頁(yè)面。有關(guān)更多信息，請(qǐng)參考參考資料[9]中提到的文章。本書重點(diǎn)介紹如何使用CDN來(lái)緩存靜態(tài)內(nèi)容。

以下是CDN的高級(jí)工作原理：當(dāng)用戶訪問(wèn)網(wǎng)站時(shí)，距離用戶最近的CDN服務(wù)器將傳送靜態(tài)內(nèi)容。直觀來(lái)說(shuō)，用戶離CDN服務(wù)器越遠(yuǎn)，網(wǎng)站加載速度就越慢。例如，如果CDN服務(wù)器位于舊金山，洛杉磯的用戶將比歐洲的用戶更快地獲取內(nèi)容。圖1-9是一個(gè)很好的示例，顯示了CDN如何提高加載時(shí)間。

圖1-10展示了CDN的工作流程。

1. 用戶A嘗試使用圖像URL獲取image.png。URL的域名由CDN提供商提供。以下兩個(gè)圖像URL是用來(lái)演示Amazon和Akamai CDN上圖像URL的樣例：
   • https://mysite.cloudfront.net/logo.jpg
   • https://mysite.akamai.com/image-manager/img/logo.jpg
2. 如果CDN服務(wù)器沒(méi)有image.png的緩存，CDN服務(wù)器會(huì)從源（可以是Web服務(wù)器或像Amazon S3這樣的在線存儲(chǔ)）請(qǐng)求文件。
3. 源將image.png返回給CDN服務(wù)器，其中包括可選的HTTP頭部Time-to-Live（TTL），描述圖像被緩存的時(shí)間。
4. CDN緩存圖像并將其返回給用戶A。圖像會(huì)在CDN中緩存，直到TTL過(guò)期。
5. 用戶B發(fā)送請(qǐng)求以獲取相同的圖像。
6. 只要TTL未過(guò)期，圖像將從緩存中返回。

CDN 使用的考慮因素

• 成本：CDN 由第三方提供商運(yùn)營(yíng)，您需要支付 CDN 內(nèi)外的數(shù)據(jù)傳輸費(fèi)用。對(duì)于不經(jīng)常使用的資源，緩存并沒(méi)有顯著的好處，所以您應(yīng)該考慮將其移出 CDN。
• 設(shè)置適當(dāng)?shù)木彺孢^(guò)期時(shí)間：對(duì)于時(shí)間敏感的內(nèi)容，設(shè)置緩存過(guò)期時(shí)間非常重要。緩存過(guò)期時(shí)間既不能太長(zhǎng)也不能太短。如果時(shí)間太長(zhǎng)，內(nèi)容可能已經(jīng)不新鮮。如果時(shí)間太短，可能會(huì)導(dǎo)致重復(fù)從源服務(wù)器重新加載內(nèi)容到 CDN。
• CDN 回退：您應(yīng)該考慮您的網(wǎng)站/應(yīng)用程序如何應(yīng)對(duì) CDN 故障。如果出現(xiàn)臨時(shí)的 CDN 中斷，客戶端應(yīng)該能夠檢測(cè)到問(wèn)題并從源獲取資源。
• 使文件失效：您可以在文件過(guò)期之前從 CDN 中移除文件，具體操作有以下幾種：
  • 使用 CDN 供應(yīng)商提供的 API 使 CDN 對(duì)象失效。
  • 使用對(duì)象版本控制來(lái)提供不同版本的對(duì)象。要對(duì)對(duì)象進(jìn)行版本控制，可以向 URL 添加參數(shù)，比如版本號(hào)。例如，查詢字符串中添加版本號(hào) 2：image.png?v=2。

圖 1-11 展示了在添加 CDN 和緩存后的設(shè)計(jì)。

1. 靜態(tài)資源（JS、CSS、圖片等）不再由 Web 服務(wù)器提供。它們從 CDN 獲取以獲得更好的性能。
2. 通過(guò)緩存數(shù)據(jù)減輕了數(shù)據(jù)庫(kù)的負(fù)載。

無(wú)狀態(tài)的Web層

現(xiàn)在是考慮水平擴(kuò)展Web層的時(shí)候了。為此，我們需要將狀態(tài)（例如用戶會(huì)話數(shù)據(jù)）從Web層中移出。一個(gè)很好的做法是將會(huì)話數(shù)據(jù)存儲(chǔ)在持久性存儲(chǔ)中，如關(guān)系型數(shù)據(jù)庫(kù)或NoSQL數(shù)據(jù)庫(kù)。集群中的每個(gè)Web服務(wù)器都可以從數(shù)據(jù)庫(kù)中訪問(wèn)狀態(tài)數(shù)據(jù)。這被稱為無(wú)狀態(tài)的Web層。

有狀態(tài)架構(gòu)

有狀態(tài)服務(wù)器和無(wú)狀態(tài)服務(wù)器有一些關(guān)鍵區(qū)別。有狀態(tài)服務(wù)器會(huì)記住從一個(gè)請(qǐng)求到下一個(gè)請(qǐng)求的客戶端數(shù)據(jù)（狀態(tài)）。無(wú)狀態(tài)服務(wù)器不保存任何狀態(tài)信息。

圖1-12顯示了一個(gè)有狀態(tài)架構(gòu)的示例。

在圖1-12中，用戶A的會(huì)話數(shù)據(jù)和個(gè)人資料圖片存儲(chǔ)在服務(wù)器1中。要對(duì)用戶A進(jìn)行身份驗(yàn)證，HTTP請(qǐng)求必須路由到服務(wù)器1。如果請(qǐng)求被發(fā)送到其他服務(wù)器，如服務(wù)器2，身份驗(yàn)證將失敗，因?yàn)榉?wù)器2不包含用戶A的會(huì)話數(shù)據(jù)。同樣，來(lái)自用戶B的所有HTTP請(qǐng)求必須路由到服務(wù)器2；來(lái)自用戶C的所有請(qǐng)求必須發(fā)送到服務(wù)器3。

問(wèn)題在于同一客戶端的每個(gè)請(qǐng)求必須路由到同一臺(tái)服務(wù)器。在大多數(shù)負(fù)載均衡器中，可以通過(guò)粘性會(huì)話來(lái)實(shí)現(xiàn)這一點(diǎn)[10]；然而，這會(huì)增加開銷。使用這種方法更加困難地添加或刪除服務(wù)器。處理服務(wù)器故障也是一項(xiàng)挑戰(zhàn)。

無(wú)狀態(tài)架構(gòu)

圖1-13展示了無(wú)狀態(tài)架構(gòu)。

在這種無(wú)狀態(tài)架構(gòu)中，用戶的HTTP請(qǐng)求可以發(fā)送到任何Web服務(wù)器，這些服務(wù)器從共享數(shù)據(jù)存儲(chǔ)中獲取狀態(tài)數(shù)據(jù)。狀態(tài)數(shù)據(jù)存儲(chǔ)在共享數(shù)據(jù)存儲(chǔ)中，并且不保存在Web服務(wù)器中。無(wú)狀態(tài)系統(tǒng)更簡(jiǎn)單、更健壯和可擴(kuò)展。

圖1-14展示了帶有無(wú)狀態(tài)Web層的更新設(shè)計(jì)。

在圖1-14中，我們將會(huì)話數(shù)據(jù)從Web層移出，并將其存儲(chǔ)在持久數(shù)據(jù)存儲(chǔ)中。共享數(shù)據(jù)存儲(chǔ)可以是關(guān)系數(shù)據(jù)庫(kù)、Memcached/Redis、NoSQL等。選擇NoSQL數(shù)據(jù)存儲(chǔ)是因?yàn)樗子跀U(kuò)展。自動(dòng)擴(kuò)展意味著根據(jù)流量負(fù)載自動(dòng)添加或刪除Web服務(wù)器。在狀態(tài)數(shù)據(jù)從Web服務(wù)器中移除后，根據(jù)流量負(fù)載添加或刪除服務(wù)器輕松實(shí)現(xiàn)Web層的自動(dòng)擴(kuò)展。

您的網(wǎng)站快速增長(zhǎng)，并吸引了大量國(guó)際用戶。為了提高可用性并在更廣泛的地理區(qū)域提供更好的用戶體驗(yàn)，支持多個(gè)數(shù)據(jù)中心至關(guān)重要。

數(shù)據(jù)中心

圖1-15顯示了一個(gè)擁有兩個(gè)數(shù)據(jù)中心的示例設(shè)置。在正常運(yùn)行時(shí)，用戶會(huì)根據(jù)地理位置通過(guò)geoDNS路由到最近的數(shù)據(jù)中心，其中在美國(guó)東部的流量占x%，在美國(guó)西部的流量占(100 - x)%。geoDNS是一種DNS服務(wù)，根據(jù)用戶所在地將域名解析為IP地址。

如果發(fā)生任何重大數(shù)據(jù)中心故障，我們會(huì)將所有流量引導(dǎo)到一個(gè)正常運(yùn)行的數(shù)據(jù)中心。在圖1-16中，數(shù)據(jù)中心2（美國(guó)西部）離線，100%的流量被路由到數(shù)據(jù)中心1（美國(guó)東部）。

要實(shí)現(xiàn)多數(shù)據(jù)中心設(shè)置，需要解決一些技術(shù)挑戰(zhàn)：

• 流量重定向：需要有效的工具將流量引導(dǎo)到正確的數(shù)據(jù)中心。根據(jù)用戶所在地，可以使用geoDNS將流量引導(dǎo)到最近的數(shù)據(jù)中心。
• 數(shù)據(jù)同步：來(lái)自不同地區(qū)的用戶可能使用不同的本地?cái)?shù)據(jù)庫(kù)或緩存。在故障轉(zhuǎn)移情況下，流量可能會(huì)路由到一個(gè)數(shù)據(jù)中心，該數(shù)據(jù)中心的數(shù)據(jù)不可用。一種常見的策略是在多個(gè)數(shù)據(jù)中心之間復(fù)制數(shù)據(jù)。一項(xiàng)先前的研究展示了Netflix如何實(shí)現(xiàn)異步多數(shù)據(jù)中心復(fù)制[11]。
• 測(cè)試和部署：對(duì)于多數(shù)據(jù)中心設(shè)置，重要的是在不同的位置測(cè)試您的網(wǎng)站/應(yīng)用程序。自動(dòng)化部署工具對(duì)于保持所有數(shù)據(jù)中心的服務(wù)一致至關(guān)重要[11]。

為了進(jìn)一步擴(kuò)展我們的系統(tǒng)，我們需要解耦系統(tǒng)的不同組件，使它們可以獨(dú)立擴(kuò)展。消息隊(duì)列是許多實(shí)際分布式系統(tǒng)用于解決這個(gè)問(wèn)題的關(guān)鍵策略。

消息隊(duì)列

消息隊(duì)列是一種持久性組件，存儲(chǔ)在內(nèi)存中，用于支持異步通信。它作為緩沖區(qū)并分發(fā)異步請(qǐng)求。消息隊(duì)列的基本架構(gòu)很簡(jiǎn)單。稱為生產(chǎn)者/發(fā)布者的輸入服務(wù)創(chuàng)建消息，并將其發(fā)布到消息隊(duì)列中。其他服務(wù)或服務(wù)器，稱為消費(fèi)者/訂閱者，連接到隊(duì)列并執(zhí)行消息定義的操作。模型如圖1-17所示。

解耦使消息隊(duì)列成為構(gòu)建可擴(kuò)展和可靠應(yīng)用程序的首選架構(gòu)。使用消息隊(duì)列，當(dāng)消費(fèi)者無(wú)法處理消息時(shí)，生產(chǎn)者可以將消息發(fā)布到隊(duì)列中。即使生產(chǎn)者不可用，消費(fèi)者也可以從隊(duì)列中讀取消息。

考慮以下用例：您的應(yīng)用程序支持照片定制，包括裁剪、銳化、模糊等操作。這些定制任務(wù)需要時(shí)間來(lái)完成。在圖1-18中，Web服務(wù)器將照片處理作業(yè)發(fā)布到消息隊(duì)列中。照片處理工作者從消息隊(duì)列中接收作業(yè)，并異步執(zhí)行照片定制任務(wù)。生產(chǎn)者和消費(fèi)者可以獨(dú)立擴(kuò)展。當(dāng)隊(duì)列的大小變大時(shí)，可以添加更多工作者以減少處理時(shí)間。然而，如果隊(duì)列大部分時(shí)間為空，工作者的數(shù)量可以減少。

日志記錄、指標(biāo)、自動(dòng)化

在處理只運(yùn)行在幾臺(tái)服務(wù)器上的小型網(wǎng)站時(shí)，日志記錄、指標(biāo)和自動(dòng)化支持是良好的實(shí)踐，但并非必需。然而，現(xiàn)在你的網(wǎng)站已經(jīng)發(fā)展成為一個(gè)為大型企業(yè)提供服務(wù)的網(wǎng)站，投資于這些工具是必不可少的。

日志記錄：監(jiān)控錯(cuò)誤日志非常重要，因?yàn)樗兄谧R(shí)別系統(tǒng)中的錯(cuò)誤和問(wèn)題。您可以在每個(gè)服務(wù)器級(jí)別監(jiān)控錯(cuò)誤日志，也可以使用工具將它們聚合到一個(gè)集中式服務(wù)中，以便進(jìn)行簡(jiǎn)單的搜索和查看。

指標(biāo)：收集不同類型的指標(biāo)有助于我們獲取業(yè)務(wù)見解并了解系統(tǒng)的健康狀況。以下是一些有用的指標(biāo)：

• 主機(jī)級(jí)別的指標(biāo)：CPU、內(nèi)存、磁盤I/O等。
• 聚合級(jí)別的指標(biāo)：例如整個(gè)數(shù)據(jù)庫(kù)層、緩存層等的性能。
• 關(guān)鍵業(yè)務(wù)指標(biāo)：每日活躍用戶、留存率、收入等。

自動(dòng)化：當(dāng)系統(tǒng)變得龐大而復(fù)雜時(shí)，我們需要構(gòu)建或利用自動(dòng)化工具來(lái)提高生產(chǎn)效率。持續(xù)集成是一種良好的實(shí)踐，通過(guò)自動(dòng)化驗(yàn)證每次代碼提交，使團(tuán)隊(duì)能夠早期發(fā)現(xiàn)問(wèn)題。此外，自動(dòng)化構(gòu)建、測(cè)試、部署流程等可以顯著提高開發(fā)人員的生產(chǎn)力。

添加消息隊(duì)列和其他工具

圖1-19顯示了更新后的設(shè)計(jì)。由于空間限制，圖中只顯示了一個(gè)數(shù)據(jù)中心。

1. 設(shè)計(jì)中包括一個(gè)消息隊(duì)列，有助于使系統(tǒng)更松散耦合和具有容錯(cuò)性。
2. 包括了日志記錄、監(jiān)控、指標(biāo)和自動(dòng)化工具。

隨著每天數(shù)據(jù)的增長(zhǎng)，您的數(shù)據(jù)庫(kù)負(fù)荷越來(lái)越重。是時(shí)候?qū)?shù)據(jù)層進(jìn)行擴(kuò)展了。

數(shù)據(jù)庫(kù)擴(kuò)展

數(shù)據(jù)庫(kù)擴(kuò)展有兩種主要方法：垂直擴(kuò)展和水平擴(kuò)展。

垂直擴(kuò)展

也稱為縱向擴(kuò)展，是通過(guò)向現(xiàn)有機(jī)器添加更多的性能（CPU、RAM、DISK等）來(lái)進(jìn)行擴(kuò)展。有一些功能強(qiáng)大的數(shù)據(jù)庫(kù)服務(wù)器。根據(jù)亞馬遜關(guān)系數(shù)據(jù)庫(kù)服務(wù)（RDS）[12]，你可以獲得一臺(tái)具有24 TB RAM的數(shù)據(jù)庫(kù)服務(wù)器。這種強(qiáng)大的數(shù)據(jù)庫(kù)服務(wù)器可以存儲(chǔ)和處理大量的數(shù)據(jù)。例如，2013年的stackoverflow.com每月有超過(guò)1000萬(wàn)的獨(dú)立訪問(wèn)者，但它只有1個(gè)主數(shù)據(jù)庫(kù)[13]。然而，垂直擴(kuò)展也存在一些嚴(yán)重的缺點(diǎn)：

• 你可以為數(shù)據(jù)庫(kù)服務(wù)器添加更多的CPU、RAM等，但存在硬件限制。如果你有大量的用戶，單個(gè)服務(wù)器是不夠的。
• 單點(diǎn)故障的風(fēng)險(xiǎn)增加。
• 垂直擴(kuò)展的總體成本較高。強(qiáng)大的服務(wù)器更加昂貴。

水平擴(kuò)展

也稱為分片，是添加更多服務(wù)器的做法。圖1-20比較了垂直擴(kuò)展和水平擴(kuò)展。

分片將大型數(shù)據(jù)庫(kù)分割成更小、更易管理的部分，稱為分片。每個(gè)分片共享相同的模式，盡管每個(gè)分片上的實(shí)際數(shù)據(jù)是唯一的。

圖1-21展示了分片數(shù)據(jù)庫(kù)的示例。用戶數(shù)據(jù)根據(jù)用戶ID分配到數(shù)據(jù)庫(kù)服務(wù)器上。每當(dāng)你訪問(wèn)數(shù)據(jù)時(shí)，都會(huì)使用散列函數(shù)來(lái)找到相應(yīng)的分片。在我們的示例中，user_id % 4被用作散列函數(shù)。如果結(jié)果等于0，則使用分片0來(lái)存儲(chǔ)和獲取數(shù)據(jù)。如果結(jié)果等于1，則使用分片1。其他分片的邏輯也是相同的。

圖1-22展示了分片數(shù)據(jù)庫(kù)中的用戶表。

在實(shí)施分片策略時(shí)，最重要的因素是選擇分片鍵。分片鍵（也稱為分區(qū)鍵）由一個(gè)或多個(gè)列組成，用于確定數(shù)據(jù)的分布方式。如圖1-22所示，“user_id”是分片鍵。分片鍵允許你通過(guò)將數(shù)據(jù)庫(kù)查詢路由到正確的數(shù)據(jù)庫(kù)來(lái)高效地檢索和修改數(shù)據(jù)。在選擇分片鍵時(shí)，最重要的一個(gè)標(biāo)準(zhǔn)是選擇一個(gè)能夠均勻分布數(shù)據(jù)的鍵。

分片是擴(kuò)展數(shù)據(jù)庫(kù)的一種很好的技術(shù)，但遠(yuǎn)非完美的解決方案。它給系統(tǒng)引入了復(fù)雜性和新的挑戰(zhàn)：

重新分片數(shù)據(jù)：當(dāng)1）單個(gè)分片由于快速增長(zhǎng)而無(wú)法再容納更多數(shù)據(jù)時(shí)，需要重新分片數(shù)據(jù)。2）某些分片可能由于不均勻的數(shù)據(jù)分布而更快地耗盡分片。當(dāng)分片耗盡時(shí)，需要更新分片函數(shù)并移動(dòng)數(shù)據(jù)。一種常用的解決此問(wèn)題的技術(shù)是一致性哈希，將在第5章中討論。

熱點(diǎn)鍵問(wèn)題：也稱為明星問(wèn)題。對(duì)特定分片的過(guò)度訪問(wèn)可能導(dǎo)致服務(wù)器超載。想象一下，Katy Perry、Justin Bieber和Lady Gaga的數(shù)據(jù)都最終存儲(chǔ)在同一個(gè)分片上。對(duì)于社交應(yīng)用來(lái)說(shuō)，該分片將被讀操作淹沒(méi)。為了解決這個(gè)問(wèn)題，我們可能需要為每個(gè)名人分配一個(gè)分片。甚至每個(gè)分片可能還需要進(jìn)一步分區(qū)。

連接和去規(guī)范化：一旦數(shù)據(jù)庫(kù)被分片到多個(gè)服務(wù)器上，執(zhí)行跨數(shù)據(jù)庫(kù)分片的連接操作就變得困難。一個(gè)常見的解決方法是對(duì)數(shù)據(jù)庫(kù)進(jìn)行去規(guī)范化，以便可以在單個(gè)表中執(zhí)行查詢。

在圖1-23中，我們對(duì)數(shù)據(jù)庫(kù)進(jìn)行分片以支持快速增長(zhǎng)的數(shù)據(jù)流量。與此同時(shí)，一些非關(guān)系型功能被移到NoSQL數(shù)據(jù)存儲(chǔ)中，以減輕數(shù)據(jù)庫(kù)負(fù)載。這是一篇涵蓋了NoSQL許多使用案例的文章[14]。

超過(guò)數(shù)百萬(wàn)用戶的規(guī)模

系統(tǒng)的擴(kuò)展是一個(gè)迭代的過(guò)程。根據(jù)本章學(xué)到的知識(shí)進(jìn)行迭代可能會(huì)使我們走得更遠(yuǎn)。為了超越數(shù)百萬(wàn)用戶，需要更多的優(yōu)化和新策略。例如，您可能需要優(yōu)化您的系統(tǒng)并將系統(tǒng)解耦為更小的服務(wù)。本章學(xué)到的所有技術(shù)應(yīng)該為應(yīng)對(duì)新的挑戰(zhàn)提供了良好的基礎(chǔ)。為了總結(jié)本章，我們提供了如何擴(kuò)展我們的系統(tǒng)以支持?jǐn)?shù)百萬(wàn)用戶的摘要：

• 保持 Web 層無(wú)狀態(tài)
• 在每個(gè)層面上構(gòu)建冗余性
• 盡可能地緩存數(shù)據(jù)
• 支持多個(gè)數(shù)據(jù)中心
• 在 CDN 中托管靜態(tài)資源
• 通過(guò)分片擴(kuò)展數(shù)據(jù)層
• 將層級(jí)拆分為獨(dú)立的服務(wù)
• 監(jiān)控您的系統(tǒng)并使用自動(dòng)化工具

恭喜您取得了如此大的進(jìn)展！現(xiàn)在給自己一個(gè)鼓勵(lì)。做得好！

AI不會(huì)取代你,使用AI的人會(huì)。歡迎關(guān)注我的公眾號(hào)：更AI。以程序員的視角來(lái)看AI能帶給我們什么~

參考資料

[1] 超文本傳輸協(xié)議（Hypertext Transfer Protocol）: https://zh.wikipedia.org/wiki/超文本傳輸協(xié)議

[2] 你是否應(yīng)該超越關(guān)系型數(shù)據(jù)庫(kù)？:

https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases

[3] 復(fù)制（Replication）: https://zh.wikipedia.org/wiki/復(fù)制_(計(jì)算機(jī))

[4] 多主復(fù)制（Multi-master replication）:

https://zh.wikipedia.org/wiki/多主復(fù)制

[5] NDB 集群復(fù)制：多主和環(huán)形復(fù)制:

https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-replication-multi-master.html

[6] 緩存策略及如何選擇合適的策略:

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

[7] R. Nishtala，“Facebook 的緩存擴(kuò)展”，第十屆 USENIX 網(wǎng)絡(luò)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)研討會(huì)（NSDI '13）。

[8] 單點(diǎn)故障（Single point of failure）: https://zh.wikipedia.org/wiki/單點(diǎn)故障

[9] Amazon CloudFront 動(dòng)態(tài)內(nèi)容傳送:

https://aws.amazon.com/cloudfront/dynamic-content/

[10] 配置經(jīng)典負(fù)載均衡器的黏性會(huì)話:

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

[11] 多區(qū)域容錯(cuò)性的主動(dòng)-主動(dòng)（Active-Active）:

https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b

[12] Amazon EC2 高內(nèi)存實(shí)例:

https://aws.amazon.com/ec2/instance-types/high-memory/

[13] 運(yùn)行 Stack Overflow 的所需條件:

http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow

[14] 你到底在使用 NoSQL 做什么:

http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html

本文翻譯自《System Design Interview: An Insider’s Guide》第一章，如有侵權(quán)，請(qǐng)聯(lián)系本人刪除文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-462251.html

到了這里，關(guān)于系統(tǒng)設(shè)計(jì)：從零用戶擴(kuò)展到百萬(wàn)用戶的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！