系统设计面试问题：如何设计 Spotify，一个音乐流媒体系统

• 分析系统的功能需求、用户量以及数据量
• 设计系统的高层架构，包括移动应用程序、负载均衡器、Web 服务器、数据存储等组件
• 选择合适的存储结构，包括 Blob 存储和 SQL 数据库，并设计数据表和关系
• 根据系统的扩展需求，引入 CDN、缓存、数据库复制等技术，提高系统性能

初始预估

在这个阶段，我们假设系统需要处理 50 万用户和 3000 万首歌曲。我们将有播放歌曲的用户和上传歌曲的艺术家。

数据估计

我们首先估计我们需要的存储空间。我们需要将歌曲存储在某种存储中，以及存储歌曲元数据和用户元数据。我们假设：

• 歌曲存储：Spotify 和类似服务通常使用 Ogg Vorbis 或 AAC 等格式进行流式传输，平均歌曲大小为 3MB
• 歌曲元数据：每首歌曲的平均元数据大小约为 100 字节
• 用户元数据：平均而言，我们将为每个用户存储 1KB 的数据

根据这些假设，我们可以计算出我们需要的存储空间：

系统架构

我们的系统由以下几个组件组成：

移动应用程序：这是用户与服务交互的前端。用户可以搜索歌曲、播放音乐、创建播放列表等。当用户执行操作（例如播放歌曲）时，应用程序会向后端服务器发送请求。

负载均衡器：这是一个中间层，它将传入的流量分配到多个 Web 服务器上。这提高了我们的应用程序的可用性和容错能力。

Web 服务器 (API) ：这是处理来自移动应用程序的请求的 API 层。例如，如果用户想要播放歌曲，请求就会发送到这些网络服务器。然后，服务器确定歌曲所在的位置（在数据库或存储服务中）以及如何检索它。

存储结构

数据存储将分为两个独立的服务 - 歌曲的 Blob 存储（我们将在其中存储实际的歌曲文件）和 SQL 数据库（我们将在其中存储歌曲和用户元数据）。

歌曲 - Blob 存储：这是一个用于存储实际的歌曲文件的 Blob（二进制大对象）存储服务。这些服务旨在存储大量非结构化数据。我们可以使用一些云服务提供商的 Blob 存储服务，例如 AWS S3、GCP、Azure Blob 存储等。

用户、艺术家和歌曲元数据 — SQL 数据库：这是一个用于存储结构化数据的 SQL 数据库服务。这些数据包括用户信息（如用户名、密码和电子邮件地址）和歌曲元数据（如歌曲名称、艺术家姓名、专辑详细信息等）。我们可以使用一些关系型数据库管理系统，例如 MySQL、PostgreSQL、Oracle 等。

为什么用户、艺术家和歌曲元数据选择用 SQL 数据库？因为 SQL 数据库非常适合此类结构化数据，因为它们允许复杂的查询以及不同类型数据之间的关系。

每个歌曲文件都存储为“blob”，SQL 数据库通常会存储对此文件的访问连接（如 URL）。

表结构设计

我们的表结构设计由以下几个部分组成：

• 歌曲 - Blob 存储：每个歌曲文件都存储为一个“blob”，它有一个唯一的标识符和一个 URL，指向它在 Blob 存储中的位置。我们可以使用这个 URL 来访问和下载歌曲文件。
• 用户、艺术家和歌曲元数据 - SQL 数据库：我们在 SQL 数据库中创建了以下几个表来存储结构化数据：
  • Users：这个表包含了用户的元数据，如 UserID、Username、Email、PasswordHash、CreatedAt、LastLogin 等。
  • Songs：这个表包含了歌曲的元数据，如 SongID、Title、ArtistID、Duration、ReleaseDate 和 FileURL。FileURL 是歌曲文件在 Blob 存储中的 URL，我们可以使用它来访问和下载歌曲文件。
  • Artists：这个表包含了艺术家的信息，如 ArtistID、Name、Bio、Country 等。
  • ArtistsSongs：这是一个连接表，它建立了 Artists 和 Songs 表之间的多对多关系。它包含了 ArtistID（指向 Artists 表的外键）和 SongID（指向 Songs 表的外键）。

播放歌曲

当我们存储结构设计好以后，我们就可以进行播放歌曲的操作了。

当用户想要播放一首歌曲时，移动应用程序会向 Web 服务器发送一个请求，包含歌曲的 ID。Web 服务器会从 SQL 数据库中查询歌曲的元数据，包括 FileURL。然后，Web 服务器会使用 FileURL 从 Blob 存储中获取歌曲文件，并将其逐块流式传输到移动应用程序。

或者我们可以直接将 FileURL 返回给移动应用程序，让它从 Blob 存储中直接下载歌曲文件，从而减少 Web 服务器的负载。

系统扩展

当系统处于规模化阶段，我们假设系统需要处理 5000 万用户和 2 亿首歌曲。我们需要重新计算数据，引入缓存和 CDN，以及扩展数据库。

数据估计

我们需要重新计算我们需要的存储空间。我们需要将歌曲存储在某种存储中，以及存储歌曲元数据和用户元数据。我们假设：

• 歌曲存储：Spotify 和类似服务通常使用 Ogg Vorbis 或 AAC 等格式进行流式传输，平均歌曲大小为 3MB
• 歌曲元数据：每首歌曲的平均元数据大小约为 100 字节
• 用户元数据：平均而言，我们将为每个用户存储 1KB 的数据

根据这些假设，我们可以计算出我们需要的存储空间：

接下来，我们的系统架构与初始阶段相比，有以下几个变化。

引入 CDN

由于流量增加，我们需要引入缓存和 CDN（如 Cloudfront / Cloudflare）来提供歌曲，并且每个 CDN 在地理位置上都将靠近一个区域。因此它可以比我们原有的 web 服务器更快地提供歌曲。

并且我们可以使用 LRU（最近最少使用）驱逐策略来缓存流行歌曲，不流行的歌曲仍然会从 Blob 存储中获取，然后缓存到 CDN。歌曲文件还可以直接从云存储传输到客户端，这将减少网络服务器的负载。

扩展数据库

数据库也需要扩展。由于我们知道我们的应用程序的读取次数多于写入次数，这意味着有很多用户在听歌曲，但上传歌曲的艺术家数量相对较少。

我们可以搭建数据库主从，将用户的读操作和写操作分开，当用户检索歌曲和元数据时请求会到达从数据库，当用户上传歌曲时，请求会到达主数据库。通过读写分离，我们可以提高应用程序的歌曲播放速度。

总结一下

我们给大家介绍了如何设计一个类似 Spotify 的音乐流媒体系统，从基础版本到规模化阶段，我们都给出了合理的方案和估计。我们的设计具有以下优点：

• 可用性高：我们使用了负载均衡器、CDN、缓存和数据库复制等技术，来保证我们的系统在高流量下仍然可以正常运行，并且能够应对故障和异常情况。
• 性能好：我们使用了 Blob 存储和 SQL 数据库来分别存储非结构化和结构化数据，并且优化了数据操作和传输的效率，使得用户可以快速地搜索和播放歌曲。
• 扩展性强：我们的系统可以根据用户量和数据量的增长，动态地调整存储和计算资源，以满足不同的需求和场景。

当然我们的设计也有一些地方没有阐述，大家可以自己研究，

• 数据一致性：由于我们使用了数据库复制和缓存等技术，我们的系统可能会出现数据不一致的情况，例如，当一个艺术家更新了一首歌曲的元数据时，用户可能会看到不同的版本，取决于他们访问的是哪个数据库或缓存节点。
• 数据安全性：由于我们的系统涉及到用户和艺术家的敏感信息，例如密码、电子邮件、歌曲版权等，我们需要保证这些数据的安全性，防止被泄露或篡改。我们需要使用一些加密和身份验证等技术，来保护我们的数据和服务。
• 数据分析：由于我们的系统收集了大量的用户和歌曲的数据，我们可以利用这些数据进行一些数据分析和挖掘，例如，推荐系统、用户画像、歌曲分类等。这些功能可以提高我们的系统的价值和用户体验，但也需要额外的存储和计算资源。

如果觉得这篇文章写的不错的话，不妨点赞加关注，我会更新更多技术干货、项目教学、经验分享的文章。