system-design-notes邮件接收流程深度解析DNS MX记录查找全图解【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes是《System Design Interview - An Insiders Guide》一书的配套笔记其中第 23 章 23. Distributed Email Service/README.md 以 Gmail 为原型设计了一个支持 10 亿用户的分布式邮件服务。本文将带你用图解方式吃透邮件接收流程的 10 个关键步骤并完整拆解DNS MX 记录查找这一邮件跨服务器投递的核心机制是新手入门分布式系统设计的优质教程 。先看懂全局分布式邮件系统高层架构在深入邮件接收流程之前先建立全局视角。一个现代分布式邮件服务通常由 Web 服务、实时推送服务和多层存储组成各核心组件职责一目了然组件职责Webmail用户通过浏览器收发邮件Web Servers处理登录、注册、资料管理等 HTTP 请求Real-time Servers通过 WebSocket降级为长轮询实时推送新邮件Metadata DB存储邮件元数据主题、正文、收发件人Attachment Store对象存储存放大附件Distributed Cache缓存近期邮件如 Redis提升体验Search Store分布式文档存储支持全文搜索相比传统邮件服务器把邮件存成本地文件磁盘 I/O 是瓶颈且无法保证高可用分布式架构通过消息队列、对象存储与多级存储层同时满足了可靠性、可用性与可扩展性要求。DNS MX记录查找怎么做邮件跨服务器投递的秘密邮件能找到对方服务器靠的是 DNS 中的MXMail Exchanger记录。以 Alice 给 Bob 发信为例传统邮件服务器的投递路径如下流程共 4 步Alice 在 Outlook 客户端点发送邮件通过SMTP协议送到 Outlook 邮件服务器Outlook 服务器向 DNS 查询gmail.com的MX 记录找到对端邮件服务器后再通过 SMTP 转交邮件Gmail 的 SMTP 服务器将邮件存入本地 StorageBob 通过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 PolicyEAP非法邮件在此直接丢弃第一时间挡住垃圾流量。步骤 ③大附件分流如果邮件附件过大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中限流思想的工程化应用。邮件发送流程对照看同一套骨架方向相反理解了接收侧再看发送侧会事半功倍两者共享同一套存储层发送流程要点Webmail 通过 HTTPS 经负载均衡器负责限流到达 Web 服务器Web 服务器做基础校验如邮件大小校验失败进Error queue通过则进Outgoing queueSMTP Outgoing workers从队列拉取做垃圾/病毒检查后投递到互联网此时就要用上前面讲的 DNS MX 记录查找邮件同时写入存储层的元数据库、搜索存储、对象存储与缓存归档到已发送文件夹。运维上需要监控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 Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考