后台任务：从定时脚本到分布式系统

设想一下，当用户向某个 Web 应用上传一张个人头像时，可能会发生什么。

根据具体业务场景，应用可能会对图片进行多尺寸的缩放处理；也可能先对图片内容进行安全检测；随后还将这些缩放后的图片分发至内容分发网络，以提升访问速度。

最后，应用还会将最新的元数据更新到用户的账户记录中。试想一下，如果所有这些操作都挤在一个图片上传的请求处理流程里，那么在执行这些功能的过程中，用户只能眼看着一个加载中的按钮转个不停，足足等上好几秒钟，心里还在忐忑：我的照片到底上传成功没有？

这样的用户体验显然相当糟糕。

如果我们把这些额外的工作从主请求路径中剥离出去，那么只要图片文件一存入对象存储，上传操作就能几乎立即返回响应。至于图片的缩放、内容扫描以及分发等工作，依然会按部就班地完成，只是不再与主请求同步进行。

这种模式被称为后台任务，而触发它的原因通常有以下几种：

• 由用户的某个操作直接触发。例如，用户注册成功后，系统自动发送一封欢迎邮件。
• 由时间事件触发。例如，夜间报表生成、月度账单开具、每小时缓存刷新等定时任务。
• 由其他系统发出的信号触发。例如，收到一条 Webhook 消息，或者有新文件被存入对象存储。
• 纯粹出于效率或成本考虑。例如，某些工作批量处理——一次处理上千条记录——往往更经济、更安全。

大多数情况下，团队最初会从一台服务器上运行一个简单的定时脚本起步，它足以胜任相当规模的后台任务。然而，随着系统的规模不断扩大、复杂度持续攀升，后台任务的管理也亟需更为成熟的策略。

在本文中，我们将详细探讨多种用于执行后台任务的具体方案。

为什么普通请求并非处处适用