设计分布式邮箱服务

一句话

这一章表面是「造一个 Gmail」，实际上是整套 Xu 系列里分区键（partition key）最干净的一道题：邮件协议那一层四十年前就冻结了，工程量全压在十亿个互不相干的私人信箱上——而正因为任何查询都只落在一个人身上，分布式里最贵的那几样（跨分区事务、全局排序、全局索引）在这里可以整套不买。这一章真正教你的，是认出并用尽这份天赐的分区键。

Glossary · 术语表

坐标

卷二第 8 章。上承 Ch7「酒店预订」（有限库存的并发争抢），下启 Ch9「对象存储」。它是卷二那条「造轮子的内部构造」主线的前半段：本章把「海量小对象的元数据」摊开讲，下一章再把承接附件的那个存储层本身拆开。现实对应物是 Gmail、Outlook、企业邮件网关，以及任何「每个用户一个私有数据空间」的系统——网盘、笔记、私信收件箱都是同一形状。

这章要解决什么

先按书里那组假设把账算出来：10 亿用户，人均每天发 10 封、收 40 封，正文平均 50KB，20% 的信带附件、附件平均 500KB。

• 发信：10^9 × 10 / 86400 ≈ 11.6 万封/秒；收信：10^9 × 40 / 86400 ≈ 46 万封/秒。
• 每天新增正文 10^9 × 40 × 50KB ≈ 2PB，附件 10^9 × 40 × 20% × 500KB ≈ 4PB——合计约 6PB/天，而且几乎只增不减。

传统邮件服务器的做法是一台机器上一个 Maildir 目录，每个人的信当文件堆着。这套东西在 6PB/天面前三处同时崩：存不下（单机容量）、搜不动（全文搜索要扫文件）、挂一台掉一批人（没有副本）。

更隐蔽的一条是写放大在状态位上：邮件正文写一次就不动了，但「已读 / 未读 / 标签 / 归档」每天被改无数次。按上面的假设，光是「读完标已读」这一个动作，全局就是约 46 万次/秒的小更新——跟收信本身同一个量级。邮箱不是一个读系统，是一个读写都很重的系统，这直接决定了它不能用只读优化的存储。

核心内容，讲透

① 协议这层是既定事实，真正的自由度在它后面

对外你必须讲 SMTP：发信时查对方域名的 MX 记录找到目标服务器，建连接把信推过去。这一层你改不了，也控制不了对端——对方服务器可能宕着、可能限速、可能把你判成垃圾直接退回。

由此推出第一条架构硬约束：出站绝不能同步等。用户点「发送」得立刻返回，投递本身是个可能要重试几小时甚至几天的后台任务。所以出站必须是队列 + 指数退避重试 + 死信/退信。

对内则是另一套：POP3 是单设备时代的遗产（下载即删），IMAP 让服务端成为唯一真相、多设备各自同步，而今天网页版和手机 App 实际走的是自家的 HTTPS 接口 + WebSocket 推送——只在跟第三方客户端（Outlook、Apple Mail）打交道时才需要真的实现 IMAP。

② 元数据存哪：为什么不是关系库，而是宽列 NoSQL

书里先把邮件元数据的性格列清楚，选型是从性格里推出来的：

• 量极大且只增不减——PB 级，合规要求下删不掉。
• 每个用户只访问自己的数据——没有任何一条查询需要跨用户。
• 写的大头是小更新——已读位、标签、移动文件夹。
• 单用户内要强一致，跨用户之间毫不相干——手机上标了已读，电脑刷新必须立刻看到；但你的信箱和我的信箱之间，不需要任何一致性保证。

最后一条是整章的枢纽。它意味着「一致性边界」可以正好画在一个用户身上：把行键（row key）取成 user_id，一个用户就是一行，那么所有需要原子性的操作——收一封信、标已读、批量归档——全部落在同一行内。绝大多数宽列存储都提供单行原子写，于是分布式事务这项最贵的开销，一次都不用买。Google 的 Megastore 论文（CIDR 2011）正是拿邮箱账户当「实体组」的范例：组内保证 ACID，组与组之间不保证——邮箱天然长成这个形状。

列键则再吃一次免费的午餐。把它设计成 文件夹:时间戳:邮件ID 这样的复合键，宽列存储本就按列键排序，于是「取收件箱最近 20 封」退化成一次反向范围扫描：不需要二级索引，不需要 ORDER BY，不需要 offset 分页。

③ 正文与附件分家：小对象进数据库，大对象进对象存储

正文通常几 KB 到几十 KB，附件则是几百 KB 起、上限 25MB（Gmail 的公开限制）。若把附件字节塞进元数据行，收件箱列表这个最高频的操作就得连带拖动几百 MB 的无用数据。所以书里的做法是把附件放进外部对象存储，元数据里只留一个键。

这带来一个漂亮的顺手收益：按内容哈希去重。一封带 10MB 附件的信群发给 100 人，对象存储里只存一份，元数据里 100 张「取件单」指过去——省掉 99% 空间。代价是删除从一次写变成了引用计数与垃圾回收问题：最后一个引用消失前，那份字节不能动。

大附件上传还得是分片上传 + 断点续传：25MB 在弱网下一次性 PUT 的失败率高到不可接受，切成 5MB 一片重试才有意义。

④ 搜索：十亿个小索引，不是一个大索引

这是全章最容易被想歪的地方。邮件搜索和网页搜索有三条根本差别：

• 范围：网页搜索是一个巨型索引服务十亿人；邮件搜索是十亿个小索引各服务一人。一个重度用户几万到几十万封信，语料小到可以每人独立成册。
• 排序：网页按相关性排；邮件绝大多数时候按时间倒序排——用户找的是「上周那封」，不是「最相关那封」。
• 时效：网页索引延迟几小时可以接受；邮件一秒前刚到的那封，现在就必须搜得到。这条直接把「离线批量建索引」这条路堵死了。

把这三条合起来，索引的分片键就只剩一个选择：还是 user_id。一次搜索只打一个分片，不需要把查询扇出到上千个分片再归并——这正是邮件搜索能做到几十毫秒级而成本又不爆炸的原因。

写路径因此被搜索反向塑形：一封信进来，要同时写元数据、写对象存储、写索引。这三者不在同一个事务里，所以书里的处理是异步写 + 失败重试 + 定期比对补偿，接受一个秒级的不一致窗口。把搜索当成「以后再加的功能」，是这道题最常见的翻车点——它决定的是写路径的形状，不是读路径的装饰。

关键权衡与选型

表 1 · 元数据存哪：三条路线，书里选了第三条

表 2 · 搜索：买现成的，还是长在存储里

表 3 · 客户端怎么取信：三种同步模型

为什么重要 / 落到真实系统

这道题在面试里的独特价值是：它是唯一一道分区键已经写在题面上的题。考官真正在看的，不是你能不能背出 SMTP 的握手，而是你有没有意识到「没人查别人的信箱」这句话一次性买断了跨分区事务、全局排序和搜索扇出——并把这份红利用到底。答不出这层，整道题就退化成一堆框图。

易错点与争议

• 以为难点在协议。SMTP/IMAP 是全章最成熟、最没有设计空间的一层。把时间花在讲握手流程上，等于答错了题。
• 以为「按 user_id 分区」就万事大吉。企业里有几十万封、几十 GB 的超大信箱，一行会变成胖行 + 热点。真实系统需要在用户之下再按文件夹或时间段二次切分——这一层书里点到但没展开。
• 把已读位当小事。状态更新的 QPS 与收信同量级，它才是决定存储选型的那条约束；只按「存正文」估算，会选错整套底层。
• 把三副本当备份。副本抗的是硬件与机房故障，抗不了一个会删数据的软件缺陷——它会被忠实复制三份。邮件系统必须另有离线、不可变、跨介质的备份。
• 时代局限（书写于 2022）：端到端加密邮箱（Proton 那一类）几乎没被讨论。一旦服务端看不到正文，服务端搜索和反垃圾同时失效，索引只能搬到客户端——本章的整套架构在那里要重来一遍。
• 本章没覆盖的真实工程量：投递率（deliverability）。IP 信誉、发送域预热、退信分类处理、SPF/DKIM/DMARC 的实际部署——真实邮件团队一大半时间花在这上面，书里只是点名。同理，GDPR 的「删除权」与法务保留（legal hold）之间的冲突，在「邮件只增不减」的前提下是个真难题，书里也没展开。

要点