サービスファブリックアクター - 状態をデータベースに保存

Question

サンプルサービスファブリックプロジェクトでは、ショッピングリストを管理する必要があります。このためには、特定のIDによって識別可能なShoppingListアクタがあります。 StateManagerを使用して現在のリストコンテンツをその状態に格納します。すべて正常に動作します。

しかし、並行して、ショッピングリストのコンテンツをSQLデータベースに保存したいと考えています。特に：

• 店（クラスタが再作成された後など）すべてを追加/ DBから最初の俳優の初期化ロードリストの内容に将来の分析のための項目の要求（ML）
• を削除

それを達成するための最良のアプローチは何ですか？カスタムStateProviderを作成します（例は見つかりません）。 （おそらく、キューやリマインダーを使用して）すべてのdb操作を処理するための別のサービス/アクターがありますか？

すべての例は、デフォルトのStateManagerに完全に依存しているように見えますが、外部ストレージへのデータ永続性はないため、ベストプラクティスがわかりません。

Answer 1

DBへのデータの格納を担当する別個のエンティティを持つことをお勧めします。そして、俳優は、実行された操作に関するデータを含むイベント（SFイベントを意味しない）を送信し、別のエンティティはそれを捕捉して残りの作業を実行します。

しかし、もちろん、あなたは俳優自身にこの事を実装することができますが、それは2つの可能な問題をもたらす：間のDBまたは接続といくつかの問題があるかどう

• 俳優は、他の要求を処理することはできないだろうアクターとDB、またはDB自体の負荷が高くなり、要求がゆっくりと処理されるかどうかを判断します。アクターは、DBへの転送が正常に完了するまで待たなければなりません。
• 他のエンティティからの1つまたは複数の接続ではなく、多くのアクターからの多くの単一接続でのDBのオーバーロードが可能で、バッチ挿入。

したがって、最終的な解決方法はシステムの作業負荷によって異なります。しかし、間違いなく、そのようなデータの価値が高すぎて損失をもたらすことができない場合、DBにデータを安全に格納するための信頼できるキューが必要です。

また、トランザクションの完了後にDBに転送されてサービスの状態から削除される前に、トランザクションに関するログと情報を保存するために、デフォルトの状態マネージャを使用することもできます。そのようなデータをサービスに永久保存する必要はありません。

さらに、DBからの読み込みを考慮する必要があります。おそらく、あなたが関係データベースを持っていて、新しいレコードで更新するのは1つのテーブルだけです+アクティブ化時にそのようなデータをクエリするアクターが膨大な量になる場合は、パフォーマンスが低下します。それは異なった振る舞いをするように構成されません。だから、おそらく、アクターのアクティベーションのためのデータを読み込むためのキャッシュシステムが必要になるでしょう - あなたのワークロードに依存します。

カスタムState Managerの実装については、thisの例をご覧ください。基本的には、IReliableStateManagerReplicaインターフェイスを実装して、StatefullServiceコンストラクタに渡すだけです。