2017-02-15 20 views
0

サービスファブリック内のアクターの使用を検討していますが、開始する前にいくつかのことを明確にしたかっただけです。サービスファブリックアクターの状態を維持する

ユーザーからデータの処理要求を受け取り、IDを返すAPIがあります。ユーザーからの複数のリクエストは、処理が重複せず、完全に分離されているため、このためにアクターがうまく機能すると感じています。

しかし、私が理解したいことは、各リクエストから作成した各アクタ内に状態をローカルに格納し、その後にそのデータをクエリするとよいでしょうか?

「使用中」(https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-lifecycle)ではなくアクタが状態を維持し、アクタに新しい呼び出しが行われたときに再びアクティブになることを理解します。したがって、理論的には、各アクタに同じIDが割り当てられて、ユーザに返されると、問題は発生しません。アクタが非アクティブになっても、ユーザは戻ってクエリを実行できます。

これは良いアプローチですか、それとも仕事をしてストレージを別のステートフルサービスにオフロードするだけでよいですか?この問題の長所/短所のリストを入手することをお勧めします。

答えて

2

アクターのアクティベーション/非アクティブ化を超えても状態が確実に保存されている(つまり、他のノードにレプリケートされている)アクターの状態がPersistentと表示されている限り、ユーザーへのアクターは良いアプローチになります。アクティブなアクタは、単にそれがActorServiceの作業メモリにロードされていることを意味します。アクタが非アクティブ化され、その後呼び出されると、アクタが再アクティブ化されます。 ActorIdをユーザIDにマップすると、セカンダリデータストレージ(データベースなど)を必要とせずに、同じアイデンティティをアクタ自体に格納することができます。

アクターの特徴は、シングルスレッドであることです。これは、ActorとActorの状態へのアクセスがシーケンシャルな方法で行われることを意味します。アクターへのアクセスが主にユーザーのAPIとのやりとりによって行われる場合、それは問題ではありません。一方で、同時にアクターにアクセスしている複数のサービスがある場合は、これがボトルネックになる可能性があります。その場合、データ/状態の代わりに信頼できるステートフルサービスを使用することを検討してください。

永続俳優

  • シングルスレッドアクセス
  • アクターIDによって仕切ら含ま状態

俳優状態と別持続性無し

  • アクターIDで仕切られたシングルスレッドアクセス
  • 持続性溶液(SQL接続プールなどで制限
  • 州/データアクセス)

ステートフルサービス

  • マルチスレッドアクセスを確実にパーティション

ステートレスサービス内に含まれる '手動' に割り当てられたパーティションキー

  • 状態で仕切ら
    • マルチスレッドアクセス
    • いいえ分割、複数のインスタンス
    永続溶液(SQL接続プール等)によって制限
  • 状態/データアクセス
  • 関連する問題