初始阶段:基础版本
需求: 初始要求是处理50万用户和3000万首歌曲。我们将有播放歌曲的用户和上传歌曲的艺术家。
![null 5037fafa17998c2f1a3d662b99deb185.png](https://i-blog.csdnimg.cn/blog_migrate/44299776d67896af0cd265cd5ec6a39c.png)
估算:数据计算
让我们从估算我们需要的存储开始。首先,我们需要将歌曲存储在某种存储中。
•歌曲存储: Spotify等服务通常使用Ogg Vorbis或AAC等格式进行流媒体传输,假设平均歌曲大小为3MB,我们需要3MB * 3000万 = 90TB的存储空间用于歌曲。•歌曲元数据: 我们还需要存储歌曲元数据和用户配置文件信息。每首歌平均的元数据大小约为100字节 — 100字节 * 3000万 = 3GB•用户元数据: 平均而言,我们将每个用户存储1KB的数据 — 1KB * 50万 = 0.5GB
![null 62850f3fe4845dacee9b92fb468feaeb.png](https://i-blog.csdnimg.cn/blog_migrate/298b4a9c874f9e5a5e97a80213dd1bcc.png)
高级设计
移动应用: 我们将有一个移动应用,是用户与服务互动的前端。用户可以搜索歌曲,播放音乐,创建播放列表等。当用户执行操作(如播放歌曲)时,应用程序将发送请求到后端服务器。
负载均衡器: 但在到达服务器之前,我们有一个负载均衡器,用于在多个web服务器之间分发传入流量。这提高了应用程序的可用性和容错性。
![null dc1156ae7f4c852dd4e2a536b2368f45.png](https://i-blog.csdnimg.cn/blog_migrate/3e1eb85c7204762ff97eedc8299f7be4.png)
Web服务器(API): Web服务器是处理移动应用程序发来的请求的API。例如,如果用户想播放一首歌,请求将发送到这些Web服务器。服务器然后确定歌曲的位置(在数据库或存储服务中)以及如何检索它。
数据存储
数据存储将分为两个独立的服务 — 歌曲的Blob存储,我们将在其中存储实际的歌曲文件,以及SQL数据库,我们将在其中存储歌曲和用户元数据。
![null 72707ad989cabdc8fe1c4e1fa3f4e7ec.png](https://i-blog.csdnimg.cn/blog_migrate/de142d6f52abbb1d856558902010f1e9.png)
歌曲 — Blob存储(例如AWS S3、GCP、Azure Blob存储): 实际的歌曲文件存储在Blob(二进制大对象)存储服务中。这些服务设计用于存储大量非结构化数据。
用户、艺术家和歌曲元数据 — SQL数据库: 该SQL数据库存储结构化数据,如用户信息(如用户名、密码和电子邮件地址)以及关于歌曲的元数据(如歌曲名称、艺术家名称、专辑详细信息等)。
为什么使用SQL?SQL数据库非常适合这种类型的结构化数据,因为它们允许进行复杂的查询和不同类型数据之间的关系。
每个歌曲文件都存储为“blob”,而SQL数据库通常存储对此文件的引用(如URL)。
SQL数据库结构
以下是我们SQL数据库中表及其关系的基本大纲:
我们将需要一个用户表,其中包含用户元数据,如UserID、Username、Email、PasswordHash、CreatedAt、LastLogin等。
![null 67270ae224231141e41cd3bd9d595468.png](https://i-blog.csdnimg.cn/blog_migrate/fc6467a6839180eba5b952627b5ab906.png)
歌曲表将保存歌曲的元数据信息,例如SongID、Title、ArtistID、Duration、ReleaseDate和FileURL,即指向歌曲文件存储位置的URL(例如在blob存储中)。
艺术家表将包含艺术家信息 — ArtistID、Name、Bio、Country等。
关系: 我们将在艺术家歌曲表中连接艺术家和歌曲表,其中将有**ArtistID**
(指向艺术家表的外键)和**SongID**
(指向歌曲表的外键)。从那里,我们可以获取歌曲元数据,其中还将包含指向歌曲所在的Blob存储的**FileURL**
属性。
将所有内容整合
![null 848571fcfb457a0a23f9497a365d3d0a.png](https://i-blog.csdnimg.cn/blog_migrate/b01c11e20cfaf4418d0686601bea8d92.png)
因此,Web服务器将从SQL数据库获取歌曲元数据,从中获取fileURL
,然后将其分块流式传输到移动应用程序。或者我们可以直接从对象存储流式传输到客户端,绕过Web服务器以减轻负载。
扩展阶段:5000万用户,2亿首歌曲
现在如果我们扩展到5000万用户和2亿首歌曲呢?我们首先需要重新计算数据。这意味着SQL数据存储需要存储200/30 = 约6.66倍的歌曲元数据:
每首歌100字节 * 2亿首歌 = 20GB
用户元数据也是如此:
每个用户1KB * 5000万用户 = 50GB
![null 0e19266e6df405523ba6716905b4b097.png](https://i-blog.csdnimg.cn/blog_migrate/fe3d3864c1a49fab749f67910b1d0e48.png)
引入CDN
由于流量增加 — 我们需要引入缓存和CDN(如Cloudfront / Cloudflare)来提供歌曲,每个CDN将在地理上接近一个区域;因此,它可以比Web服务器更快地提供歌曲。
![null d794d5369fcb1995ba883cdb4f9133a7.png](https://i-blog.csdnimg.cn/blog_migrate/ce43989305ab61c9c1a90f228f1dd5d8.png)
我们可以使用LRU(Least Recently Used)淘汰策略缓存热门歌曲,而不热门的歌曲仍然将从Blob存储中获取,然后缓存在CDN中。
歌曲文件还可以直接从云存储流式传输到客户端,这将减轻Web服务器的负载。
扩展数据库:领导者-跟随者技术
数据库也需要扩展。由于我们知道我们的应用程序获得的读取次数比写入次数多,也就是有很多用户听歌曲,但相对较少的艺术家上传歌曲 — 我们可以使用领导者 → 跟随者技术,有一个领导者数据库负责接受读取和写入,以及多个跟随者或从数据库仅用于检索歌曲和用户元数据。
![null 4ecfac98bf1a7a9551433277c0146db7.png](https://i-blog.csdnimg.cn/blog_migrate/6dd6405040e95cd6e5da9b1e9696fe61.png)