在你的下一次Facebook面试前练习这些问题!

在过去的几年里，系统设计面试（SDI）已经获得了很多关注。现在所有的软件工程面试都包括这些面试，以评估候选人设计和管理复杂系统的能力。

工程师们通常在SDI中挣扎，部分原因是他们没有开发大规模系统的经验，部分原因是SDI的非结构化性质。即使是有经验的工程师也会发现这些面试令人不安，主要是由于设计问题的开放性，没有标准的答案。

今天我们将讨论在Facebook面试中问到的7大系统设计问题。

Facebook是最大的社交网络服务之一，用户可以分享照片、新闻和基于文本的信息。让我们设计一个可以存储和搜索用户的状态更新的服务。

要求

•    让我们假设Facebook有15亿总用户，8亿日活跃用户。

•    平均而言，Facebook每天有4亿条状态更新。

•    一个状态更新的平均大小是300字节。

•    让我们假设每天会有5亿次搜索。

•    搜索查询将由多个词与AND/OR组合而成。

在高层次上，我们需要将所有的状态更新存储在一个数据库中，同时建立一个索引，可以跟踪哪个词出现在哪个状态更新信息中。这个索引将帮助我们快速找到用户试图搜索的信息。

推特搜索的高层次设计

了解更多关于设计Facebook状态更新搜索。

设计一个类似Instagram的照片分享服务，用户可以上传照片与其他用户分享。

功能要求

1.   用户应该能够上传/下载/查看照片。

2.  用户可以根据照片/视频的标题进行搜索。

3.  用户可以关注其他用户。

4.  系统应该生成并显示用户的新闻提要，其中包括用户所关注的所有人员的好评照片。

非功能要求

1.   我们的服务需要高度可用。

2.  系统可接受的延迟为200ms的新闻递送生成。

3.  如果用户有一段时间没有看到一张照片，一致性可能会受到影响（为了可用性）；应该没有问题。

4.该系统应该是高度可靠的；任何上传的照片或视频都不应该丢失。

在高层次上，我们需要支持两种情况，一种是上传照片，另一种是查看/搜索照片。我们的服务需要一些对象存储服务器来存储照片，需要一些数据库服务器来存储照片的元数据信息。

了解更多关于设计Instagram的信息

设计一个类似于Facebook Messenger的即时通讯服务，用户可以通过网络和手机界面互相发送文字信息。

功能要求：

1.   Messenger应该支持用户之间一对一的对话。

2.  Messenger应该跟踪其用户的在线/离线状态。

3.  Messenger应该支持聊天记录的持久性存储。

 

非功能要求：

1.   用户应该有最低延迟的实时聊天体验。

2.  我们的系统应高度一致；用户应在所有设备上看到相同的聊天记录。

3.  Messenger的高可用性是可取的；为了一致性，我们可以容忍较低的可用性。

 

在高层次上，我们需要一个聊天服务器，它将是精心策划用户之间所有通信的核心部分。例如，当一个用户想给另一个用户发送消息时，他们将连接到聊天服务器，并将消息发送到服务器；然后服务器将该消息传递给另一个用户，同时将其存储在数据库中。

详细的工作流程是这样的：

1.   用户A通过聊天服务器向用户B发送一个消息。

2.  服务器收到该消息并向用户A发送确认。

3.  服务器将消息存储在其数据库中并将消息发送给用户B。

4.  用户B收到消息并向服务器发送确认信息。

5.  服务器通知用户A，消息已经成功地传递给用户B。

发送消息的请求流程

了解更多关于设计Facebook Messenger的信息。

设计Facebook的Newsfeed，它将包含用户关注的所有人物和页面的帖子、照片、视频和状态更新。

功能要求：

1.   将根据用户关注的人、网页和群组的帖子来生成新闻摘要。

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

3.  摘要可能包含图片、视频，或只是文字。

4.  我们的服务应该支持在所有活跃用户的新闻摘要中附加新的帖子。

 

非功能要求：

1.   我们的系统应该能够实时生成任何用户的Newsfeed - 终端用户看到的最大延迟是2秒。

2.  假设有新的Newsfeed，一个帖子不应该超过5秒才会出现在用户的feed上。

 

在高层次上，我们的Newsfeed服务将需要以下组件：

1.   网络服务器。为了保持与用户的连接。这个连接将被用来在用户和服务器之间传输数据。

2.  应用服务器。执行在数据库服务器中存储新文章的工作流程。我们还需要一些应用服务器来检索和推送newsfeed给最终用户。

3.  元数据数据库和缓存。存储关于用户、页面和组的元数据。

4.  帖子数据库和缓冲区。存储关于帖子和其内容的元数据。

5.  视频和照片存储，以及缓存。Blob存储，用于存储帖子中包含的所有媒体。

6.  Newsfeed生成服务。为用户收集和排列所有相关的帖子，以生成newsfeed并存储在缓存中。这项服务也将接收实时更新，并将这些较新的feed项目添加到任何用户的时间线上。

7.  Feed通知服务。通知用户有更新的项目可用于他们的newsfeed。

 

以下是我们系统的高级架构图。用户B和C关注用户A。

脸谱网Newsfeed架构

了解更多关于设计Facebook的Newsfeed。

设计一个网络爬虫，它将系统地浏览和下载World Wide Web。网络爬虫也被称为网络蜘蛛、机器人、蠕虫、步行者和机器人。

要求

让我们假设我们需要在所有的网络爬行。

可伸缩性：我们的服务需要具有可伸缩性，以便它能够在整个网络爬行，并可用于找来数以亿计的网络文件。

可扩展性：我们的服务应该以模块化的方式设计，并期望新的功能能添加进去。未来可能会有更加新的文件类型需要被下载和处理。

高级别的解决方案

一个最基本的爬虫至少需要这些组件。

1. URL前沿阵地。存储要下载的URL列表，并优先考虑哪些URL应该首先爬行。

2. HTML取样器：从服务器上检索网页。

3. 提取器：从HTML文档中提取链接。

4. 重复消除器。确保同一内容不会被无意中提取两次。

5. 数据存储。存储检索到的页面、URL和其他元数据。

了解更多关于设计网络爬虫的信息。

设计一个类似Yelp的服务，用户可以搜索附近的地方，如餐馆，剧院，或商场等，还可以添加/查看地方的评论。

功能要求：

1.   用户应该能够添加/删除/更新地方。

2.  鉴于他们的位置（经度/纬度），用户应该能够在给定的半径内找到所有附近的地方。

3.  用户应该能够添加关于一个地方的反馈/评论。反馈可以有图片、文字和评级。

非功能要求:

1.   用户应该有一个最低延迟的实时搜索体验。

2.  我们的服务应该支持大量的搜索负载。与增加一个新地方相比，会有大量的搜索请求。

在高层次上，我们需要存储和索引上述的每个数据集（地方、评论等）。对于用户查询这个庞大的数据库，指标化应该是有效的，因为在搜索附近的地方时，用户希望能实时看到结果。

鉴于一个地方的位置并不经常改变，我们不需要担心数据的频繁更新。作为对比，如果我们打算建立一个对象确实经常改变其位置的服务，例如，人或出租车，那么我们可能会想出一个非常不同的设计。

了解更多关于设计Yelp或附近的朋友。

7. 设计Ticketmaster

设计一个像Ticketmaster或BookMyShow那样销售电影票的在线售票系统。

功能要求：

1.   我们的订票服务应该能够列出其附属电影院所在的不同城市。

2.  一旦用户选择了城市，该服务应该显示在该特定城市发行的电影。

3.  一旦用户选择了一部电影，该服务应该显示播放该电影的电影院和其可用的放映时间。

4.  用户应该能够在特定的电影院选择一个节目，并预订他们的票。

5.  该服务应该能够向用户显示电影院大厅的座位安排。用户应该能够根据自己的喜好选择多人座位。

6.  用户应该能够区分可用座位和已预订的座位。

7.  用户应该能够在付款完成预订之前将座位搁置5分钟。

8.  如果有机会获得座位，用户应该能够等待，例如，当其他用户的持有过期时。

9.  应以公平、先到先得的方式为等待的顾客提供服务。

 

非功能要求：

1.   该系统将需要高度的并发性。在任何特定的时间点上，都会有对同一座位的多个预订请求。该服务应该优雅地、公平地处理这个问题。

2.  服务的核心内容是订票，这意味着金融交易。这意味着系统应该是安全的，数据库应该符合ACID标准。

在高层次上，我们的网络服务器将管理用户的访客量，而应用服务器将处理所有的票据管理，在数据库中存储数据，以及与缓存服务器合作处理预订。