基于信号恢复Cadence Workflow，不阻塞线程答案

【问题标题】：Resume Cadence Workflow based on signal without blocking the thread基于信号恢复Cadence Workflow，不阻塞线程
【发布时间】：2020-06-17 07:08:48
【问题描述】：

我们想要构建一个包含以下步骤的工作流

执行一些同步活动。
通过 kafka 事件触发外部操作。
监听 kafka 事件以获取操作结果。
根据结果执行一些其他活动。

Kafka 可能包含与工作流无关的事件，因此我们需要一个单独的工作流来过滤该特定工作流的事件。

我打算使用 cadence 将其分成两个工作流程

Workflow1 : 1 -> 2 -> 等待信号 -> 4
Workflow2 : 3 -> 调用 workflow1.signal

是否可以在没有实际阻塞线程的情况下等待工作流1中的信号，以便线程可以同时处理另一个工作流。

【问题讨论】：

标签： cadence-workflow temporal-workflow

【解决方案1】：

我认为对于 Temporal/Cadence 的工作原理存在一些误解。没有要求不阻塞线程以使其他工作流能够取得进展。 Worker 实例处理这种情况没有问题。

所以我建议在工作流中阻止线程等待信号，因为这是解决您的业务需求的最简单方法。

作为旁注，我不明白您为什么需要第二个工作流程。不需要有一个工作流来过滤 Kafka 事件。您可以直接在发出第一个工作流信号的 Kafka 使用者中执行此操作。

【讨论】：

感谢Maxim的及时回复。我是 Cadence/Temporal 工作流程的新手。我刚刚开始探索这些框架，似乎我没有正确地提出我的问题（现在更新）。我的问题是我们是否可以解锁同一个线程来处理另一个工作流。假设我们需要使用 10 个线程运行 100 个工作流。我们可以在同时重新使用它们来处理其他工作流，而不是在 Kafka 响应中阻塞 10 个线程。是的，我将 Kafka 消费者称为第二个工作流程。
100 个工作流和 10 个线程的短语在 Temporal 上下文中没有意义。您的系统中可以有一个具有 10 个线程和 100 万个工作流的工作器，如果大多数时间它们被阻塞等待外部事件，那也没关系。
感谢 Maxim 的澄清。我认为在这种情况下，整体吞吐量将受到影响，因为线程大部分时间都被外部事件阻塞，并且同时无法选择另一个工作流（鉴于我们受到每个工作线程数的限制并且需要处理 1M 工作流）以及我们如何在这种情况下动态扩展工作人员（我的意思是基于哪个参数）以提高吞吐量？
您对“线程大部分时间都被外部事件阻塞并且无法选择另一个工作流”的假设是不正确的。当工作流被阻塞时，如果需要，它可以从工作内存中删除并释放它的线程。当它收到一个新事件时，它将在一个可能不同的工作人员身上复活，并从它被阻止的同一个地方继续。
太棒了，很适合我们的用例。如果您可以分享任何描述该场景的 java 示例，这将非常有帮助 ------ 当工作流被阻塞时，如果需要，可以将其从工作内存中删除并释放其线程。当它收到一个新事件时，它将在一个可能不同的工人身上复活，并从它被阻止的同一个地方继续-----

【解决方案2】：

我有一些编写 Kafka/Kinesis 消费者的经验（不使用 Cadence，但计划很快这样做）。我的感觉是，您只需要阻塞 1 个消费者线程并等待来自 Kafka 流的新事件。这个消费者可以住在任何地方，只要它可以与您的 Cadence 系统对话以向工作流程发送信号。对于每条 Kafka 消息（过滤掉不相关的），如果它可以设计为包含所有信息，供消费者决定向哪个工作流发出信号，那将非常简单。如果您无法控制消息中的内容（听起来您有一个现有的流），这是一个小技巧。您的消费者可能需要根据消息中的其他标识符来查找要调用的工作流

【讨论】：

谢谢戈登。是的，我正计划完全按照您提到的关于 Kafka 消费者的操作（消息将包含用于决定要发出信号的工作流实例的信息）。但问题是执行实际工作流的线程也被阻止等待第 2 步之后的信号，这将影响整体吞吐量。基本上，如果我将工作流程分成 2 个。一个用于执行步骤 1->2，另一个用于执行步骤 4，它将增加吞吐量。但是，我想将所有步骤整合到一个工作流程中以跟踪整体进度。
“执行实际工作流程的线程”：据我了解，这不是 Cadence/Temporal 的工作方式。当工作流调用活动然后等待信号时，执行工作流的 Java/Go 工作线程将继续执行其他操作。该“工作流程”现在是数据库中的一堆数据。当信号到来时，它进入一个队列，有容量的工作人员会接它并继续执行工作流
感谢 Gordon 的澄清。