AKKAのReceive-methodの中に子アクターを作成するのは理にかなっていますか？

Question

いくつかのサブプロセスを子アクターに委任する必要があると仮定します。アクタの初期化中に子アクタを作成することができます（AKKA.NETのPreStartと呼ばれます）。並行して動作する複数の子アクターが必要な場合は、AKKAルーターを使用できます。私はこれを推奨アプローチと考えています。

しかし、私はまた、受信・メソッド内で子役を作成し、IActorRefインスタンスへの参照が受信-法のローカルスコープを持ってみましょうことができます。このアプローチはこれまで理にかなっていますか？上記の場合よりも利点がありますか？

Answer 1

はい。たとえば、受信した各メッセージがステートフルなプロセスを開始する場合、このプロセスを処理する子アクターを作成します。これらの子アクターは、他のアクターからの他のメッセージに応答する必要があるかもしれません。プロセスが終了するように指示する最後のメッセージが表示されることがあります。メッセージの一部としてIActorRefを渡すことができるので、ローカルスコープの概念が必ずしも適用されるわけではありません。

Answer 2

それはあなたが入ってくるデータに応じて動的に作成するので、あなたがそれらを演繹的に作成することができない場合は特に、メッセージハンドラで子役を作成するための完璧な意味があります。

本の典型的な例では、各エンティティIDの俳優を作成Child Per Entity pattern、です。したがって、以前に受信していない新しいIDのメッセージを受信した場合は、新しい子アクターをスピンアップする必要があります。

あなたはhow the web crawler sample does thisを見ることができます。最初の誘惑は、子供の俳優のためのidの辞書を維持することですが、これは必要でもないことが判明します。 Webクローラサンプルでは、​​俳優のChildrenをチェックして、その子が既にあるかどうかを判断できます。

あなたが動的に子役を作成するとき、あなたは彼らは永遠に住んでメモリリークが発生していないことを確認するために、彼らにReceiveTimeoutを与えたいと思うことがあります。

Answer 3

俳優が余分とカメオパターン動的に作成されている別の例を説明hereとソースコードhere

カメオパターンの基本的な考え方は、応答ファサードフロント実際の労働者（カメオ）です。ファサードはレスポンスパス上になく、Cameoに関連するすべてのコンテキストを渡し、ジョブを完了させ、結果を（元のジョブの）送信者に直接伝えることができるため、ルータとは異なります。

余分なパターンは同じですが、匿名の俳優です。カメオの俳優は、より良いログ（読みやすい俳優の名前を持つ）を提供し、コードを少し良くするために優れています。また、ファサードの俳優の状態を閉じるのは難しいです。

ボトムライン：要求ごとにアクターを作成することで、作業単位をよりよく断熱し、「エントリーポイント」アクターのビジーを少なくし、より良いスコープのログを提供します（分散システムの動作を理解する上で非常に重要）。