2

したがって、非常に多くのタイムアウト値があります。

ローカル アクティビティの場合:

  • ScheduleToClose タイムアウト

再試行なしの通常のアクティビティの場合:

  • ScheduleToStart タイムアウト
  • ScheduleToClose タイムアウト
  • StartToClose タイムアウト
  • ハートビート タイムアウト

そして、retryOptionsのその他の値:

  • 有効期限間隔
  • 初期間隔
  • バックオフ係数
  • 最大間隔
  • 最大試行回数

また、retryOptions は localActivity または通常のアクティビティに適用できます。

それらをどのように組み合わせてどのように使用しますか？

4

1 に答える 1

4

TL;DR

タイムアウトを使用する最も簡単な方法:

再試行を伴う通常のアクティビティ:

  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 : 全体的なタイムアウトには ScheduleToClose を使用します

再試行を伴う LocalActivity :

  1. 各試行のタイムアウトとして ScheduleToClose を使用します。
  2. バックオフを制御するには、retryOptions.InitialInterval、retryOptions.BackoffCoefficient、retryOptions.MaximumInterval を使用します。
  3. すべての試行の全体的なタイムアウトとして retryOptions.ExperiationInterval を使用します。
  4. retryOptions.MaximumAttempts を空のままにします。

何となぜ

リトライなしの基本

やり直しのない世界のほうが物事は理解しやすい。ケイデンスはそこから始まったからです。

  • ScheduleToClose タイムアウトは、ワークフローの観点から見た全体的なエンド ツー エンドのタイムアウトです。

  • ScheduleToStart タイムアウトは、アクティビティ ワーカーがアクティビティを開始するのに必要な時間です。このタイムアウトを超えると、アクティビティは ScheduleToStart タイムアウト エラー/例外をワークフローに返します

  • StartToClose タイムアウトは、アクティビティの実行に必要な時間です。これを超えると、StartToClose がワークフローに返されます。

  • 要件とデフォルト:

    • ScheduleToClose が提供されるか、ScheduleToStart と StartToClose の両方が提供されます。
    • ScheduleToClose のみの場合、ScheduleToStart と StartToClose はデフォルトです。
    • ScheduleToStart と StartToClose のみが指定されている場合は、ScheduleToClose = ScheduleToStart + StartToClose.
    • それらはすべて、workflowTimeout によって制限されます。(たとえば、workflowTimeout が 1 時間の場合、ScheduleToClose に 2 時間を設定しても 1 時間になりますScheduleToClose=Min(ScheduleToClose, workflowTimeout):)

では、なぜ彼らは？

ScheduleToClose は ScheduleToClose < ScheduleToStart + StartToClose. ScheduleToClose タイムアウトが他の 2 つの組み合わせによって既に強制されている場合ScheduleToClose >= ScheduleToStart+StartToClose、意味がなくなるためです。

したがって、ScheduleToClose が 2 の合計よりも小さい場合の主な使用例は、アクティビティの全体的なタイムアウトを制限したいが、scheduleToStart または startToClose のタイムアウトを増やしたい場合です。これは非常にまれな使用例です。

また、ScheduleToStart と StartToClose を区別したい主な使用例は、ワークフローが ScheduleToStart タイムアウト エラーに対して特別な処理を行う必要がある場合です。これも非常にまれな使用例です。

したがって、TL;DR で、 ScheduleToCloseのみを使用し、他の 2 つを空のままにすることをお勧めする理由を理解できます。ごくまれに必要になる場合があるためです。ユースケースが思いつかない場合は、必要ありません。

LocalActivity には ScheduleToStart/StartToClose がありません。これは、サーバー スケジューリングが関係なくワークフロー ワーカー内で直接開始されるためです。

ハートビート タイムアウト

ハートビートは、長時間実行されるアクティビティにとってスタックを防ぐために非常に重要です。バグが原因でアクティビティが停止するだけでなく、通常のデプロイ/ホストの再起動/障害によっても発生する可能性があります。ハートビートがなければ、Cadence サーバーはアクティビティがまだ処理中であるかどうかを認識できませんでした。こちらの詳細については、Cadence/SWF/StepFunctions で停止したタイマー/アクティビティを修正するためのソリューションを参照してください。

RetryOptions と Retry を使用したアクティビティ

まず、ここで RetryOptions はserver sideバックオフ再試行用です。つまり、再試行はワークフローと対話することなく Cadence によって自動的に管理されます。再試行はケイデンスによって管理されるため、開始されたイベントはアクティビティが終了するまで書き込まれないように、アクティビティをケイデンスの履歴で特別に処理する必要があります。ここにいくつかの参考資料があります:活動タスクがスケジュールされているのに開始されていないのはなぜですか?

実際、ワークフローはclient side独自に再試行できます。これは、ワークフローが再試行ロジックを管理することを意味します。独自の再試行関数を作成するか、SDKWorkflow.retryに Cadence-java-client のようなヘルパー関数があります。クライアント側の再試行では、すべての開始イベントがすぐに表示されますが、単一のアクティビティを再試行すると、履歴に多くのイベントが残ります。パフォーマンスの問題があるため、お勧めしません。

では、オプションの意味は次のとおりです。

  • 有効期限:

    • ScheduleToClose タイムアウトを置き換えて、すべての試行のアクティビティの実際の全体的なタイムアウトになります。
    • また、他の 3 つのタイムアウト オプションと同様に、ワークフロー タイムアウトにも上限があります。ScheduleToClose = Min(ScheduleToClose, workflowTimeout)
    • 各試行のタイムアウトは StartToClose ですが、上記の説明のように StartToClose のデフォルトは ScheduleToClose です。
    • ScheduleToClose は ExpirationInterval: まで延長されます ScheduleToClose = Max(ScheduleToClose, ExpirationInterval)。これは、ScheduleToClose が ScheduleToClose および StartToClose にコピーされる前に発生します。

  • InitialInterval: 最初の再試行の間隔

  • BackoffCoefficient: 自己説明

  • MaximumInterval: 再試行中の間隔の最大値

  • MaximumAttempts: 最大試行回数。ExpirationInterval が存在する場合、いずれかを超えると再試行が停止します。

  • 要件とデフォルト:

  • MaximumAttempts または ExpirationInterval のいずれかが必要です。ExpirationInterval は、指定されていない場合、workflowTimeout に設定されます。

ExpirationInterval は常に存在するため、実際にはより便利です。ほとんどの場合、MaximumAttempts を使用するのは困難です。これは、backoffCoefficient を簡単に台無しにしてしまうためです (たとえば、backoffCoefficient>1 の場合、注意しないとエンド ツー エンドのタイムアウトが非常に大きくなる可能性があります)。したがって、ExpirationInterval を使用することをお勧めします。あなたが本当にそれを必要としない限り。

于 2020-12-04T06:56:34.777 に答える