1

ケイデンス0.11を使用

私たちのプロジェクトには、workflowHistory を必要とする頻繁に使用されるサービスがあります。
したがって、この関数を頻繁に呼び出す必要があります。

GetWorkflowHistory(ctx context.Context, workflowID string, runID string, isLongPoll bool, filterType s.HistoryEventFilterType) HistoryEventIterator

問題は、関数の呼び出しが非常に遅く、サービスが非常に遅くなることです。さらに、キャッシュは頻繁に更新されるデータを保存できないため、キャッシュを使用できないように、ワークフローの正確性を確保する必要があります。

workflowHistory を取得するためのより迅速な方法はありますか? おそらく新しいAPI、またはケイデンスのいくつかの新しい構成ですか？

4

1 に答える 1

2

履歴を取得するためのより高速な方法はありません。待ち時間は、履歴の長さとサイズによって異なります。これは Cadence の重要な API であるため、パフォーマンスはそのアーキテクチャ内で最適化されています。

ただし、ユース ケースに基づくと、これは API の誤用です。ワークフローのクエリ ハンドラーを実装する必要があります。ワーカーは、履歴を解析するために行っているのと同じことをすべて行います。

必要に応じて、ワークフロー イベントのほとんどすべてを返す非常に一般的なクエリ ハンドラーを実装できます。そのため、履歴から取得するようなものを取得できるのは 1 つのクエリ ハンドラーだけです。具体的には、すべてのシグナル、アクティビティの入力出力などをリストに入れ、そのリストをクエリ結果として返すことができます。

ワーカー クエリを使用すると、レイテンシが節約されます。これは、Cadence ワーカーが履歴をキャッシュするためです。ワークフローに変更がない場合、サーバーからそれ以上の履歴は取得されません。新しいイベントが追加されると、イベントのデルタのみがワーカーとサーバーの間で転送されます。したがって、履歴の長さに関係なく、レイテンシは最小になります。

ワーカーが履歴全体をリロードする必要がある唯一のケースは、キャッシュが削除されたとき、またはワーカーが再起動したときです。そのため、その場合にリソースのコストがかかりすぎないように、履歴を短くすることを常にお勧めします。

クエリに関するその他のドキュメントを参照してください。

https://cadenceworkflow.io/docs/concepts/queries/#stack-trace-query

ゴラン

https://cadenceworkflow.io/docs/go-client/queries/

Java https://cadenceworkflow.io/docs/java-client/queries/

Golang を例にとると、アクティビティの結果をクエリ出力として返したい場合は、次のようになります。


func MyWorkflow(ctx workflow.Context, input string) error {
    var res map[string]string 
    err := workflow.SetQueryHandler(ctx, "current_state", func() (map[string]string, error) {
        return res, nil
    })
    
    ctx = workflow.WithActivityOptions(ctx, ...)
    var act_out string 
    err = workflow.ExecuteActivity(ctx, ActivityA, "my_input").Get(ctx, &act_out)
    if err != nil {
        res["ActivityA"] = act_out
        return err
    }
    return nil
}
于 2021-09-01T05:51:15.647 に答える