当前位置：首页 > news >正文

系统设计案例：设计 Spotify

news 文章来源：https://blog.csdn.net/weixin_44008788/article/details/144850502 2025/5/18 22:31:11

https://levelup.gitconnected.com/system-design-interview-question-design-spotify-4a8a79697dda

这是一道系统设计面试题，即设计 Spotify。在真正的面试中，你通常会关注应用程序的一两个主要功能，但在本文中，我想从高层次概述如何设计这样的系统，然后你可以根据需要深入研究每个单独的部分。

初始阶段：基础版本

要求：最初的要求是处理**50 万用户和 30M 首歌曲。我们将有播放歌曲的用户和上传歌曲的艺术家。

估算：数据数学

让我们先估算一下所需的存储空间。首先，我们需要将歌曲存储在某种存储空间中。

歌曲存储： Spotify 和类似的服务通常使用 Ogg Vorbis 或 AAC 等格式进行流媒体播放，假设平均歌曲大小为 3MB，则我们需要3MB * 3000 万 = 90TB的歌曲存储空间。
歌曲元数据： 我们还需要存储歌曲元数据和用户个人资料信息。每首歌曲的平均元数据大小约为 100 字节 — 100 字节 * 3000 万 = 3GB
用户元数据： 平均而言，我们将为每个用户存储 1KB 的数据 - 1KB * 500,000 = 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 数据库中表及其关系的基本概述：

我们需要一个包含用户元数据（如用户 ID、用户名、电子邮件、密码哈希、CreatedAt、LastLogin 等）的用户表。

歌曲表将保存歌曲元数据信息，例如 SongID、Title、ArtistID、Duration、ReleaseDate 和 FileURL，后者是歌曲文件存储位置的 URL（例如，在 Blob 存储中）。

艺术家表 将包含艺术家信息——艺术家 ID、姓名、简历、国家等。

关系： 我们将在ArtistsSongs 表中连接 Artists 和 Songs 表，其中我们将拥有ArtistID（指向 Artists 表的外键）和SongID（指向 Songs 表的外键）。从那里，我们可以获取歌曲元数据，其中还将包含FileURL指向歌曲所在的Blob 存储的属性。

综合起来

因此，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（最近最少使用）驱逐策略来缓存热门歌曲，而不受欢迎的歌曲仍将从 Blob 存储中获取，然后缓存到 CDN。

歌曲文件还可以直接从云存储传输到客户端，这将减轻网络服务器的负载。

扩展数据库：领导者-追随者技术

数据库也需要扩展。因为我们知道我们的应用程序的读取次数比写入次数多得多，这意味着有很多用户在听歌，但上传歌曲的艺术家数量相对较少——我们可以使用Leader → Follower 技术，并拥有一个可以同时接受读取/写入的 Leader 数据库和多个Follower 或 Slave 数据库，这些数据库将是只读的，用于检索歌曲和用户元数据。

如果有必要的话，我们也可以实现数据库分片，拆分成多个SQL数据库，或者实现Leader↔Leader的技术，但这些是比较复杂的场景，你不会遇到面试时问得太深这个方面的问题。