如何使Cadence工作流拒绝信号

Question

除了MaximumSignalsPerExecution之外，还有其他方法可以发出工作流拒绝信号吗？

基本上，我有一个工作流，它在超时前会定期继续运行。但是，如果它在继续像新的一样工作之前不断收到大量信号，它将会超时并丢失一些信号。我可以将< code > MaximumSignalsPerExecution 设置得更低，这样它就会在超时之前拒绝信号，但理想情况下，我希望能够在工作流级别进行配置。

我正在测试一些更糟糕的情况，其中存在流量峰值，并且工作流每秒将获得多个信号。

Answer 1

除了Emrah的详细回答之外

• 根据您希望用于拒绝新信号的条件，您可能可以使用搜索属性来记录工作流的某些状态。在工作流中，使用upsertSearchAttribute API更新条件。然后，在发送任何信号之前，使用DescribeWorkflowExecution API读取搜索属性，并使用它来决定是否应该发送信号
  • 上面的想法是稍微误用了搜索属性。因为我们没有使用该属性来搜索任何内容。理想情况下，我想用“备忘录”来做这件事，但“备忘录”在今天的工作流中并不是可变的。这是我希望允许更新备忘录（如更新SA）的未决问题。
  • 因为这个想法不需要“搜索”工作流。因此，即使您没有为搜索属性启用AdvancedVisibilty，也可以这样使用它

Answer 2

首先，回答您的问题：不幸的是，没有任何其他限制可以阻止发送的信号数量。不过，我不确定这会有多大用处。signal、startandsignalbeartAPI是Cadence用户调用的最关键的API之一，因为这些API将数据保存在Cadence中。我们通常会尽量保持这些API的高可用性，以便我们能够接受和保存这些请求附带的数据。否则，客户机要么必须有一个回退数据存储来保存Cadence拒绝的请求，要么只将故障传播到上游。

MaximumSignalsPerExecution限制的主要好处是保护Cadence数据库免受单个工作流执行的无限增长。我不建议仅仅为了改进一个用例而使用它。

信号和< code>ContinueAsNew之间的竞争是一个相对常见的问题。我有一些想法来解决它，但我不认为我们能够很快做到这一点，因为竞争的优先权。同时，我认为最好的办法是为你的工作流程设定正确的期望值。设计工作流程时，您应该记住以下两条原则:

< li >尽管Cadence在并发工作流的数量方面可以很好地进行水平扩展，但在每个工作流的基础上却不能很好地进行扩展。原因是cadence服务器为每个工作流获取锁，并将每个数据库更新作为一个昂贵的事务来执行，以便提供在后台保持工作流安全所需的所有一致性保证。我推荐的经验法则是:设计您的工作流，使它们每秒钟生成的事件不超过10个，包括收到的信号。当超过这个限制时，您将开始遇到特定工作流的锁争用，导致延迟增加和超时，即使系统的其余部分非常健康/空闲。 < Li > < code >决策任务(即你的工作流对事件做出反应并决定下一步的时间)应该非常快，以毫秒为单位。这将增加工作流周围的一切快速移动而不互相阻塞的机会。

就你的情况而言，如果你还没有考虑过，你应该考虑以下想法:

• 考虑一下，如果你有一个硬限制，比如每秒5个，你如何减少每个工作流的信号数量。也许你可以通过启动许多类似的工作流来解决这个问题，而不仅仅是一个，并发出一个随机的信号来在它们之间分配负载
• 确保您的决定尽可能快，尤其是在处理信号和尝试像新的一样继续时。
• 如果您试图在接收到信号后安排任何工作（即活动等），请尝试将其放入列表中并将其作为输入传递给工作流的下一次运行作为输入，以便新的工作流运行执行上一次运行跳过的信号处理工作。