媒体社交网络服务系统的目的

该系统将允许用户与其他用户共享照片和视频。此外，用户可以根据关注请求关注其他用户，他们可以看到其他用户的照片和视频。在此系统中，您可以搜索用户并查看他们的个人资料（如果他们的帐户是公开的）。否则，您需要发送关注请求。 

在开始设计任何系统，如照片和视频共享社交网络服务系统之前，建议详细考虑系统边界和需求，并尝试了解未来（如 5 年或 10 年）的系统容量。至关重要，因为在某些时候，如果系统的用户数量呈指数增长，系统的容量将不足以提供快速响应。在建筑设计背后，你必须考虑一些支柱。这些是;

   – 可用性 

   – 可靠性 

   – 弹性 

   – 耐用性 

   – 性价比

这些是我们应该一起考虑的支柱，因为它们是相互耦合的。简而言之，可用性意味着系统应该始终可用。可靠性意味着系统应该按预期工作。弹性意味着如果出现任何问题，系统将如何以及何时恢复自身。持久性是系统的每个部分都应该存在的支柱，直到我们删除为止。性价比也是一个重要的话题，基本上与成本效率下的使用服务有关。可以这样说明，如果系统将构建在 AWS 上并且使用 t2 微型 EC2 实例就足够了，那么就没有任何理由使用更大的 EC2 实例并支付额外费用。

需求

和系统边界 如果你想设计一个系统，你必须首先定义需求和系统边界。可能您将拥有一份服务设计文档，并且您将在此服务设计文档中定义需求、边界、架构决策和其他内容。但基本上，照片和视频共享社交网络系统将是用户可以与其他用户共享图像和视频的服务。用户可以拥有公共或私人帐户，这意味着如果您拥有公共帐户，您的图像/视频将对其他用户可见（无论您是否有关系）。但是，如果您有私人帐户，那么您的图像/视频将仅对您的朋友可见。所以你的系统会支持这些功能；

   – 用户必须能够创建帐户。 

   – 每个注册用户都必须有自己的个人账户页面。 

   – 用户必须能够登录系统和退出系统。 

   – 用户必须能够在他们的时间线中看到其他用户的照片和视频。 

   – 用户登录后必须能够上传照片和视频。 

   – 用户登录后必须能够删除他们的照片和视频。 

   – 用户必须能够搜索用户。 

   – 系统必须能够支持公共和私人帐户。 

   – 用户必须能够向其他用户发送关注请求。 

   – 用户必须能够接受或拒绝关注请求。 

   – 用户必须能够在需要时删除他们的帐户。 

   – 用户必须能够像其他用户的照片和视频一样。

   – 系统应该是高度可用的 

   – 系统应该是高度可靠的 

   – 系统应该是持久 的

   – 系统应该是有弹性 的

   – 系统应该是高成本和性能效率

的 当定义了系统边界和功能要求时，需要考虑云或在线承诺选项。你的系统可以；

   – %100 on-promise（您自己的数据中心/服务器） 

   – %100 云（AWS、Google Cloud、Azure） 

   – on-promise 和云的混合（您可以在迁移过程中同时

拥有）由于云机制的优势而大受欢迎。这些优势；

   – 成本效率 

   – 高速 

   – 安全 

   – 备份解决方案 

   – 无限存储容量 

   – 许多不同的服务选项。您无需从头开始创建世界 

   – 可靠性 

   – 耐用性 

   – 弹性 

   – 监控几乎所有服务 

   – 与其他服务的轻松软件集成 

   – 来自云提供商的维护等等……

让我们考虑一下设计边界；

   – 服务将是写入繁重和读取繁重的。 

   – 服务将保持一致和可靠，这意味着不应该有任何数据丢失。– 服务将是持久的，这意味着所有系统都应该存在，直到它们被手动删除。

在定义容量考虑之前，您必须定义服务的目的是什么。即使它对于 on-promise 服务更重要，但它对于 on-promise 和云服务都是必不可少的，因为您可以根据目的选择正确的服务，根据可用区域定位它们并定义容量。这样的例子是；

   – 创建比写服务更多的读服务。 

   – 根据操作类型选择服务器类型。 

   – 根据您的容量估计定义缓存策略。 

   – 根据您的要求选择数据库类型（SQL、NoSQL）。 

   – 根据您的容量估计定义备份解决方案。 

   – 根据您的要求等定义数据分片策略……

假设您的用户总数为 1 亿。在您的系统中，我们假设下载数据比上传数据重，假设读写的比例为 10:3。

我们将假设照片的平均大小为 200 KB，视频的平均大小为 25 MB，因此系统将具有；

5年内的照片容量；

   – 5 * 100M * 10 * 200KB = 1 PB。（假设每个用户每年上传 10 张照片）。 

   – 12PB 用于复制和备份。

使照片的总容量在 5 年内达到 3 PB。

5年内视频容量；

   – 5 * 100M * 1 * 25 MB = 12 PB。（假设每个用户每年会上传 1 个视频）。 

   – 36 PB 用于复制和备份。

此计算只是如何定义系统容量的简单示例，我们不会计算每日下载/上传容量和元数据容量，但您应该考虑此计算（以及每日读取/写入容量估计）以进行服务/数据库扩展。

API 设计

我们可以使用 REST 或 SOAP 来提供我们的 API。基本上，将有照片和视频共享服务系统的三个重要API。

   1- PostMedia (api_dev_key, media_type, media_data, title, description, tags[], media_details)

PostMedia 将负责上传照片或图片。api_dev_key 是注册账号的 API 开发者密钥。我们可以使用 api_dev_key 消除黑客攻击。此 API 返回 HTTP 响应。（如果成功则接受 202）

   2- GetMedia (api_dev_key, media_type, search_query, user_location, page, maximum_video_count = 20) 

     返回包含有关照片和视频列表信息的 JSON。每个媒体资源都会有一个标题、创建日期、喜欢计数、总观看次数、所有者和其他元信息。

   3- DeleteMedia (api_dev_key, ID, type) 

     检查用户是否有权删除媒体。如果操作已排队，它将返回 HTTP 响应 200（OK）、202（已接受），或者根据您的响应返回 204（无内容）。

**设计照片和视频共享服务的 API 比较多，但是这三个 API 比其他 API 更重要。其他 API 会像媒体、搜索、推荐等……

数据库架构

您可以将数据库部分考虑为两部分。第一部分将涉及如何以安全的方式保存图像/视频，第二部分将涉及如何将图像/视频元数据和用户信息/用户关系数据保存在数据库中。视频和图像是静态数据，因此您可以将图像/视频保存在图像存储中。您可以使用 Chromecast 等 3rd 方服务，或者如果您使用 AWS，您可以将真实媒体文件存储在 S3 上。S3 将根据您的策略提供不同类型的存储。为了说明这一点，S3 将提供 S3 标准、s3 不频繁访问、S3 Glacier 等……如果我们认为对于 Instagram，我们可以开始使用 S3 标准来保存图像/视频，如果它们在今年上传，第一年之后我们可以移动它们不经常访问 S3，10 年后我们可以将它们移至 S3 Glacier。这使得系统具有成本效益，因为即使 S3 标准是 AWS 中最便宜的服务之一，S3 不频繁访问也比 S3 标准便宜。此外，我们 S3 Standard 和 S3 Infrequently access 会自动将数据保存在不同的可用区域（如数据中心）中，这样您就不必担心可靠性。但是最好将镜像数据（复制）保留在不同的区域以增加数据冗余。此外，最好使用 Cloudfront 作为分布式缓存层来减少读取/访问时间。Cloudfront 是一种分布式 AWS 缓存服务，位于不同的边缘位置。您可以同时使用 cloudfront 读取和写入选项。此外，我们 S3 Standard 和 S3 Infrequently access 会自动将数据保存在不同的可用区域（如数据中心）中，这样您就不必担心可靠性。但是最好将镜像数据（复制）保留在不同的区域以增加数据冗余。此外，最好使用 Cloudfront 作为分布式缓存层来减少读取/访问时间。Cloudfront 是一种分布式 AWS 缓存服务，位于不同的边缘位置。您可以同时使用 cloudfront 读取和写入选项。此外，我们 S3 Standard 和 S3 Infrequently access 会自动将数据保存在不同的可用区域（如数据中心）中，这样您就不必担心可靠性。但是最好将镜像数据（复制）保留在不同的区域以增加数据冗余。此外，最好使用 Cloudfront 作为分布式缓存层来减少读取/访问时间。Cloudfront 是一种分布式 AWS 缓存服务，位于不同的边缘位置。您可以同时使用 cloudfront 读取和写入选项。Cloudfront 是一种分布式 AWS 缓存服务，位于不同的边缘位置。您可以同时使用 cloudfront 读取和写入选项。Cloudfront 是一种分布式 AWS 缓存服务，位于不同的边缘位置。您可以同时使用 cloudfront 读取和写入选项。

对于用户，您可以同时使用 RDBMS 或 NoSQL。我们可以使用图形数据库，这样用户之间就会有很强的关系。AWS Neptune 或 Neo4j 可以是用于此目的的合适数据库。在 MySQL 或 PostgreSQL 上设计；

用户： 

USERID： INT 

NICKNAME： NVARCHAR(50) 

密码： VARCHAR(255) with Hash function 

EMAIL： NVARCHAR(50) 

BIRTHDATE： DATETIME 

REGISTERDATE： DATETIME 

LASTLOGINDATE： DATETIME

主键： USERID

UserRelations 

ID： INT 

FOLLOWERID： INT 

FOLLOWINGID： INT

Primary键：ID 

外键：FOLLOWERID、FOLLOWINGID 和用户表

对于发布元数据，您可以使用 RDBMS，如 MySQL 或 PostgreSQL。

帖子 

编号：INT 

USERID：INT 

MEDIA_TYPE_ID：INT 

PATH：NVARCHAR(100) 

描述：文本 可见性

：BOOLEAN 

ADDEDDATE：DATETIME 

VIEWS_COUNT：INT

主键：ID 

外键：USERID 和用户表 

外键：MEDIA_TYPE_ID 和 Media_Type 表

主键：(ID, TYPE) 

外键：MEDIAID 与媒体表

UserLike 

ID：INT 

MEDIAID：INT 

USERID：INT

主键：ID 

外键：USERID 与用户表 

外键：MEDIAID 与媒体表

评论 

ID：INT 

MEDIAID：INT 

USERID：INT 

COMMENT：NVARCHAR（256 )

主键：ID 

外键：带有用户表的 USERID 

外键：带有媒体表的 MEDIAID

当然我们会有更多的数据库表，这些只是示例。遵循数据库设计过程的规范化规则会很好。 

   ** 我们将在 AWS S3 中存储照片/视频。我们也可以使用 S3 生命周期规则来提高成本效率。 

   ** 我们可以使用Cassandra，基于列的数据存储，来保存用户的后续。 

   注意：很多 NoSQL 数据库都支持复制。 

   注意：我们可以在 Media Table – ADDEDDATE 字段上创建一个二级索引，因为我们需要获取最新的媒体文件。

系统设计考虑

   ——下载媒体文件时，系统将具有缓存机制以快速响应。 

   – 系统最终将保持一致，但我们将有缓存驱逐策略来清理缓存。 

   - 系统将有推送通知机制向用户发送信息（比如用户喜欢照片/视频）。 

   – 系统将 Cloudfront 作为 CDN。Cloudfront 位于 EDGE 位置，因此响应时间会很快。我们可以使用 Cloudfront 进行下载和上传。 

   – 系统将使用 NGinx 作为负载均衡器，我们将实施智能路由算法以仅发送健康服务的请求。 

   – 系统将有预先生成的服务来为用户创建时间线。 

   – 系统将保留多个数据和文件。（复制、备份） 

   ——系统会有监控机制。如果系统组件发生故障，系统将根据警报考虑发送警报 

   ——系统将支持代码管道机制。我们可以使用 AWS Codecommit、Codebuild、CodeDeploy 和 CodePipeline。

高级系统设计

如果我们正在设计一个系统，我们需要的基本概念是；

   – 客户端 

   – 服务 

   – Web 服务器 

   – 应用程序服务器 

   – 媒体文件存储 

   – 数据库 

   – 缓存 

   – 复制 

   – 冗余 

   – 负载均衡 

   –

分片 该系统中有两个独立的服务，即上传/下载媒体。媒体存储用于保存静态媒体内容。数据库用于保存有关用户和媒体内容的所有元数据。当请求到达系统时，它会首先到达 Web 服务器。Web 服务器将传入请求重定向到应用程序服务器。

复制和备份是我们之前提到的提供支柱的两个重要概念。复制是处理服务或服务器故障的一个非常重要的概念。复制可以应用于数据库服务器、Web 服务器、应用程序服务器、媒体存储等。实际上我们可以复制系统的所有部分。（某些 AWS 服务，例如 Route53，它们本身就具有高可用性，因此您无需处理 Route53、负载均衡器等的复制。）请注意，复制还有助于系统减少响应时间。你想象一下，如果我们将传入的请求分成更多的资源而不是一个资源，系统可以轻松满足所有传入的请求。此外，每个资源的最佳副本数为 3 个或更多。 

对于缓存策略，我们可以通过使用缓存服务器来使用全局缓存机制。我们可以使用 Redis 或 memcache，但缓存策略最重要的部分是如何提供缓存驱逐。如果我们使用全局缓存服务器，我们将保证每个用户将在缓存中看到相同的数据，但如果我们使用全局缓存服务器，则会有时间延迟。作为缓存策略，我们可以使用 LRU（最近最少使用）算法。

对于媒体文件缓存，正如我们之前提到的，我们将使用 CDN。CDN 位于不同的边缘位置，因此响应时间将小于直接从 AWS S3 获取媒体内容。 

在这种服务中分片 ID 总是很困难，因为会有大量数据，但你可以检查；

a href="https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c/">

负载均衡器允许根据某些标准将传入请求重定向到资源。我们可以在系统的每一层使用负载均衡器。如果我们想使用 AWS 负载均衡器服务，AWS 将支持三种不同的负载均衡器类型：

   – 网络负载均衡器 

   – 经典负载均衡器（已弃用） 

   – 应用程序负载均衡器

对于此服务，应用程序负载均衡器将适合我们的服务，它还将自行处理可用区分布。否则你可以使用 NGinx，但你必须实现算法，如果我们想使用 NGinx，你必须提供维护。

我们可以使用负载均衡器； 

   – 在请求和 Web 服务器之间。 

   – 在 Web 服务器和应用程序服务器之间。 

   – 应用服务器和数据库 

   之间 – 应用服务器和图像存储之间。 

   – 应用服务器和缓存数据库之间。 

   – 我们可以对负载均衡器使用循环方法。Round Robin 方法防止请求进入死服务器，但 Round Robin 方法不处理任何服务器处于高流量状态的情况。我们可以修改 Round Robin 方法，使其成为一种更智能的方法来处理这个问题。