Uber Cadence 任务列表管理

问题描述

我们正在使用 Uber Cadence，并且会定期在生产环境中遇到问题。 设置如下：

• 一个带有 Cadence 客户端 2.7.5 的 Java 14 BE
• 带有 Postgres DB 的 Cadence 服务版本 0.14.1

有多个域，对于所有域，单个 BE 服务器都注册为 worker。

在日志中可以看到的是，有时在查询过程中，节奏似乎失去了对 BE 服务的粘性：

"msg":"query direct through matching failed on sticky,clearing sticky before attempting on non-sticky","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"
"msg":"query directly though matching on non-sticky failed","address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"
"msg":"query directly though matching on non-sticky failed","address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"
...

同时在后端什么也看不见。但是，在此期间，如果我检查 cadence Web 客户端上的轮询器，我会看到任务列表在那里，但它不再被视为决策处理程序 (http://localhost:8088/domains/mydomain/task-列表/mytasklist/pollers）。正因为如此，整个环境几乎都死了，因为没有什么可以随着决定而进步。唯一的选择是重启后端服务，让它重新注册为 worker。

此时调查陷入僵局，希望能提供帮助。

• 有谁知道工作人员或任务列表如何失去其作为决策处理者的能力？它是否由节奏管理，例如基于工人产生的错误数量？我找不到任何关于此的信息。
• 据我所知，当粘性丢失时，cadence 将检查是否有另一个工作人员重播工作流程并继续执行（在我的情况下，这将是同一个工作人员，因为只有一个工作人员）。是否有可能无法重放流程（尽管我认为它会在来自 cadence 客户端的后端日志中生成一些内容），或者此时工作人员已经从列表中删除并导致超时？

欢迎任何帮助！谢谢！

解决方法

有谁知道工人或任务列表如何失去其作为决策处理者的能力

当工作人员停止轮询决策任务时，就会发生这种情况。例如，如果您将工作人员配置为仅轮询活动任务，那么它将显示为这样。显然，如果工作人员出于某种原因停止轮询决策任务，也会发生这种情况。

据我所知，当粘性丢失时，cadence 将检查另一个工人是否重播工作流程并继续

是的，只要有另一个工人轮询决策任务。请注意，查询任务被视为决策任务类型。 （这是一个错误的设计，我们正在努力将其分开）。

来自您的日志：

"msg":"query directly though matching on non-sticky failed","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"

这意味着 Cadence 将 Query 任务分派给一个 worker，一个 worker 接受了，但没有在超时时间内回复。

您的查询处理程序逻辑中很有可能存在一些错误。该错误导致决策工作人员崩溃（这意味着 Cadence Java 客户端也有一个错误，用户代码崩溃不应该使工作人员崩溃）。然后一个查询任务循环遍历您的工作池的所有实例，最终使您的所有决策工作者崩溃。