uber-cadence框架是否对工作流生命周期内收到的信号数量进行了限制？

Question

优步的Cadence文档称，在工作流的生命周期中，单个工作流不能期望运行超过100k的活动。https://cadenceworkflow.io/docs/concepts/workflows/#child-workflow

单个工作流的大小有限。例如，它不能执行100k个活动。子工作流可以用来将问题划分成更小的块。一个有1000个子节点的父节点执行1000个活动，就是100万个已执行活动。

我想知道cadence是否会因为收到许多信号而对状态变化的次数施加类似的限制？

在我的用例中，我有一个长时间运行(几个月到几年)的工作流，每个工作流将跟踪游戏系统的用户活动。每隔几天，每个用户工作流将接收的信号总数会超过100k，这导致超过100k的工作流状态变化。

问题是，在我的业务逻辑中，每个信号不一定调用活动调用，因此每个工作流调用的活动总数可能保持在较低水平。（例如，接收到的信号超过 100k 时总共有 100 个活动呼叫）

1. 在这种情况下，节奏工作流是否会引发任何错误，因为工作流的内部历史太长，无法跟踪接收到的100k信号，尽管文档中每个指南只有数百个活动调用？

我不清楚cadence文档引用的100k活动限制是否仅适用于活动调用总数或所有状态更改(活动、信号、查询等)总数。

Answer 1

uber-cadence框架是否对工作流生命周期内收到的信号数量进行了限制？

是的。默认是10K。请参阅https://pkg . go . dev/github . com/Uber/cadence @ v 0 . 23 . 1/common/dynamic config # Key中的< code > MaximumSignalsPerExecution

更准确地说，此 10K 信号限制从此提交的 0.16 版本开始：https://github.com/uber/cadence/commit/0993f6ebb0ceda610f9e47fe8569db50485b0e18

小于0.16的版本没有任何限制。

当向工作流发送超过限制数量的信号时，Cadence将拒绝信号请求。

每个用户工作流将收到的信号总数可以100k每隔几天，这导致超过100k工作流状态changes.In这种情况下，节奏工作流会抛出任何错误，因为工作流的内部历史太长，无法跟踪收到的100k信号，尽管文档中每个指南只有数百个活动调用？

默认情况下，踏频要求历史记录小于 200K

查看历史限制 https://pkg.go.dev/github.com/uber/cadence@v0.23.1/common/dynamicconfig#Key 中的错误

当历史增长超过此限制时，Cadence将立即终止工作流程。但是，您可以调整配置，然后重置工作流。