Twitter 系统设计面试示例

披露：本文包含 affiliate 链接；如果您通过本文提供的不同链接购买产品或服务，我可能会获得一定的报酬。

感谢 - Sandeep/CodeKarle

大家好，如果你正在准备系统设计面试，并且在寻找常见的系统设计问题和资源，那么你来对地方了。

在过去，我讨论过一些重要的系统设计概念，比如API Gateway 和 Load Balancer 的区别和水平扩展与垂直扩展的区别，Forward Proxy 和 Reverse Proxy 的区别，以及常见的系统设计问题。今天，我将讨论一个流行的系统设计问题——设计 Twitter 或 X.com。

设计像Twitter这样的复杂系统可能会很有挑战性，特别是在系统设计面试中。

最大的挑战不是复杂性而是时间，你需要在40分钟内说服面试官你确实具备相关知识，这只有在你准备充分并采用结构化的方法回答这些问题时才有可能实现。

在这篇系统设计教程中，我还将给你一个简单的指南，帮助你构建系统设计模板（见下文），以整理你的思路并呈现一个清晰的设计。

顺便说一下，如果你正在准备系统设计面试，并希望在有限的时间内学习系统设计，你可以查看一些网站，如ByteByteGo，DesignGurus.io，Exponent，Educative.io，Codemia.io 和 Udemy，这些网站上有许多优秀的系统设计课程。

同样，在回答系统设计问题时，你也可以遵循一个系统设计模板，例如从DesignGurus.io提供的模板，以便在有限的时间内更好地表达你的答案。

遵循这个模板是为任何系统设计面试做准备的最好方法之一。

现在，让我们进入问题和解决方案。

设计一个像 Twitter 一样的系统是系统设计面试中的常见场景，但如果你想从头开始练习这个问题，你可以在 Codemia.io 上开始，这是一个类似于 LeetCode 的系统设计面试平台。

它包含超过120多个系统设计问题并且还在增长，其中包括设计Twitter。它还提供了由知名公司高级工程师创建的编辑解决方案。

它也有一些免费的系统设计问题，设计Twitter是 就是其中之一。你可以在这里访问它。

现在回到问题本身，这是一个很好的方式来展示你对大规模分布式系统的理解，因为它涉及到了处理大量用户、确保高可用性以及在高负载下保持稳定等各个方面。

本解决方案指南将带你逐步设计Twitter，涵盖系统需求、容量估算、API设计、数据库设计、高层次设计、请求流程、详细组件设计、权衡以及潜在的故障场景。

到本指南结束时，你将对如何在面试中阐述这种设计有一个扎实的理解。

这里有一个Twitter架构图，以获得整体概念：

正如我说的，我们将一步步解决这个问题，并且我们会涵盖：

1. 需求

2. 容量估算

3. 每秒查询数（QPS）

4. API 设计

5. 数据库设计

6. 表

7. 存储

8. 高级设计

9. 组件详细设计

10. 故障场景和瓶颈

11. 权衡取舍

所以，我们在等什么，让我们开始吧。

首先你应该正确理解需求，这从功能需求开始。

如果你要克隆一个真实的 app，比如在亚马逊上购物或在 Facebook 或 Twitter 上发送消息，选择你最熟悉的那个。

功能需求

为了设计一个健壮且用户友好的类似Twitter的系统，我们需要概述核心功能。

用户应该能够撰写和分享推文，这是平台的主要功能。

这包括创建一条新推文，附带可选的媒体内容，并与他们的关注者分享。此外，用户还应该能够关注其他用户，以便在他们的动态中看到对方的更新。

这意味着管理用户关注的用户列表，并确保这些用户的推文出现在用户的动态时间线中。

另一个重要功能是允许用户收藏推文，以此表达他们的喜爱，并可能将这些推文作为将来参考的书签。

以下是供您参考的关键功能需求：

1. 发布和分享推文：用户应该能够创建和分享推文。
2. 关注用户：用户应该能够关注其他用户并查看他们的更新。
3. 收藏推文：用户应该能够收藏推文以表示赞赏。

非功能性需求

对于像Twitter这样规模的平台，非功能性需求至关重要。可扩展性是首要的，因为系统必须在不降低性能的情况下处理大量的用户、推文和互动。

高可用性确保平台即使在高峰流量时段或硬件故障情况下也能保持可访问和正常运行。

稳定性是另一个关键方面，服务必须可靠，最大限度地减少停机时间，并保持一致的性能，即使在高并发情况下也是如此。

这里是你在面试中应该提到的关键非功能性需求：

1. 可扩展性：系统应能够处理大量用户、推文和互动。
2. 高可用性：系统应在高流量情况下仍保持可用。
3. 稳定性：系统应稳定且可访问，不会频繁出现问题或停机。

估算用户基数是理解系统规模的第一步。对于这个设计，我们假设用户基数为5亿。这有助于我们评估预期的负载以及支持如此多用户所需的基础设施。

用户基数

• 假设用户基数为5亿。

流量
为了了解日常运营情况，我们需要估算流量。假设每个用户每天发一条推文，我们可以预计每天有5亿条推文。

此外，如果每个用户每天查看其主页 feed 的 10 页，这将导致大量的读取操作。

跟随关系也增加了复杂性，每个用户平均跟随100个其他用户，导致了50亿条跟随关系。

最后，如果每个用户每天收藏5条推文，那么我们每天将有25亿次收藏操作。

这里是你应该考虑或提及的关键流量需求：

• 推文 : 每天5亿条推文（每位用户每天一条推文）。
• 主页推送 : 每位用户每天查看10页。
• 关注 : 每位用户平均关注100位其他用户，导致500亿条关注关系。

• 收藏 : 每位用户每天收藏5条推文，导致每天25亿条收藏。

• • *

每秒查询数 (QPS)

将这些操作分解为每秒查询数（QPS），有助于我们理解实时负载。

对于写操作，我们估算每秒查询率为15k次，对于读操作约为75k次每秒，对于收藏操作大约为30k次每秒。

这些数字有助于规划所需的基础设施和负载均衡策略。

• 写 : (\frac{500M \times 2}{3600 \times 24} \approx 15k) QPS
• 读 : (\frac{500M \times 10}{3600 \times 24} \approx 75k) QPS

• 收藏 : (\frac{500M \times 5}{3600 \times 24} \approx 30k) QPS

• • *

数据大小

理解数据量对于存储规划至关重要。每天有5亿条推文，每条推文在考虑编码后平均为300字节，这相当于每天新增140GB的数据，或每年50TB的数据。

对于媒体内容，如果我们假设它的大小是推文的100倍，那么每天会产生10TB的数据，或者每年会产生4PB的数据。

这一估计强调了分布式存储架构的必要性。

• 推文：每天5亿条推文，每条推文140字符（每条300字节）。这相当于每天140GB，每年50TB。

• 媒体（图片/视频）：假设推文大小的100倍，每天10TB，每年4PB。

• • *

现在，让我们来谈谈API设计，这是系统设计面试中的另一个重要领域：

发布推文

发布推文的API需要高效地处理推文的创建和发布。这包括捕获用户信息、推文内容、位置数据和时间戳。适当的错误处理和验证对于确保顺畅的用户体验至关重要。

    public Result postTweet(Long userId, String tweetText, String location, DateTime date);

进入全屏模式 退出全屏模式

接下来

以下功能需要API来管理用户之间的关系。这包括关注和取消关注用户，确保数据完整性，并及时更新用户的关注列表。

    public Result followUser(Long userId, Long followedUserId);\
    public Result unfollowUser(Long userId, Long followedUserId);

进入全屏模式 退出全屏模式

收藏夹

API 用于收藏，允许用户点赞或取消点赞推文。这些操作应该高效，通过适当的索引和错误处理来确保收藏更新快速且每条推文的收藏数准确。

    public Result favoriteTweet(Long userId, Long tweetId);\
    public Result unfavoriteTweet(Long userId, Long tweetId);

进入全屏模式 退出全屏模式

推文渲染API对于从关注的用户那里获取和显示推文至关重要。这需要高效的查询和分页，以确保加载速度快，用户体验流畅。

    public Result getFeeds(Long userId, String location, int pageNo);

进入全屏模式 退出全屏模式

在设计API之后，让我们来谈谈数据库设计

表格

数据库设计包括定义用户、推文和关注关系的表。UserInfo表存储用户详情，Tweets表处理推文内容和元数据，Follower表管理关注关系。适当的索引对于快速查找和更新至关重要。

• 用户信息表

• userId (主键)

• userName

• status

• otherProfile (头像, 年龄等)

• 推文表

• tweetId (主键)

• userId (索引)

• content

• postTime (索引)

• modifyTime

• status

• 关注表

• userId

• followerId (索引)

• followedTime

这里有一个简单的ERD图，帮助更好地理解Twitter架构的模式：

选择合适的存储解决方案至关重要。对于像用户资料和推文这样的结构化数据，MySQL 是一个不错的选择，因为它支持复杂的查询和事务。

对于媒体存储，Amazon S3 提供了可扩展且成本效益高的图片和视频存储服务。

• 使用 MySQL 存储结构化数据（用户、推文、关注关系）。

• 使用 Amazon S3 存储媒体文件（图片和视频）。

• • *

让我们先来看一下高层次的设计：

客户端层

客户端层涉及网站和应用程序向服务器发送请求。这些请求通过负载均衡器分发，以确保负载均衡和高可用性。使用CDN来分发静态文件有助于减少延迟并提高加载速度。

• 客户端（网站/应用）向服务器发送请求。
• 请求通过负载均衡器进行分发。
• 使用速率限制器来保护后端服务器。
• 使用 CDN 来分发静态文件（图片、视频）。

服务器层

客户端层涉及网站和应用程序向服务器发送请求。这些请求通过负载均衡器分发，以确保负载均衡和高可用性。

使用 CDN 来分发静态文件有助于减少延迟并提高加载速度。

• 服务器集群处理请求和不同的服务：
• Tweet Service：发布推文。
• User Service：用户注册和资料管理。
• Follow Service：关注/取消关注用户。
• Home Feed Service：渲染用户动态。

数据层

数据层涉及使用 Redis 缓存数据以提高响应速度，并使用主从架构的 MySQL 进行持久化存储，以确保一致性和可用性。Amazon S3 用于存储媒体文件，确保可扩展性和持久性。

• 使用 Redis 进行缓存以提高响应速度。
• 使用主从架构的 MySQL 来保证数据一致性和可用性。
• 使用 Amazon S3 存储媒体文件。

请求流程

解释请求流程有助于理解不同组件之间的交互。当客户端发送请求时，请求首先到达负载均衡器，负载均衡器将其分发到合适的服务器。

服务器处理请求，更新数据库，并缓存必要的数据。对于读取请求，数据从缓存或数据库中获取，媒体文件从CDN获取，确保快速响应时间。

1. 客户端向负载均衡器发送请求。
2. 负载均衡器将请求分发到服务器。
3. 限流器检查流量。
4. 服务器处理请求，并将数据存储在MySQL和Redis中。
5. 媒体文件存储在CDN中。
6. 对于读取请求，服务器从CDN中获取文件，并从Redis或MySQL中获取数据。

这里有一个很好的mermaid图，有助于更好地理解Twitter架构中的请求流程。当我通过Codemia.io练习系统设计问题时，我也使用他们的界面创建这样的mermaid图。

现在，让我们来看看设计Twitter时可以使用的详细组件设计和各种软件架构组件。

负载均衡器

在集群中部署多个负载均衡器可以确保高可用性和负载均衡。

在不同位置放置负载均衡器可以减少用户的延迟，而使用如轮询或最少连接数等不同算法有助于高效地管理负载。

• 在集群中部署多个负载均衡器。
• 将负载均衡器放置在不同的位置以减少延迟。
• 使用如轮询、最少连接或IP哈希等算法。

如果你不知道什么是负载均衡器，这里有一个来自DesignGurus.io的示意图，这是我最喜欢的学习系统设计的网站之一：

CDN

使用 CDN 分发静态内容可以减轻源服务器的负载并提高用户的加载速度。优化缓存规则和调整 TTL 可以提高缓存命中率，确保内容快速提供。

• 同时使用拉取缓存和推送缓存的方法。
• 优化缓存规则和TTL以实现更高的缓存命中率。

• 通过添加更多的服务器节点来扩展系统。

• • *

Redis

使用 Redis 进行缓存涉及设置 Redis 集群以实现可扩展性，并采用主从复制来保证高可用性。Sentinel 监控集群并处理故障转移，确保即使在节点故障期间缓存仍然可用。

• 使用 Redis 集群处理大规模数据。
• 采用主从复制以实现高可用性。

• 使用 Sentinel 监控集群并处理故障转移。

• • *

MySQL

MySQL 的主从架构支持高流量，并通过复制确保数据一致性。水平分区帮助将负载分布在多个服务器上，高效处理大规模数据集。

• 使用主从架构处理高流量。

• 使用水平分区处理更多数据。

• • *

这可能是系统设计面试中最重要的部分，因为你将不得不解释你的选择和所做权衡以及它们如何帮助解决问题。让我们来看一下：

数据库

选择使用 MySQL 而不是 NoSQL 是因为需要支持复杂的查询和事务。虽然 NoSQL 提供了模式灵活性，但它缺乏对结构化数据和复杂事务的支持，而这对于 Twitter 的商业模式是必不可少的。

• 选择了 MySQL 而不是 NoSQL，因为需要支持复杂的查询和事务处理。

缓存

Redis 相比 Memcached 更受欢迎，因为它支持多种数据类型和水平扩展。虽然 Memcached 在基本的键值存储方面效率很高，但 Redis 提供了更高级的功能和更好的可扩展性，使其适合大规模系统。

我选择了 Redis 而不是 Memcached，因为它具有更先进的功能和水平扩展能力。

现在，让我们看看我们的系统有多健壮和可靠

混合模型

为了处理关注很多账户的用户，可以结合使用拉取和推送的混合模型来减少延迟。对于关注很多人的情况，推送新推文可以减少聚合动态时的负载，从而改善用户体验。

• 如果一个用户关注了很多用户，结合拉取和推送模型来减少延迟。

阅读热点

处理读热点，例如拥有大量粉丝的热门用户，可以通过在 Redis 中缓存他们的推文，并使用缓存旁路策略来保证一致性。在 Redis 服务器中添加热点区域并使用本地缓存可以分发负载，避免对同一服务器进行过多的调用。

• 使用缓存旁路策略将热数据缓存到 Redis 中。
• 使用本地缓存来处理高流量。

未来改进

未来的改进包括实现多区域主动-主动策略以应对灾难恢复和高可用性。

在多个地点部署带有自动故障转移和负载均衡的服务集群和数据库集群，确保没有单点故障，保持服务的连续性和可靠性。

• 实现多区域主主策略以应对灾难并保证高可用性。

• 继续优化缓存、负载均衡和数据存储策略以应对未来增长。

• • *

如果你正在准备系统设计面试，并且在寻找最好的资源，那么这里有一份精选的 最佳系统设计书籍、在线课程和实践网站 列表，你可以参考这些资源来更好地准备系统设计面试。这些课程中的大多数也回答了我在这里分享的问题。

1. DesignGuru 的系统设计课程: 一个互动学习平台，通过动手练习和真实世界场景来加强你的系统设计技能。

2. Codemia.io: 这是另一个很好的平台，可以用来练习面试中的系统设计问题。它提供了超过120多个系统设计问题，其中许多是免费的，并且有一个合理的结构来解决这些问题。

3. ByteByteGo: 由 Alex Xu 编写的用于系统设计面试准备的实时书籍和课程。它包含了《系统设计面试》第一卷和第二卷的所有内容，并将随着即将推出的第三卷进行更新。

4. Exponent: 一个专门用于面试准备的网站，特别是针对亚马逊和谷歌等FAANG公司。他们还提供了一个很棒的系统设计课程和其他许多可以帮助你通过FAANG面试的材料。

5. 《系统设计面试》by Alex Xu: 这本书提供了对系统设计概念、策略以及面试准备技巧的深入探讨。

6. 《设计数据密集型应用》 作者 Martin Kleppmann：一本全面的指南，涵盖了设计可扩展和可靠系统的原则和实践。

7. LeetCode 系统设计标签: LeetCode 是一个流行的面试准备平台。LeetCode 上的系统设计标签包括各种练习题。

8. "系统设计入门" 在 GitHub 上：一份精选的资源列表，包括文章、书籍和视频，帮助你为系统设计面试做准备。

9. Educative 的系统设计课程: 一个互动学习平台，通过实战练习和真实场景来增强你的系统设计技能。

10. High Scalability 博客：一个博客，包含关于高流量网站和可扩展系统架构的文章和案例研究。

11. YouTube 频道: 可以关注像 "Gaurav Sen" 和 "Tech Dummies" 这样的频道，它们提供了关于系统设计概念和面试准备的深入视频。

图片来源 --- ByteByteGo

记得通过参与实际项目和模拟面试来结合理论知识和实际应用。

持续练习和学习将给你系统设计面试的信心。

这便是关于如何在系统设计面试中设计类似Twitter或X.com的系统的所有内容。通过遵循此结构，你可以设计出一个类似Twitter的强大且可扩展的系统。此指南将帮助你在系统设计面试中有效地展示你的设计。

祝你在系统设计面试中一切顺利