首页 > Java > java教程 > WhatsApp 系统设计:高层和低层架构的幽默之旅

WhatsApp 系统设计:高层和低层架构的幽默之旅

Patricia Arquette
发布: 2024-11-15 10:22:02
原创
707 人浏览过

WhatsApp System Design: A Humorous Journey Through High-Level and Low-Level Architecture

欢迎来到 WhatsApp 系统设计的奇妙而混乱的世界!本文不仅会揭开 WhatsApp 的高层(HLD)和低层(LLD)架构的神秘面纱,还会加入一些幽默(因为系统设计并不一定很无聊!)并为您绘制一些图表(因为我们所有喜欢流程图)。

所以,系好安全带,喝杯咖啡,让我们开始一段旅程,服务器、数据库和消息协议联合起来,将数十亿条消息传送到您的手机上。

目录:

  1. 高层架构(HLD)
  2. 底层架构(LLD)
  3. 流程图:设计英雄
  4. 核心组件分解
  5. 为什么要使用这些组件?
  6. 有趣的事实和 WhatsApp 特定优化

1. 高层架构(HLD):大局

将 WhatsApp 想象成一首精心编排的交响乐,但我们有服务器而不是小提琴,我们有数据库而不是大提琴。在较高层面上,我们正在设计一个支持以下功能的系统:

  • 数十亿用户
  • 实时消息
  • 多媒体分享
  • 端到端加密
  • 高可用性和低延迟(没有人喜欢等待“打字...”)

HLD概述:

在HLD,我们像建筑师一样思考。您还不关心每个窗户的形状 - 您只想确保房子不会倒塌。

从 30,000 英尺的高度来看,WhatsApp 的架构包括:

  • 客户端应用程序(iOS、Android、Web)
  • API 网关
  • 负载均衡器(平衡数百万条消息的混乱)
  • 应用程序服务器(奇迹发生的地方)
  • 数据库层(因为数据必须存放在某个地方)
  • 文件存储(对于那些猫 GIF)
  • 消息队列(类似 Kafka 的实时消息传递系统)
  • 通知服务器(当你喜欢的人回复时一定要让你知道)

HLD的核心要素:

  1. 客户端应用程序: WhatsApp 适用于移动(iOS/Android)、网络和桌面应用程序,所有这些应用程序都连接到相同的后端服务器。客户端负责 UI/UX、发送/接收消息、加密/解密(我们稍后会介绍)以及当您的 Wi-Fi 决定休息一下时重新连接。
  2. API 网关: 这是处理来自客户端的请求并将其转发到适当的后端服务的中间人。 API 网关检查您是否经过正确身份验证,记录您的消息请求,并将您发送到正确的服务器。
  3. 负载均衡器: 拥有数百万在线用户,您需要一名(或两名)管弦乐团指挥来确保没有一台服务器被淹没。负载均衡器在许多应用程序服务器之间分配请求,这可以防止过载并使速度变得超级快。
  4. 应用程序服务器: 这些坏孩子是 WhatsApp 的大脑。它们处理消息、管理用户会话并执行加密。这里的关键是可扩展性;如果有更多用户加入,我们会添加更多服务器。
  5. 数据库层: 您所有的消息和媒体都去哪里了?这就是数据库的用武之地:
    • NoSQL 数据库 (Cassandra):用于存储大规模数据,如用户配置文件、消息历史记录等
    • SQL 数据库:在极少数情况下,需要关系数据(例如财务记录)。
  6. 文件存储: 您的所有照片、视频和语音笔记都存储在可扩展的分布式文件存储系统中。想想 S3(但 WhatsApp 可能构建了一些定制的东西——因为它们很酷)。
  7. 消息队列(Kafka/Redis): 对于实时消息传递,WhatsApp 使用消息队列来处理跨不同服务器的消息传递。如果用户离线,消息将存储在队列中,直到他们回来为止。
  8. 通知服务器: 当您的手机屏幕关闭时,WhatsApp 会通过 APNs(Apple 推送通知服务)和适用于 Android 的 Firebase Cloud Messaging 等服务发送通知。

HLD流程图:

以下是可视化 WhatsApp 中客户端、后端服务和数据库之间交互的基本流程图:

                   +---------------+               +--------------+
Client (Mobile) -->| API Gateway    |---> LB --->   | Application  |
(Client (Web)) --> | (Rate limiting)|               | Servers      |
                   +---------------+               +--------------+
                           |                             |
                           |                             |
                           V                             V
                    +-------------+               +--------------+
                    | Message     |               | Notification |
                    | Queues      |               | Servers      |
                    +-------------+               +--------------+
                           |
                           V
                   +---------------+
                   |   Databases    | (Cassandra, File Storage)
                   +---------------+

登录后复制
登录后复制

2. 底层架构(LLD):本质细节

在LLD中,我们专注于各个组件的实现和技术细节。这是我们深入研究算法、数据库分片、加密方法和网络协议的地方。

LLD 的关键概念:

  1. 消息传递系统
    • WhatsApp 使用 XMPP 协议进行实时消息传递。这是一种轻量级、高效的协议,可以处理一对一和群组消息传递。
    • 如果收件人离线,消息会被临时存储,并在收件人上线后传送。
  2. 端到端加密:
    WhatsApp 的端到端加密基于信号协议。这个想法很简单但很天才:

    • 每条消息都有自己独特的加密密钥。
    • WhatsApp 和任何第三方都无法读取您的消息,因为只有发件人和收件人持有必要的密钥。

    如果 WhatsApp 是一本间谍小说,那么如果错误的人试图阅读它,该消息就会自毁!

  3. 数据存储和复制:

    • Cassandra(NoSQL 数据库)用于存储聊天消息。为什么?它是分布式的、高度可用的,并且可以处理跨多个数据中心的复制。 Cassandra 确保即使服务器崩溃(当服务器决定需要小睡时发生这种情况),数据也不会丢失。
    • 媒体文件(如图片和视频)与短信分开存储,通常存储在基于云的文件存储系统中。
  4. 处理离线用户:

    • 如果您发送消息而收件人离线,则消息将使用 Kafka/Redis 等系统进行排队。这就像当某人不在家时在他们的门上留下一张纸条,只不过这张纸条被安全地藏在队列中。
  5. 数据库分片:

    • WhatsApp 拥有数百万用户,无法将每个人的数据存储在一个庞大的数据库中。这就像试图将世界上所有人都装进一部电梯一样。
    • 相反,WhatsApp 对数据库进行分片。分片就像将电梯分成一百个较小的电梯,每个电梯负责自己的用户组。

LLD流程图:

这是一个简化的 LLD 流程图,重点关注实时消息传递和消息队列:

                   +---------------+               +--------------+
Client (Mobile) -->| API Gateway    |---> LB --->   | Application  |
(Client (Web)) --> | (Rate limiting)|               | Servers      |
                   +---------------+               +--------------+
                           |                             |
                           |                             |
                           V                             V
                    +-------------+               +--------------+
                    | Message     |               | Notification |
                    | Queues      |               | Servers      |
                    +-------------+               +--------------+
                           |
                           V
                   +---------------+
                   |   Databases    | (Cassandra, File Storage)
                   +---------------+

登录后复制
登录后复制

3. 流程图:我们的设计英雄

让我们添加一些图表以使事情变得更加清晰。将流程图想象成建筑师的蓝图;它们帮助我们直观地理解系统。

消息发送流程:

      +------------------+   Send Message   +-------------------+
      | Client App        |---------------->| API Gateway        |
      +------------------+                  +-------------------+
                  |                                  |
                  |         Authenticate User        |
                  V                                  V
          +----------------+                 +------------------+
          | Message Queue   |  <--Store Msg---| Application      |
          | (Kafka/Redis)   |                 | Servers (XMPP)   |
          +----------------+                 +------------------+
                       |                               |
                       |   Offline/Store Msg            |
                       |------------------------------->
                       V
                +-------------+
                |   Database   | (Sharded Cassandra, File Storage)
                +-------------+

登录后复制

消息检索流程:

Client (Mobile App)
     |
     V
API Gateway  --->  Authenticate ---> Forward to Application Server
     |
     V
Load Balancer ---> Routes to Least Busy Server
     |
     V
Message Queue ---> Holds the message if the user is offline
     |
     V
Database ---> Saves the message for future retrieval

登录后复制

4. 核心组件分解

让我们更详细地分解一些关键组件:

  • XMPP:用于发送和接收实时消息的消息协议。
  • Kafka/Redis:负责在接收者离线时对消息进行排队。
  • Cassandra:存储消息、用户数据和聊天历史记录的 NoSQL 数据库。
  • 信号协议:为消息隐私提供端到端加密。
  • 分片:将数据库划分为更小、更易于管理的部分,以处理数百万用户。

5. 为什么使用这些组件?

为什么是卡桑德拉?

  • 由于 WhatsApp 需要高可用性、低延迟以及处理多个位置的分布式数据库的能力,因此 Cassandra 是完美的选择。另外,它的设计永不宕机,WhatsApp 非常喜欢这种可靠性。

为什么选择XMPP?

  • XMPP 轻量级、高效,专为实时消息传递而设计。非常适合您不能迟到的系统,例如告诉您的朋友电影 5 分钟后开始。

为什么选择卡夫卡/Redis?

  • 消息队列可确保消息不会丢失,即使收件人在没有 Wi-Fi 的区域度假也是如此。 Kafka 和 Redis 可靠、快速且可扩展。

为什么使用信号协议进行加密?

  • WhatsApp 不想阅读您的消息(我保证)。通过端到端加密,他们实际上无法读取它们,因为只有您和您的收件人拥有密钥。

6. 有趣的事实和 WhatsApp 特定优化

  1. 多设备支持:WhatsApp 允许用户在多个设备上使用同一帐户。这需要仔细的会话管理和消息同步。
  2. 高效媒体存储:WhatsApp 通过对不同聊天中共享的相同媒体文件进行重复数据删除来优化媒体存储(因为我们都有一个朋友向每个群组发送相同的表情包)。

结论:将所有内容整合在一起

现在您已经了解了 WhatsApp 的系统设计之旅!我们探索了高层架构(HLD),深入研究了底层设计(LLD),甚至加入了一些幽默,让旅程变得有趣。从 XMPP 协议到 Kafka 队列、Cassandra 数据库和 Signal 加密,WhatsApp 是可扩展的实时消息传递的杰作,让我们的群聊保持活力!

以上是WhatsApp 系统设计:高层和低层架构的幽默之旅的详细内容。更多信息请关注PHP中文网其他相关文章!

来源:dev.to
本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
作者最新文章
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板