欢迎邮件不属于注册流程：后台任务系统的四种消失方式
来源：dev.to — 2026-09-03
📋 概述
「顺带再发封欢迎邮件」——这句附注是后端工程里最能承重的谎言之一：它听起来像个脚注，实际是一个完整的子系统。作者用注册流程中的发信场景，从最天真的「请求里同步发信」写起，一版版把它弄坏再修好，梳理出后台任务消失的四种方式及其对策：直接把第三方的慢/失败拖进请求（该异步化）、双写两套系统间的崩溃缝隙导致账号在而任务丢（用事务性 outbox 保证原子提交）、worker 中途被杀任务就消失（用可见性超时而非立即删除，配合幂等处理至少一次投递）、永远成功不了的「注定失败」任务反复烧钱（用死信队列并给 DLQ 深度加报警）。核心是：让注册独立于邮件，把「顺带做」的活从请求里推出去。
🔑 核心要点
- 创建账号与发邮件是两种紧迫度完全不同的工作：用户在等前者，从没人坐在那里等欢迎邮件——把它们串在一起是把自己的 p99 交给别人的值班团队
- 事务性 outbox 让用户行与任务行在同一数据库同一事务里提交，消除了双写缝隙；它不能保证恰一次，只把静默丢任务变成偶尔做两次的可修问题
- 真实队列用可见性超时而非投递即删：worker 完成才显式 delete，崩溃后计时器过期任务重新可见，确保任何任务都不会丢
- 删除是收据不是结账——因为网络上的恰一次投递买不到，只能在至少一次之上用幂等（稳定 job id + 唯一约束）构建恰一次效果
- 永久失败别重试：畸形邮箱重试四遍也不会变好，约五次后进死信队列；DLQ 是停车场不是坟场，没人报警的 DLQ 只是更慢更贵地丢数据
- 判断一段活该不该后台化：用户是否在等结果？是否触碰不受自己控制的东西？跑两次是否有害？——请求处理器里出现「顺带做」就是后台任务
💡 金句
那些「顺带做」的事——顺带发邮件、顺带更新搜索索引、顺带 ping CRM——就是后台任务的特征，那个「顺带」就是破绽。
👍 0
👎 0
← 返回 dev.to 首页