backend
从零实现博客邮件订阅系统：Subscriber、EmailLog 到 EmailQueue 的完整设计
从设计 Subscriber 表开始，一步步实现博客邮件订阅系统，并深入介绍 EmailLog、统一邮件服务、异步队列以及生产环境优化方案。
2026-07-14
7 分钟阅读
从零实现博客邮件订阅系统：Subscriber、EmailLog 到 EmailQueue 的完整设计
很多人在开发个人博客时，都会希望增加一个『邮件订阅』功能。
例如：
用户输入邮箱 → 发布新文章 → 自动发送邮件通知。
看起来只是一个简单的功能，但如果从系统设计的角度来看，它其实涉及到了数据库设计、业务分层、日志记录、异步任务以及后期性能优化等多个方面。
本文将以我的博客系统为例，完整介绍这一套邮件订阅系统是如何一步一步设计出来的，以及后期如何逐步演进成一套适合生产环境的方案。
最初的需求
整个功能其实只有一句话：
当发布一篇新的文章时，自动通知所有已经订阅的用户。
整个流程可以抽象成：
context-payment.ts
发布文章 │ ▼ 查询所有订阅者 │ ▼ 发送邮件 │ ▼ 完成
如果订阅人数只有几个人，这样做几乎没有任何问题。
例如：
context-payment.ts
const subscribers = await prisma.subscriber.findMany() await Promise.all( subscribers.map((item) => sendSubscriptionEmail(...) ) )
但是，当订阅人数越来越多时，这个方案的问题就开始暴露出来。
第一步：设计 Subscriber 表
邮件订阅首先需要保存订阅用户的信息，因此第一步就是设计订阅者模型。
context-payment.ts
model Subscriber { id String @id @default(cuid()) email String @unique name String? verified Boolean @default(false) active Boolean @default(true) createdAt DateTime @default(now()) updatedAt DateTime @updatedAt }
其中有几个字段值得重点说明。
邮箱必须唯一，避免重复订阅。
verified
建议采用邮箱验证码完成验证之后再正式加入订阅列表，防止别人恶意填写他人的邮箱。
active
很多人会直接删除订阅数据，其实更推荐采用软删除：
context-payment.ts
active = false
这样既保留了历史数据，也方便以后重新恢复订阅。
第二步：封装统一邮件发送入口
如果项目越来越大，很容易出现下面这种情况：
context-payment.ts
await transporter.sendMail(...)
到处都是 SMTP 代码。
这样不仅重复，而且以后更换邮件服务时需要修改很多地方。
因此更推荐统一封装：
context-payment.ts
sendVerificationEmail() │ ▼ sendEmail() sendSubscriptionEmail() │ ▼ sendEmail() sendResetPasswordEmail() │ ▼ sendEmail()
所有邮件最终都交给 sendEmail() 处理。
sendEmail() 只负责：
- SMTP 发送
- 统一异常处理
- 邮件日志记录
- 更新发送状态
业务层只需要关心发什么邮件，而不用关心怎么发送。
这也是典型的职责分离思想。
第三步：增加 EmailLog
很多人一开始都会忽略日志。
但是随着系统运行，很快就会遇到这些问题：
- 为什么用户没有收到邮件？
- SMTP 是否发送成功？
- 邮件什么时候发送的？
- MessageId 是什么？
- 是否需要重新发送？
因此增加 EmailLog 是非常有必要的。
context-payment.ts
model EmailLog { id String @id @default(cuid()) email String name String? subject String type EmailType status EmailStatus error String? messageId String? payload Json? sentAt DateTime? createdAt DateTime @default(now()) updatedAt DateTime @updatedAt }
邮件发送流程变成：
context-payment.ts
创建 EmailLog(PENDING) │ ▼ SMTP 发送 │ ├──────────────┐ ▼ ▼ SUCCESS FAILED
以后任何邮件都可以查询发送记录，而不是依赖服务器日志。
第四步：封装 Newsletter
很多人会直接写：
context-payment.ts
sendEmail({ subject, html, })
更推荐继续封装：
context-payment.ts
sendSubscriptionEmail()
它负责：
- 生成邮件标题
- 选择 HTML 模板
- 组织 payload
例如：
context-payment.ts
sendSubscriptionEmail({ email, name, title, summary, url, coverImage, })
这样业务层根本不需要关心 HTML 模板。
第五步：为什么不能在发布文章接口直接发送所有邮件？
很多人的第一版代码都是：
context-payment.ts
发布文章 │ ▼ 查询所有订阅者 │ ▼ Promise.all() │ ▼ 等待所有发送完成
如果只有十几个订阅用户，这没有问题。
但是如果有：
context-payment.ts
1000 人
甚至：
context-payment.ts
10000 人
那么问题就来了。
首先，请求会一直阻塞。
其次，SMTP 会限制发送频率。
最后，Promise.all() 会同时创建大量 Promise，占用大量内存。
因此发布文章接口会越来越慢。
第一阶段优化：异步发送
对于个人博客来说，其实可以这样：
context-payment.ts
void notifySubscribers(blog)
而不是：
context-payment.ts
await notifySubscribers(blog)
发布接口立即返回，后台继续发送邮件。
这是最简单，也是成本最低的优化方式。
第二阶段优化：EmailQueue
如果订阅人数达到几百甚至几千人，就应该引入发送队列。
新增：
context-payment.ts
model EmailQueue { id String @id @default(cuid()) type EmailType status EmailStatus payload Json retries Int createdAt DateTime @default(now()) }
发布文章时：
context-payment.ts
发布文章 │ ▼ 查询订阅者 │ ▼ createMany EmailQueue │ ▼ 立即返回
真正发送邮件由后台 Worker 完成：
context-payment.ts
Cron │ ▼ 读取20条待发送任务 │ ▼ sendEmail() │ ▼ SUCCESS / FAILED
即使有几千名订阅用户，发布文章接口依旧可以在几百毫秒内完成。
第三阶段优化：消息队列
如果以后网站规模继续扩大，还可以接入专业消息队列。
例如：
- Redis + BullMQ
- RabbitMQ
- Kafka
整个流程将演变为：
context-payment.ts
Blog │ ▼ Queue │ ▼ Worker │ ▼ SMTP
不仅能够控制发送速度，还可以实现失败重试、限流、优先级、分布式发送等能力。
整个系统最终架构
最终整个邮件系统可以整理成下面这样：
context-payment.ts
发布文章 │ ▼ notifySubscribers() │ ▼ sendSubscriptionEmail() │ ▼ sendEmail() │ ├───────────────┐ │ │ ▼ ▼ EmailLog SMTP Server │ ▼ SUCCESS / FAILED
未来如果加入 EmailQueue，则整个系统演变为：
context-payment.ts
Blog │ ▼ EmailQueue │ ▼ Worker │ ▼ sendEmail() │ ▼ EmailLog │ ▼ SMTP
整个系统职责划分十分清晰：
- Subscriber：管理订阅用户。
- EmailQueue：管理待发送任务。
- sendSubscriptionEmail：负责订阅模板。
- sendEmail：统一发送邮件。
- EmailLog：记录每一次发送结果。
总结
邮件订阅系统看起来只是一个很小的功能，但如果提前做好架构设计，后期几乎不需要推倒重来。
对于个人博客而言，完全可以按照下面的演进路线逐步升级：
- Subscriber 管理订阅用户。
- sendEmail() 统一邮件发送入口。
- EmailLog 记录所有发送日志。
- sendSubscriptionEmail() 封装业务模板。
- EmailQueue 实现异步发送。
- Worker + 消息队列支持大规模邮件投递。
这样既满足当前个人博客的需求，又为未来的扩展预留了足够的空间，也符合现代 Web 应用中常见的分层架构设计。
评论 (0)
暂无评论，留下第一条声音吧。