初始阶段：基础版本

需求: 初始要求是处理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服务器的负载。

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

数据库也需要扩展。由于我们知道我们的应用程序获得的读取次数比写入次数多，也就是有很多用户听歌曲，但相对较少的艺术家上传歌曲 — 我们可以使用领导者 → 跟随者技术，有一个领导者数据库负责接受读取和写入，以及多个跟随者或从数据库仅用于检索歌曲和用户元数据。