需求

让我们设计Facebook的新闻提要，其中包含来自Facebook的帖子、照片、视频和状态更新

 

用户关注的所有人和页面。类似服务：Twitter新闻源、Instagram新闻源、Quora新闻提要

 

难度等级：难

 

1.Facebook的新闻源是什么？

新闻订阅是脸谱网主页中间不断更新的故事列表。它包括状态更新、照片、视频、链接、应用程序活动以及来自用户访问的人员、页面和组的“喜好”。关注Facebook。换句话说，它是一个完整的可滚动版本的来自照片、视频、位置、状态更新和其他活动的朋友和你的生活故事

 

对于你设计的任何社交媒体网站——Twitter、Instagram或Facebook——你都需要一些新闻提要系统显示来自朋友和追随者的更新。

 

2.系统的要求和目标

让我们根据以下要求为Facebook设计一个新闻提要：

 

功能要求：

 

1.新闻提要将基于用户访问的人员、页面和组的帖子生成跟随。

 

2.一个用户可能有很多朋友，并且关注大量页面/组。

 

3.提要可能包含图像、视频或文本。

 

4.我们的服务应支持在所有活动的新闻提要中添加新帖子用户。

 

非功能性要求：

 

1.我们的系统应该能够实时生成任何用户的新闻提要-看到的最大延迟最终用户将是2s。

 

2.假设有一个新的新闻源请求，一篇文章不应该花费超过5秒的时间进入用户的提要进来。

 

3.容量估算和限制条件

让我们假设一个用户平均有300个朋友，关注200个页面。

 

流量估计：

 

假设每天有3亿活跃用户，每个用户都会获取他们的时间线。平均每天五次。这将导致每天15亿个新闻提要请求，约17500个每秒请求数。

 

存储估计：

 

平均而言，假设每个用户的提要中需要大约500篇文章，我们想保留在内存中以便快速获取。我们还假设平均每个帖子大小为1KB。这意味着我们需要为每个用户存储大约500KB的数据。储存所有这些所有活动用户的数据我们需要150 TB的内存。如果一台服务器可以容纳100GB，我们会需要大约1500台机器为所有活跃用户保留内存中的前500篇文章。

 

4.系统API

� 一旦我们确定了需求，定义系统API明确说明系统的期望值。我们可以使用SOAP或RESTAPI来公开服务的功能。以下可能是

 

获取新闻源的API的定义：

 

getUserFeed(api_dev_key, user_id, since_id, count, max_id, exclude_replies)

 

参数：

 

api_dev_key（string）：注册用户的api开发者密钥可用于，根据分配的配额限制用户。

 

user_id（number）：系统将为其生成新闻提要的用户的id。

 

since_id (number):：可选；返回ID高于（即，比）的结果指定ID。

 

count (number):可选；指定要尝试和检索的提要项的数量，最多为每个不同的请求200个。

 

max_id (number):可选；返回ID小于（即早于）或等于指定ID。

 

exclude_replies(boolean):：可选；此参数将阻止回复出现在返回的页面中时间线。

 

Returns: (JSON)）返回包含提要项列表的JSON对象

 

5.数据库设计

有三个主要对象：用户、实体（如页面、组等）和提要（或帖子）。这是关于这些实体之间关系的一些观察结果：

 

•用户可以跟随其他实体并与其他用户成为朋友。

 

•用户和实体都可以发布包含文本、图像或视频的提要。

 

•每个FeedItem都有一个用户ID，该ID将指向创建它的用户。为了简单起见，让我们假设只有用户可以创建提要项目，尽管Facebook页面上可以发布提要我也是。

 

•每个FeedItem可以选择性地具有一个EntityID，该ID指向其所在的页面或组，该职位已创建。

 

如果我们使用的是关系数据库，我们需要建模两种关系：用户-实体关系和用户-实体关系饲料媒体关系。由于每个用户都可以与许多人成为朋友，并关注许多实体，我们可以将此关系存储在单独的表中。“UserFollow”中的“Type”列标识正在跟踪的实体是用户或实体。类似地，我们可以有一个FeedMedia关系表