來源：小技術君

初始階段：基礎版本

需求: 初始要求是處理50萬使用者和3000萬首歌曲。我們將有播放歌曲的使用者和上傳歌曲的藝術家。

估算：資料計算

讓我們從估算我們需要的儲存開始。首先，我們需要將歌曲儲存在某種儲存中。

•歌曲儲存： Spotify等服務通常使用Ogg Vorbis或AAC等格式進行流媒體傳輸，假設平均歌曲大小為3MB，我們需要3MB * 3000萬 = 90TB的儲存空間用於歌曲。•歌曲後設資料： 我們還需要儲存歌曲後設資料和使用者配置檔案資訊。每首歌平均的後設資料大小約為100位元組 — 100位元組 * 3000萬 = 3GB•使用者後設資料： 平均而言，我們將每個使用者儲存1KB的資料 — 1KB * 50萬 = 0.5GB

高階設計

移動應用： 我們將有一個移動應用，是使用者與服務互動的前端。使用者可以搜尋歌曲，播放音樂，建立播放列表等。當使用者執行操作（如播放歌曲）時，應用程式將傳送請求到後端伺服器。

負載均衡器： 但在到達伺服器之前，我們有一個負載均衡器，用於在多個web伺服器之間分發傳入流量。這提高了應用程式的可用性和容錯性。

Web伺服器（API）： Web伺服器是處理移動應用程式發來的請求的API。例如，如果使用者想播放一首歌，請求將傳送到這些Web伺服器。伺服器然後確定歌曲的位置（在資料庫或儲存服務中）以及如何檢索它。

資料儲存

資料儲存將分為兩個獨立的服務 — 歌曲的Blob儲存，我們將在其中儲存實際的歌曲檔案，以及SQL資料庫，我們將在其中儲存歌曲和使用者後設資料。

歌曲 — Blob儲存（例如AWS S3、GCP、Azure Blob儲存）： 實際的歌曲檔案儲存在Blob（二進位制大物件）儲存服務中。這些服務設計用於儲存大量非結構化資料。

使用者、藝術家和歌曲後設資料 — SQL資料庫： 該SQL資料庫儲存結構化資料，如使用者資訊（如使用者名稱、密碼和電子郵件地址）以及關於歌曲的後設資料（如歌曲名稱、藝術家名稱、專輯詳細資訊等）。

為什麼使用SQL？SQL資料庫非常適合這種型別的結構化資料，因為它們允許進行復雜的查詢和不同型別資料之間的關係。

每個歌曲檔案都儲存為“blob”，而SQL資料庫通常儲存對此檔案的引用（如URL）。

SQL資料庫結構

以下是我們SQL資料庫中表及其關係的基本大綱：

我們將需要一個使用者表，其中包含使用者後設資料，如UserID、Username、Email、PasswordHash、CreatedAt、LastLogin等。

歌曲表將儲存歌曲的後設資料資訊，例如SongID、Title、ArtistID、Duration、ReleaseDate和FileURL，即指向歌曲檔案儲存位置的URL（例如在blob儲存中）。

藝術家表將包含藝術家資訊 — ArtistID、Name、Bio、Country等。

關係： 我們將在藝術家歌曲表中連線藝術家和歌曲表，其中將有**ArtistID**（指向藝術家表的外來鍵）和**SongID**（指向歌曲表的外來鍵）。從那裡，我們可以獲取歌曲後設資料，其中還將包含指向歌曲所在的Blob儲存的**FileURL**屬性。

將所有內容整合

因此，Web伺服器將從SQL資料庫獲取歌曲後設資料，從中獲取fileURL，然後將其分塊流式傳輸到移動應用程式。或者我們可以直接從物件儲存流式傳輸到客戶端，繞過Web伺服器以減輕負載。

擴充套件階段：5000萬使用者，2億首歌曲

現在如果我們擴充套件到5000萬使用者和2億首歌曲呢？我們首先需要重新計算資料。這意味著SQL資料儲存需要儲存200/30 = 約6.66倍的歌曲後設資料：

每首歌100位元組 * 2億首歌 = 20GB

使用者後設資料也是如此：

每個使用者1KB * 5000萬使用者 = 50GB

引入CDN

由於流量增加 — 我們需要引入快取和CDN（如Cloudfront / Cloudflare）來提供歌曲，每個CDN將在地理上接近一個區域；因此，它可以比Web伺服器更快地提供歌曲。

我們可以使用LRU（Least Recently Used）淘汰策略快取熱門歌曲，而不熱門的歌曲仍然將從Blob儲存中獲取，然後快取在CDN中。

歌曲檔案還可以直接從雲端儲存流式傳輸到客戶端，這將減輕Web伺服器的負載。

擴充套件資料庫：領導者-跟隨者技術

資料庫也需要擴充套件。由於我們知道我們的應用程式獲得的讀取次數比寫入次數多，也就是有很多使用者聽歌曲，但相對較少的藝術家上傳歌曲 — 我們可以使用領導者 → 跟隨者技術，有一個領導者資料庫負責接受讀取和寫入，以及多個跟隨者或從資料庫僅用於檢索歌曲和使用者後設資料。