系统设计面试问题：设计WhatsApp

ChatGPTer

已于 2024-07-19 10:01:34 修改

阅读量843

点赞数 28

分类专栏：架构设计文章标签：系统架构

于 2024-07-19 10:00:35 首次发布

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/ddnosh/article/details/140540966

版权

14 篇文章 0 订阅

订阅专栏

我的新书《Android App开发入门与实战》已于2020年8月由人民邮电出版社出版，欢迎购买。点击进入详情

在这个系统设计面试场景中，我们被要求设计一个类似于 WhatsApp 的消息应用程序。

虽然真正的面试可能会关注应用程序的一个或多个功能，但在本文中，我们将对系统架构进行概述，然后您可以根据需要更深入地探索特定领域。

明确功能需求

让我们通过向面试官提出一些问题来缩小范围，因为在一小时内设计整个 WhatsApp 平台是不现实的：

规模：首先，我们来谈谈规模，即系统有多大，可以处理多少条消息。假设每天发送的消息量为 100 亿条，我们的目标是在一年内将这一数字翻一番。

可用性：在可用性方面，我们希望系统高度可用且始终可运行。

延迟：至于系统延迟，我们希望它几乎立即发生，因此大多数 API 请求应在 100 毫秒内完成。

每天有 100 亿条消息，我们大约有 100 亿条消息 / 每天 86,400 秒 =每秒 115,740 条消息 (MPS)。一年内翻倍意味着我们应该计划 115,740 * 2 = 231,480 MPS。

假设每条消息 200 字节，则每日存储量为 100 亿条消息 * 200 字节 = 2 兆兆字节 (TB)。每年存储量（含增长）约为 2 TB * 365 天 * 2 = 1.5 PB。

值得注意的是，我们计算的是平均值，但系统需要处理峰值流量，这可能远高于平均 MPS。我们可能需要根据高峰时段进行扩展。

我们可能会使用 RESTful API 样式来实现更广泛的兼容性。以下是可能的端点的细分：

发送消息（POST /messages）：请求正文包含收件人 ID 和消息内容。成功响应 (200) 返回唯一消息标识符。错误代码 (400、500) 处理缺少参数或服务器问题。
检查新消息（GET /messages）：响应为 200（带有未读消息数组）或 204（如果没有未读消息）。
获取特定消息（GET /messages/:messageId）：返回特定消息（200）或 404（如果未找到）。
将消息标记为已读（PUT 或 PATCH /messages/:messageId）：成功响应（200）确认更改，而 404 表示未找到消息。

其他注意事项：我们将集成 WebSockets 以实现实时更新。API 将处理身份验证和初始连接建立。并且可能需要对“检查新消息”端点进行分页。输入验证等安全措施也是必要的。

移动应用程序：用户的主要界面将是移动应用程序（iOS、Android）。此应用程序负责发送和接收消息、联系人管理和对话。

负载均衡器：为了高效处理传入请求，我们将使用负载均衡器在多台服务器之间分配流量。这提高了应用程序的可靠性。

API 服务器：所有请求都将发送到 API 服务器，该服务器处理我们之前概述的 RESTful API，管理消息传递逻辑。API 服务器本身可以是无状态的；这样，我们可以随着流量的增长而水平扩展（添加更多服务器）。

WebSocket 连接：类似 WhatsApp 的应用程序严重依赖 WebSocket 进行实时通信。聊天服务器将与移动应用程序保持持久的 WebSocket 连接。当消息到达时，可以立即将其推送到收件人的设备。

消息分发器：接下来，我们将有一个消息分发器服务，该服务的主要目的是将 API 服务器与直接数据库写入分离，这对于处理高写入量尤为重要。

消息队列（例如 Kafka 或 RabbitMQ）非常适合。其工作原理如下：

数据库（NoSQL）：我们同意最终的一致性是可以接受的，这使得 NoSQL 成为高消息量的可扩展选择。

让我们考虑两个强有力的选择：

Cassandra：宽列存储，以可扩展性、高可用性和写入性能而闻名。如果我们预期写入量较大，且读取模式更简单（主要通过 ID 获取消息），那么这种存储就特别有用。
DynamoDB： AWS 提供的完全托管的键值和文档数据库。如果我们想要一个维护成本低且易于扩展的数据库解决方案，那么它是非常有利的。