什么是任务队列？

有几个不同的观点，我们可以从中谈论任务队列。
从高层次上，我们可以说任务队列正是名称所暗示的。它是任务的”先入先出”队列，其中任务是执行 Workflows 更改”状态”所需的上下文。
任务队列由 Temporal 服务器维护。例如，服务器将任务放入任务队列中以安排、启动、取消和完成 Workflows 和/或 Activities 的部分。一名 Worker 使用任务队列进行长时间的轮询，等待有任务可用。然后，该工作人员根据任务内容指导去执行代码。
从开发人员的角度来看，使用 SDK，任务队列是将” Worker “与” Workflows “和/或” Activities “关联的手段之一。在这种情况下，您可以在编写应用程序的对应语言上下文中学习如何实现任务队列：

从系统设计的角度以及一切在引擎盖下如何工作的角度来看，事情变得更加复杂了一点。
我们打算在未来的系统设计和架构文档中更详细地解释这一点。

为什么任务队列？

Temporal 任务队列与常用的排队技术略有不同。主要区别在于，它们不需要明确注册，并且是按需创建的。任务队列非常轻量级，系统可以处理的任务队列总数没有限制。[译注: 典型的 Pub/Sub 场景,加上 Worker 的外部性质,很容易想到分布式运行时 Dapr 下的 Worker 与 Temporal 结合的方案]
使用任务队列向工作人员交付任务比通过同步 RPC 调用操作具有多种优势。

  • Worker 不需要有任何开放的端口，这是更安全的。
  • 工作人员不需要通过 DNS 或任何其他网络发现机制进行广告宣传。
  • 当所有 Worker 都关闭时，消息只会持续在任务队列中，等待工作人员恢复。
  • Worker 只有在有备用容量时才会对消息进行投票，以避免自身过载。
  • 任务队列可在大量 Worker 之间实现自动负载平衡。
  • 任务队列支持服务器侧节流，这使您能够将任务调度速率限制在工作人员池中，同时在发生峰值时仍然以更高的速率支持任务调度。

  • 任务队列启用我们所谓的”任务路由”，即将特定任务路由给特定的 Worker ，甚至特定程序。 :::info

    注意

    所有监听给定任务队列的 Worker 必须具有相同的 Activities / Workflows 注册。其中一个例外是在服务器升级期间，当二进制文件滚动更新时，注册暂时失调是可以的。 :::

    任务路由

    文件处理往往是您可能需要将任务路由到特定过程的最佳示例之一。
    假设您有以下三个 Activities 的 Workflows ：

  • 下载文件的 Activities 。

  • 以某种方式处理文件的 Activities 。
  • 将文件上传到其他位置的 Activities 。

在现实生活中，您希望让许多工作人员参与进来，以便同时扩展许多文件的处理。
下载文件的第一个 Activities 可能发生在任何”工作”上。但是，第二个和第三个 Activities 必须由工作人员在第一个 Activities 下载文件的同一主机上执行。
您可以使用任务队列和专用工作人员以优雅的方式处理此场景。
您可以找到用于以下语言的此技术的实现示例：

Go SDK 附带一个 Session 会话功能，抽象了为此用例明确路由任务的必要性。Go 文件处理示例也展示了这一点。