2016-05-17 1 views
0

セッションに「セッション化」できるイベントストリームを処理しようとしています。プールの1人のアクターが1つのセッションのすべてのイベントを処理する予定のアクターのプールを使用する予定です(理由はセッション状態を維持する必要があるためです)。これを達成するためには、特定のセッションに割り当てられた特定のアクタのActorRefを保持する必要があります。私が使用して俳優のプールを使用していますただし、:ルータを使用しているときに俳優の参照を取得する

val randomActor = _system.actorOf(Props[SessionProcessorActor].withRouter(RandomPool(100)), name = "RandomPoolActor") 

そこで、この場合には、randomActorはないプール内の個々の俳優に、プール全体にActorRefを提供します。どのようにして私は上記のことを達成することができますか?

私が考えることの1つの方法は、プールからのアクタが初期化された後に参照を返すことです(おそらくRandomPoolActor $ abなどのように見えます)。しかし、このメソッドにはいくつかの問題があります。その1つは、tellの代わりにaskパターンを使用しなければならないため、同じセッションのイベントを見逃すことはありません。

これを達成する他の方法はありますか?採用する他のパターン?

答えて

2

ConsistentHashingPoolあなたが探しているものに似た何かをすることができます。 ConsistentHashingRouterは、すべてのメッセージがhashKeyに基づいて同じアクターで終了することを保証します。このキーは、あなたのシナリオであなたのsessionIdになります。これを達成するためにActorRefsまたは他の参照を保持する必要はありません。

コードにhashKeyを定義する方法は複数あります。 ConsistentHashableを拡張するケースクラスを作成することをお勧めします。完了したらconsistentHashKeyメソッドを実装する必要があります。例:

case class HashableEnvelope(yourMsgClass: YourMsgClass) extends ConsistentHashable { 
    override def consistentHashKey = yourMsgClass.sessionId 
} 

その後、あなたはこのようなあなたのプールを定義することができます言及する

val pool = system.actorOf(Props[SessionProcessorActor].withRouter(ConsistentHashingPool(100))) 

もう一つは、ルータが同じハッシュキーを持つすべてのメッセージが同じ役者になってしまいますことを確実にするということですただし、特定のアクタが特定のhashKeyのメッセージのみを受け取ることは保証されません。複数のハッシュキーを受け取ることができます。それは問題ではないはずですが、ちょうどあなたのSessionProcessorActorはちょうど1つではなく、いくつかのhashKeysを処理できるはずです。

整合性のあるハッシュアルゴリズムは、どのメッセージが各アクタに行くかを決定します。あなたはそれがどのように動作するのかをウィキペディアで読むことができます:https://en.wikipedia.org/wiki/Consistent_hashing。 (デフォルトは10)、コンフィギュレーション内の仮想ノードの数を増やす必要があり、より均等な方法でメッセージを配布するには:

akka.actor.deployment.default.virtual-nodes-factor = 1000 

あなたが持っているどのように多くのsessionIdsや俳優に応じて、そのメッセージが表示されます分散なっていますより均等に。

+0

優秀 - コメントありがとうございます。これを試してみる - 私が探しているものかもしれない。簡単な質問:これは、手動で終了しない限り、特定のハッシュコードのアクターが実際に永遠にメモリに残っていることを意味しますか?その場合、私はそれらの俳優にいくつかのセッション・ステートを置くと、彼らは記憶を占め続けるでしょうか? –

+0

ここに関連する質問がありますが、こちらも未回答です:http://stackoverflow.com/questions/32075224/consistenthashingpool-in-akka-when-child-of-a-pool-router-terminates –

+0

ルータがルーティングしますhashKeyに基づくメッセージ。メッセージは、そのアクタが終了するか、またはそのアクタが終了しない限り、同じアクタで終了します。その場合、ルートは、アルゴリズムに基づいてその特定のハッシュキーのメッセージを取得する必要がある他のアクタを決定し、ルーティングを開始します。ルータのルートにある状態を追加すると、その状態はアクタが終了するか死ぬまでメモリを占有します。ステートフルなアクターを持つことに間違いはありませんが、アクターが死ぬときの状態を維持する必要がある場合に問題が発生します。そのためにAkkaの永続性を見てみましょう。 – hveiga

関連する問題