企业官网建设流程全解析

system-design-notes：邮件接收流程深度解析，DNS MX记录查找全图解

【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insider's Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes

system-design-notes是《System Design Interview - An Insider's Guide》一书的配套笔记，其中第 23 章 23. Distributed Email Service/README.md 以 Gmail 为原型设计了一个支持 10 亿用户的分布式邮件服务。本文将带你用图解方式吃透邮件接收流程的 10 个关键步骤，并完整拆解DNS MX 记录查找这一邮件跨服务器投递的核心机制，是新手入门分布式系统设计的优质教程 📬。

先看懂全局：分布式邮件系统高层架构

在深入邮件接收流程之前，先建立全局视角。一个现代分布式邮件服务通常由 Web 服务、实时推送服务和多层存储组成：


各核心组件职责一目了然：

相比传统邮件服务器把邮件存成本地文件（磁盘 I/O 是瓶颈，且无法保证高可用）：


分布式架构通过消息队列、对象存储与多级存储层，同时满足了可靠性、可用性与可扩展性要求。

DNS MX记录查找怎么做：邮件跨服务器投递的秘密

邮件能"找到"对方服务器，靠的是 DNS 中的MX（Mail Exchanger）记录。以 Alice 给 Bob 发信为例，传统邮件服务器的投递路径如下：


流程共 4 步：

1. Alice 在 Outlook 客户端点"发送"，邮件通过SMTP协议送到 Outlook 邮件服务器；
2. Outlook 服务器向 DNS 查询gmail.com的MX 记录，找到对端邮件服务器后，再通过 SMTP 转交邮件；
3. Gmail 的 SMTP 服务器将邮件存入本地 Storage；
4. Bob 通过IMAP/POP协议从服务器拉取邮件（IMAP 保留在服务端，POP 取走后删除）。

那 MX 记录到底长什么样？书中给出了用nslookup实际查询gmail.com的截图：


从图中可以看到关键信息：

• 一个域名会配置多条 MX 记录（如mail2.gsmtp-in.l.google.com、mail1.gsmtp-in.l.google.com），实现多服务器冗余；
• 每条记录带一个优先级数字（图中为 20、30、40、5、10），数字越小优先级越高；
• 发送方服务器优先连接优先级最高（数字最小）的服务器，不可达时自动降级尝试下一优先级——这正是邮件投递具备容错能力的底层保障。

💡 补充：邮件附件以 Base64 编码传输，多数邮件服务限制 25MB；另外想让自己的邮件不被判为垃圾邮件，还需要配置 SPF、DKIM 等邮件认证技术（详见原文"Email deliverability"一节）。

邮件接收流程10步图解深度解析

现在进入核心：一封入站邮件如何进入用户的收件箱？下面是完整的邮件接收流程：


按图中编号逐步拆解 🧐：

步骤 ①②：入口与分发

• 入站邮件到达SMTP 负载均衡器，负载均衡器将邮件分发到某台 SMTP 服务器；
• SMTP 服务器执行邮件接受策略（Email Acceptance Policy，EAP），非法邮件在此直接丢弃，第一时间挡住垃圾流量。

步骤 ③：大附件分流

• 如果邮件附件过大，SMTP 服务器会直接把它写入对象存储（Object Store），邮件主体只保留引用，避免后续链路被大文件拖垮。

步骤 ④⑤：异步化缓冲

• 通过检查的邮件进入Incoming email queue（入站邮件队列）；
• Mail processing workers从队列中拉取邮件，削峰填谷，保证突发流量下系统不雪崩。

步骤 ⑥：安全检测与存储落盘

• 邮件处理服务执行垃圾邮件检查和病毒检查（含 Retry 重试机制）；
• 检测通过后，邮件被同时写入存储层的四个目标：元数据库（Metadata）、搜索存储（Search store）、对象存储（附件）、分布式缓存（近期邮件）。

步骤 ⑦⑧⑨⑩：触达用户

• 邮件处理服务把新邮件通知推给Real-time Servers，实时服务器通过WebSocket推送给在线的 Webmail（步骤⑦⑧）；
• 在线用户的 Webmail 也可通过HTTPS调用 Web servers 查询（步骤⑨）；
• 离线用户上线后，通过 HTTP API 从 Web servers 拉取新邮件（步骤⑩）。

为什么接收流程要引入消息队列？

入站邮件流量天然波动大（深夜少、早高峰多），队列把"接收"与"处理"解耦：SMTP 层只负责快速接收，处理层按自身能力消费。这与19. Distributed Message Queue/README.md中讲的消费者模型一脉相承。而负载均衡器对入站流量的控制，本质上也是04. Rate Limiter/Readme.md中限流思想的工程化应用。

邮件发送流程对照看：同一套骨架，方向相反

理解了接收侧，再看发送侧会事半功倍，两者共享同一套存储层：


发送流程要点：

1. Webmail 通过 HTTPS 经负载均衡器（负责限流）到达 Web 服务器；
2. Web 服务器做基础校验（如邮件大小）：校验失败进Error queue，通过则进Outgoing queue；
3. SMTP Outgoing workers从队列拉取，做垃圾/病毒检查后投递到互联网（此时就要用上前面讲的 DNS MX 记录查找）；
4. 邮件同时写入存储层的元数据库、搜索存储、对象存储与缓存，归档到"已发送"文件夹。

运维上需要监控Outgoing queue 的堆积：队列异常增长往往意味着收件方服务器不可用（可用指数退避重试）或消费者不足（需要扩容消费者）。

延伸学习：这套设计笔记还能看什么

如果你想系统补齐分布式设计知识，本仓库的章节都是绝佳的长尾学习路径：

• 邮件服务全章：23. Distributed Email Service/README.md —— 元数据库表设计（folders/emails 表）、Elasticsearch 全文检索、多数据中心容灾；
• 缓存与 KV 存储：06. Key-Value Store/Readme.md —— 理解存储层中分布式缓存（Redis）与 Quorum 一致性原理；
• 消息队列：19. Distributed Message Queue/README.md —— 深入 At-least-once 语义、分区与消费者组；
• 限流：04. Rate Limiter/Readme.md —— 负载均衡器限流的四种经典算法图解。

📖 核心结论：邮件接收流程 =入口限流 + 策略检查 + 队列削峰 + 异步检测 + 多路存储 + 实时推送。而 DNS MX 记录的多优先级冗余机制，是这一切能够跨组织可靠投递的地基。把这两块吃透，你就理解了分布式系统"解耦"与"容错"两大思想的经典落地。

【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insider's Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes