Signals 是给 running 状态的 Workflow Execution 提供数据的信息，Queries 是向running 状态的 Workflow Execution 请求数据的信息。
Signals 和 Queries 经常一起使用。

Signals

Signal 是 Workflow Execution 的外部异步请求。
Signal 旨在将数据传递给正在运行的 Workflow Execution，用于更改变量值和 Workflow Execution 的状态。Signal 不能将数据返回给调用方，需要使用 Queries。
Signal 可以通过 Temporal 客户端或者从 Workflow 中发送出去。当发送 Signal 时，它会被集群（Cluster）接收，并作为事件记录到 Workflow Execution 事件历史中。集群将删除重复 Signal，并使用具有特定 Id 的第一个 Signal。下一个被调度的 Workflow Task 中将会包含 Signal Event。
Signal 是具有唯一 Id 的信息。Signal 必须包含目的地 （命名空间 + 工作流 Id）。

Signal Header 包括以下内容:

  • 接收方: Workflow Execution（命名空间 + 工作流 Id）
  • Id: Signal 的唯一 id。
  • 名称: 将会添加 Signal 的队列名称。

Signal Body 包括以下内容:

  • 任何可编码的数据。

Workflow 函数通过 Signal 名称监听 Signals。Signals 按照它们被接收顺序发送出去。Workflow Execution 可以选择等待单个 Signal 名称或多个 Signal 名称。

  • How to use Signals in Go
  • How to use Signals in Java

  • How to use Signals in PHP

    Queries

    Query 是一种同步操作，用于查询 Workflow Execution 的状态。
    正在运行的 Workflow Execution 的状态在不断变化。通过 Queries 向外部世界暴露内部 Workflow Execution 状态。

  • Query 通过 Temporal 客户端同步调用。

  • Query 可以携带参数来指定请求的数据，因为每个 Workflow 都可以将数据暴露给多种类型的 Queries。
  • Query 不能改变 Workflow Execution 的状态。
  • 如果将 Query 发送到已完成的 Workflow Execution，则返回最终值。
  • Query 处理逻辑在 Workflow 中作为代码实现。Query 处理逻辑必须为只读并且不能以任何方式更改 Workflow Execution 状态或包含任何阻止代码。这意味着 Query 处理逻辑不能生成 Activity Executions。

在许多 SDK 中，Temporal 客户端暴露了预定义 stack_track Query，返回该 Workflow Execution 所拥有的所有线程的堆栈跟踪。这是解决生产中 Workflow Execution 问题的好方法。

旧版

事件处理

故障忽略的,有状态的 Workflow 可以接收关于外部事件的信号 Signals 。信号 Signals 总是指向特定的 Workflow 实例。信号 Signals 总是按照接收顺序处理。 信号 Signals 有用的多种方案。

事件聚合和相关性

Temporal 不是用于替代通用流处理引擎，如 Apache Flink 或者是 Apache Spark。但在某些情况下，反而更合适的。例如，当所有应汇总和关联的事件始终应用于具有明确 ID 的某些业务实体时。或者当满足特定条件时，应执行某些操作。 主要限制是，单个 Temporal Workflow 的吞吐量相当有限，而 Workflow 的数量实际上是无限的。因此，如果您需要汇总每个客户的事件，并且您的应用程序有 1 亿客户，并且每个客户每秒生成的事件不超过 20 个，那么 Temporal 将正常工作。但是，如果您想为美国客户汇总所有事件，则这些事件的速率将超出单一 Workflow 容量。 例如，物联网设备生成事件，并且某个事件序列表示设备应重新编程。将创建每个设备的 Workflow 实例，每个实例将管理设备的状态机器，并在必要时执行重新管理 Activities 。 另一个用例是客户忠诚度计划。每次客户进行购买时，都会将事件生成到 Apache Kafka，供下游系统处理。Kafka 消费者的忠诚度计算 Service 接收事件，并使用 Temporal signalWorkflowExecutionAPI 向客户发出信号 Signals。 Workflows 进行购买计数。当达到指定阈值， Workflow 将执行一项 Activities ，通知某些外部服务客户已达到更高水平的忠诚度。此外 Workflow 还执行 Activities ，定期向客户发送有关其当前状态的信息.

人类任务

许多业务流程涉及人类参与者。实施外部交互的标准 Temporal 模式是在外部系统中执行创建人类任务的Activities 。它可以是包含表单的电子邮件，或某些外部数据库中的记录，或移动应用通知。当用户更改任务状态时，信号 Signals 将发送到相应的 Workflow 。例如，提交表格时或确认移动应用通知时。某些任务具有多种可能的操作，如索赔、返回、完成、拒绝。因此，可以发送多个与它相关的信号 Signals 。

过程执行更改

如果发生了某些外部事件，某些业务流程应更改其行为。例如，在执行订单发货 Workflow 时，任何项目数量的变化都可以以信号 Signals 的形式交付。 另一个例子是服务部署 Workflow 。在向 Kubernetes 集群推出新软件版本时，发现了一些问题。在调查问题时，可以使用信号 Signals 要求 Workflow 暂停。然后，可以使用继续或回滚信号 Signals 执行相应的操作。

同步

Temporal Workflow 具有很强的一致性，因此它们可用作执行操作的同步功能。例如，要求对单个用户的所有消息进行按顺序处理，但基础消息传递基础架构可以并行传递它们。Temporal 解决方案是每个用户有一个 Workflow ，并在收到事件时发出信号 Signals 。然后， Workflow 将缓冲内部数据结构中的所有信号 Signals ，然后对收到的每一个信号 Signals 调用Activities 。请参阅以下 Stack Overflow answer。