2

所以有这么多超时值：

对于本地活动：

  • ScheduleToClose 超时

对于没有重试的常规活动：

  • ScheduleToStart 超时
  • ScheduleToClose 超时
  • StartToClose 超时
  • 心跳超时

然后retryOptions中的更多值：

  • 过期间隔
  • 初始间隔
  • 退避系数
  • 最大间隔
  • 最大尝试次数

并且 retryOptions 可以应用于 localActivity 或常规活动。

我如何将它们与什么期望一起使用？

4

1 回答 1

4

TL;博士

使用超时的最简单方法：

带重试的常规活动：

  1. 使用 ScheduleToClose 作为每次尝试的超时
  2. 将 ScheduleToStart 和 StartToClose 留空
  3. 如果 ScheduleToClose 太大（如 10 分钟），则将心跳超时设置为较小的值，如 10 秒。定期调用活动内部的心跳 API。
  4. 使用 retryOptions.InitialInterval、retryOptions.BackoffCoefficient、retryOptions.MaximumInterval 来控制退避。
  5. 使用 retryOptions.ExperiationInterval 作为所有尝试的总体超时。
  6. 将 retryOptions.MaximumAttempts 留空。

无需重试的常规活动：

  1. 使用 ScheduleToClose 进行整体超时
  2. 将 ScheduleToStart 和 StartToClose 留空
  3. 如果 ScheduleToClose 太大（如 10 分钟），则将心跳超时设置为较小的值，如 10 秒。定期调用活动内部的心跳 API。

LocalActivity without retry : 使用 ScheduleToClose 进行整体超时

LocalActivity 重试：

  1. 使用 ScheduleToClose 作为每次尝试的超时。
  2. 使用 retryOptions.InitialInterval、retryOptions.BackoffCoefficient、retryOptions.MaximumInterval 来控制退避。
  3. 使用 retryOptions.ExperiationInterval 作为所有尝试的总体超时。
  4. 将 retryOptions.MaximumAttempts 留空。

什么和为什么

无需重试的基础知识

世界上的事情不用重试就更容易理解了。因为Cadence就是从它开始的。

  • ScheduleToClose 超时是从工作流的角度来看的整体端到端超时。

  • ScheduleToStart 超时是活动工作人员启动活动所需的时间。超过此超时，活动将向工作流返回 ScheduleToStart 超时错误/异常

  • StartToClose 超时是活动需要运行的时间。超过此值会将 StartToClose 返回到工作流。

  • 要求和默认值：

    • 提供 ScheduleToClose 或同时提供 ScheduleToStart 和 StartToClose。
    • 如果只有 ScheduleToClose，那么 ScheduleToStart 和 StartToClose 都是默认的。
    • 如果只提供了 ScheduleToStart 和 StartToClose，则ScheduleToClose = ScheduleToStart + StartToClose.
    • 所有这些都受工作流超时的限制。（例如，如果 workflowTimeout 为 1 小时，为 ScheduleToClose 设置 2 小时仍将获得 1 小时ScheduleToClose=Min(ScheduleToClose, workflowTimeout)：）

那么他们为什么会这样呢？

您可能会注意到 ScheduleToClose 仅​​在 ScheduleToClose < ScheduleToStart + StartToClose. 因为如果ScheduleToClose >= ScheduleToStart+StartToCloseScheduleToClose 超时已经被其他两者的组合强制执行了，它就变得毫无意义了。

因此，ScheduleToClose 小于两者之和的主要用例是人们希望限制活动的整体超时，但为 scheduleToStart 或 startToClose 提供更多超时。这是极其罕见的用例。

人们想要区分 ScheduleToStart 和 StartToClose 的主要用例是工作流可能需要对 ScheduleToStart 超时错误进行一些特殊处理。这也是非常少见的用例。

因此，您可以理解为什么在 TL;DR 中我建议仅使用ScheduleToClose而将其他两个留空。因为只有在极少数情况下您可能需要它。如果你想不出用例，那么你就不需要它。

LocalActivity 没有 ScheduleToStart/StartToClose，因为它直接在工作流工作者内部启动，不涉及服务器调度。

心跳超时

心跳对于长时间运行的活动非常重要，以防止它卡住。不仅错误会导致活动卡住，定期部署/主机重启/故障也可能导致它。因为没有心跳，Cadence 服务器无法知道活动是否仍在进行中。在此处查看更多详细信息解决 Cadence/SWF/StepFunctions 中卡住的计时器/活动的解决方案

RetryOptions 和 Activity 与 Retry

首先，这里的 RetryOptions 用于server side退避重试——这意味着重试由 Cadence 自动管理，而不与工作流交互。由于重试由Cadence 管理，因此必须在Cadence 历史记录中对活动进行特殊处理，在活动关闭之前无法写入启动的事件。这里有一些参考：为什么一个活动任务被安排了但没有开始？

事实上，工作流可以client side自己做重试。这意味着工作流将管理重试逻辑。您可以编写自己的重试函数，也可以在 SDK 中提供一些帮助函数，例如Workflow.retryCadence-java-client。客户端重试将立即显示所有启动事件，但在重试单个活动时，历史记录中会有很多事件。由于性能问题，不建议这样做。

那么这些选项是什么意思：

  • 过期时间：

    • 它取代了 ScheduleToClose 超时，成为所有尝试的活动的实际总体超时。
    • 与其他三个超时选项一样，它也被限制为工作流超时。ScheduleToClose = Min(ScheduleToClose, workflowTimeout)
    • 每次尝试的超时时间为 StartToClose，但 StartToClose 默认为 ScheduleToClose，如上面的解释。
    • ScheduleToClose 将扩展到 ExpirationInterval: ScheduleToClose = Max(ScheduleToClose, ExpirationInterval)，这发生在 ScheduleToClose 被复制到 ScheduleToClose 和 StartToClose 之前。

  • InitialInterval：第一次重试的间隔

  • 退避系数：自我解释

  • MaximumInterval：重试期间的最大间隔

  • MaximumAttempts：最大尝试次数。如果与 ExpirationInterval 一起存在，则当超过其中之一时重试停止。

  • 要求和默认值：

  • 需要 MaximumAttempts 或 ExpirationInterval。如果未提供，ExpirationInterval 将设置为 workflowTimeout。

由于 ExpirationInterval 始终存在，实际上它更有用。大多数情况下，MaximumAttempts 更难使用，因为它很容易与 backoffCoefficient 混淆（例如，当 backoffCoefficient>1 时，如果不小心，端到端超时可能会非常大）。所以我建议只使用 ExpirationInterval。除非你真的需要它。

于 2020-12-04T06:56:34.777 回答